[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <001201d9ab0d$a6ab50b0$f401f210$@nsr.re.kr>
Date: Fri, 30 Jun 2023 13:45:10 +0900
From: Dongsoo Lee <letrhee@....re.kr>
To: 'Eric Biggers' <ebiggers@...nel.org>
Cc: 'Herbert Xu' <herbert@...dor.apana.org.au>,
"'David S. Miller'" <davem@...emloft.net>,
'Jens Axboe' <axboe@...nel.dk>,
"'Theodore Y. Ts'o'" <tytso@....edu>,
'Jaegeuk Kim' <jaegeuk@...nel.org>,
linux-crypto@...r.kernel.org, linux-block@...r.kernel.org,
linux-fscrypt@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: RE: [PATCH v3 4/4] fscrypt: Add LEA-256-XTS, LEA-256-CTS support
On Thu, Jun 29, 2023 at 19:59:14 -0700, Eric Biggers wrote:
> I don't think that really addresses my comment, due to the second
sentence. I
> understand that you would like to advertise the performance of LEA. But
as I
> mentioned, it's not yet realized in the kernel crypto API, and in the
context of
> fscrypt it won't really bring anything new to the table anyway. For now I
think
> LEA is best described as a "national pride cipher" alongside SM4... Keep
in
> mind, it can always be changed later if new use cases come up.
>
> Could you just omit the documentation update from your patch? I actually
need
> to rework the whole "Encryption modes and usage" section anyway since it's
> growing a bit unwieldy, with 6 different combinations of encryption modes
now
> supported. The information needs to be organized better. It currently
reads
> like a list, and it might be hard for users to understand which setting to
use.
>
> I'll add on a patch that does that and adds the mention of LEA support.
>
> - Eric
Thanks for the feedback.
We'll remove the documentation and submit the next version.
Powered by blists - more mailing lists