On Oct 7, 2023, at 03:47, Eric Biggers <[email protected]> wrote:
> On Fri, Sep 15, 2023 at 11:21:28AM +0800, Jerry Shih wrote:
>> On Sep 15, 2023, at 09:48, He-Jie Shih <[email protected]> wrote:
>> The OpenSSL PR is at [1].
>> And we are from SiFive.
>>
>> -Jerry
>>
>> [1]
>> https://github.com/openssl/openssl/pull/21923
>
> Hi Jerry, I'm wondering if you have an update on this? Do you need any help?
We have specialized aes-cbc/ecb/ctr patch locally and pass the `testmgr` test
cases. But the test patterns in `testmgr` are quite simple, I think it doesn't test the
corner case(e.g. aes-xts with tail element).
For aes-xts, I'm trying to update the implementation from OpenSSL. The design
philosophy is different between OpenSSL and linux. In linux crypto, the data will
be split into `scatterlist`. I need to preserve the aes-xts's iv for each scatterlist
entry call. And I'm thinking about how to handle the tail data in a simple way.
By the way, the `xts(aes)` implementation for arm and x86 are using
`cra_blocksize= AES_BLOCK_SIZE`. I don't know why we need to handle the tail
element. I think we will hit `EINVAL` error in `skcipher_walk_next()` if the data size
it not be a multiple of block size.
Overall, we will have
1) aes cipher
2) aes with cbc/ecb/ctr/xts mode
3) sha256/512 for `vlen>=128` platform
4) sm3 for `vlen>=128` platform
5) sm4
6) ghash
7) `chacha20` stream cipher
The vector crypto pr in OpenSSL is under reviewing, we are still updating the
perl file into linux.
The most complicated `gcm(aes)` mode will be in our next plan.
> I'm also wondering about riscv.pm and the choice of generating the crypto
> instructions from .words instead of using the assembler. It makes it
> significantly harder to review the code, IMO. Can we depend on assembler
> support for these instructions, or is that just not ready yet?
I have asked the same question before[1]. The reason is that Openssl could use
very old compiler for compiling. Thus, the assembler might not know the standard
rvv 1.0[2] and other vector crypto[3] instructions. That's why we use opcode for all
vector instructions. IMO, I would prefer to use opcode for `vector crypto` only. The
gcc-12 and clang-14 are already supporting rvv 1.0. Actually, I just read the `perl`
file instead of the actually generated opcode for OpenSSL pr reviewing. And it's
not hard to read the perl code.
Thanks,
- Jerry
[1]
https://github.com/openssl/openssl/pull/20149#discussion_r1244655440
[2]
https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc
[3
https://github.com/riscv/riscv-crypto/blob/main/doc/vector/riscv-crypto-spec-vector.adoc]
On Sat, Oct 07, 2023 at 05:01:45AM +0800, He-Jie Shih wrote:
> Reply-To: [email protected]
> X-Mailer: Apple Mail (2.3445.9.7)
Can you please fix your email client configuration? Your emails have a bogus
Reply-To header, which makes replies not be sent to you by default.
- Eric