On Oct 7, 2023, at 03:47, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > On Fri, Sep 15, 2023 at 11:21:28AM +0800, Jerry Shih wrote: >> On Sep 15, 2023, at 09:48, He-Jie Shih <bignose1007@xxxxxxxxx> 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]
