| Message ID | 20230626084703.907331-5-letrhee@nsr.re.kr (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | crypto: LEA block cipher implementation | expand |
On Mon, Jun 26, 2023 at 05:47:03PM +0900, Dongsoo Lee wrote: > when SIMD instructions are available, it performs even faster. This will only be true once there is actually an applicable implementation of LEA-XTS and LEA-CTS using SIMD instructions included in the kernel. Perhaps it is your plan to go through and accelerate LEA-XTS and LEA-CTS for the common CPU architectures. However, it is not included in this patchset yet, so it should not be claimed in the documentation yet. > Particularly, it outperforms AES when the dedicated crypto > +instructions for AES are unavailable, regardless of the presence of SIMD > +instructions. However, it is not recommended to use LEA unless there is > +a clear reason (such as the absence of dedicated crypto instructions for > +AES or a mandatory requirement) to do so. Also, to enable LEA support, > +it needs to be enabled in the kernel crypto API. I think I'd prefer that you omit the mention of the "absence of dedicated crypto instructions" use case for now. fscrypt already supports another algorithm that fulfills exactly that use case (Adiantum), and that algorithm already has optimized implementations for arm32, arm64, and x86_64. LEA does not have that yet. So it does not really bring anything new to the table. I'm also unsure it would be appropriate to recommend a "lightweight" cipher at this point... That would leave "mandatory requirement" as the rationale, at least for now, similar to SM4. - Eric
On Tue, Jun 27, 2023 at 23:38:30 -0700, Eric Biggers wrote: >On Mon, Jun 26, 2023 at 05:47:03PM +0900, Dongsoo Lee wrote: >> when SIMD instructions are available, it performs even faster. > >This will only be true once there is actually an applicable implementation of >LEA-XTS and LEA-CTS using SIMD instructions included in the kernel. > >Perhaps it is your plan to go through and accelerate LEA-XTS and LEA-CTS for the >common CPU architectures. However, it is not included in this patchset yet, so >it should not be claimed in the documentation yet. > >> Particularly, it outperforms AES when the dedicated crypto >> +instructions for AES are unavailable, regardless of the presence of SIMD >> +instructions. However, it is not recommended to use LEA unless there is >> +a clear reason (such as the absence of dedicated crypto instructions for >> +AES or a mandatory requirement) to do so. Also, to enable LEA support, >> +it needs to be enabled in the kernel crypto API. > >I think I'd prefer that you omit the mention of the "absence of dedicated crypto >instructions" use case for now. fscrypt already supports another algorithm that >fulfills exactly that use case (Adiantum), and that algorithm already has >optimized implementations for arm32, arm64, and x86_64. LEA does not have that >yet. So it does not really bring anything new to the table. I'm also unsure it >would be appropriate to recommend a "lightweight" cipher at this point... > >That would leave "mandatory requirement" as the rationale, at least for now, >similar to SM4. > >- Eric As you might expect, we are working on a SIMD implementation of LEA in a general-purpose CPU environment. However, since no such implementation has been submitted yet, we agree that it's right to leave it out for now. In the next version, we would like to change the description to the following: LEA is a South Korean 128-bit block cipher (with 128/192/256-bit keys) included in the ISO/IEC 29192-2:2019 standard (Information security - Lightweight cryptography - Part 2: Block ciphers). If dedicated cipher instructions are available, or other options with performance benefits are available, using LEA is likely not a suitable choice. Therefore, it is not recommended to use LEA-256-XTS unless there is a clear reason to do so, such as if there is a mandate. Also, to enable LEA support, it needs to be enabled in the kernel crypto API.
On Thu, Jun 29, 2023 at 07:01:11PM +0900, Dongsoo Lee wrote: > On Tue, Jun 27, 2023 at 23:38:30 -0700, Eric Biggers wrote: > >On Mon, Jun 26, 2023 at 05:47:03PM +0900, Dongsoo Lee wrote: > >> when SIMD instructions are available, it performs even faster. > > > >This will only be true once there is actually an applicable implementation > of > >LEA-XTS and LEA-CTS using SIMD instructions included in the kernel. > > > >Perhaps it is your plan to go through and accelerate LEA-XTS and LEA-CTS > for the > >common CPU architectures. However, it is not included in this patchset > yet, so > >it should not be claimed in the documentation yet. > > > >> Particularly, it outperforms AES when the dedicated crypto > >> +instructions for AES are unavailable, regardless of the presence of SIMD > >> +instructions. However, it is not recommended to use LEA unless there is > >> +a clear reason (such as the absence of dedicated crypto instructions for > >> +AES or a mandatory requirement) to do so. Also, to enable LEA support, > >> +it needs to be enabled in the kernel crypto API. > > > >I think I'd prefer that you omit the mention of the "absence of dedicated > crypto > >instructions" use case for now. fscrypt already supports another algorithm > that > >fulfills exactly that use case (Adiantum), and that algorithm already has > >optimized implementations for arm32, arm64, and x86_64. LEA does not have > that > >yet. So it does not really bring anything new to the table. I'm also > unsure it > >would be appropriate to recommend a "lightweight" cipher at this point... > > > >That would leave "mandatory requirement" as the rationale, at least for > now, > >similar to SM4. > > > >- Eric > > As you might expect, we are working on a SIMD implementation of LEA in a > general-purpose CPU environment. However, since no such implementation has > been submitted yet, we agree that it's right to leave it out for now. > > In the next version, we would like to change the description to the > following: > > LEA is a South Korean 128-bit block cipher (with 128/192/256-bit keys) > included in the ISO/IEC 29192-2:2019 standard (Information security - > Lightweight cryptography - Part 2: Block ciphers). If dedicated cipher > instructions are available, or other options with performance benefits > are available, using LEA is likely not a suitable choice. Therefore, > it is not recommended to use LEA-256-XTS unless there is a clear reason > to do so, such as if there is a mandate. Also, to enable LEA support, > it needs to be enabled in the kernel crypto API. 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
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.
On Thu, Jun 29, 2023 at 07:59:14PM -0700, Eric Biggers wrote: > On Thu, Jun 29, 2023 at 07:01:11PM +0900, Dongsoo Lee wrote: > > On Tue, Jun 27, 2023 at 23:38:30 -0700, Eric Biggers wrote: > > >On Mon, Jun 26, 2023 at 05:47:03PM +0900, Dongsoo Lee wrote: > > >> when SIMD instructions are available, it performs even faster. > > > > > >This will only be true once there is actually an applicable implementation > > of > > >LEA-XTS and LEA-CTS using SIMD instructions included in the kernel. > > > > > >Perhaps it is your plan to go through and accelerate LEA-XTS and LEA-CTS > > for the > > >common CPU architectures. However, it is not included in this patchset > > yet, so > > >it should not be claimed in the documentation yet. > > > > > >> Particularly, it outperforms AES when the dedicated crypto > > >> +instructions for AES are unavailable, regardless of the presence of SIMD > > >> +instructions. However, it is not recommended to use LEA unless there is > > >> +a clear reason (such as the absence of dedicated crypto instructions for > > >> +AES or a mandatory requirement) to do so. Also, to enable LEA support, > > >> +it needs to be enabled in the kernel crypto API. > > > > > >I think I'd prefer that you omit the mention of the "absence of dedicated > > crypto > > >instructions" use case for now. fscrypt already supports another algorithm > > that > > >fulfills exactly that use case (Adiantum), and that algorithm already has > > >optimized implementations for arm32, arm64, and x86_64. LEA does not have > > that > > >yet. So it does not really bring anything new to the table. I'm also > > unsure it > > >would be appropriate to recommend a "lightweight" cipher at this point... > > > > > >That would leave "mandatory requirement" as the rationale, at least for > > now, > > >similar to SM4. > > > > > >- Eric > > > > As you might expect, we are working on a SIMD implementation of LEA in a > > general-purpose CPU environment. However, since no such implementation has > > been submitted yet, we agree that it's right to leave it out for now. > > > > In the next version, we would like to change the description to the > > following: > > > > LEA is a South Korean 128-bit block cipher (with 128/192/256-bit keys) > > included in the ISO/IEC 29192-2:2019 standard (Information security - > > Lightweight cryptography - Part 2: Block ciphers). If dedicated cipher > > instructions are available, or other options with performance benefits > > are available, using LEA is likely not a suitable choice. Therefore, > > it is not recommended to use LEA-256-XTS unless there is a clear reason > > to do so, such as if there is a mandate. Also, to enable LEA support, > > it needs to be enabled in the kernel crypto API. > > 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 I've sent out https://lore.kernel.org/linux-fscrypt/20230630064811.22569-1-ebiggers@kernel.org/T/#u. One of the things it does is add a nice list for the "national pride ciphers". So we can just add ciphers like SM4 and LEA, and any that people might insist on adding in the future like Camellia, Kuznyechik, SEED, ARIA, etc., to that list, and not have to waste time with each one individually... - Eric
On Thu, Jun 29, 2023 at 23:59:53 -0700, Eric Biggers wrote: > I've sent out > https://lore.kernel.org/linux-fscrypt/20230630064811.22569-1-ebiggers@kernel.org/T/#u. > One of the things it does is add a nice list for the "national pride ciphers". > So we can just add ciphers like SM4 and LEA, and any that people might insist on > adding in the future like Camellia, Kuznyechik, SEED, ARIA, etc., to that list, > and not have to waste time with each one individually... > > - Eric That seems reasonable enough to us. Thank you for your consideration.
diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index eccd327e6df5..60fb82c3382e 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -339,6 +339,7 @@ Currently, the following pairs of encryption modes are supported: - Adiantum for both contents and filenames - AES-256-XTS for contents and AES-256-HCTR2 for filenames (v2 policies only) - SM4-XTS for contents and SM4-CTS-CBC for filenames (v2 policies only) +- LEA-256-XTS for contents and LEA-256-CTS-CBC for filenames (v2 policies only) If unsure, you should use the (AES-256-XTS, AES-256-CTS-CBC) pair. @@ -376,6 +377,17 @@ size. It may be useful in cases where its use is mandated. Otherwise, it should not be used. For SM4 support to be available, it also needs to be enabled in the kernel crypto API. +LEA is a South Korean 128-bit block cipher (with 128/192/256-bit keys) +included in the ISO/IEC 29192-2:2019 standard (Information security - +Lightweight cryptography - Part 2: Block ciphers). It shows fast +performance and, when SIMD instructions are available, it performs even +faster. Particularly, it outperforms AES when the dedicated crypto +instructions for AES are unavailable, regardless of the presence of SIMD +instructions. However, it is not recommended to use LEA unless there is +a clear reason (such as the absence of dedicated crypto instructions for +AES or a mandatory requirement) to do so. Also, to enable LEA support, +it needs to be enabled in the kernel crypto API. + New encryption modes can be added relatively easily, without changes to individual filesystems. However, authenticated encryption (AE) modes are not currently supported because of the difficulty of dealing diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index 7ab5a7b7eef8..400238057219 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -31,7 +31,7 @@ #define FSCRYPT_CONTEXT_V2 2 /* Keep this in sync with include/uapi/linux/fscrypt.h */ -#define FSCRYPT_MODE_MAX FSCRYPT_MODE_AES_256_HCTR2 +#define FSCRYPT_MODE_MAX FSCRYPT_MODE_LEA_256_CTS struct fscrypt_context_v1 { u8 version; /* FSCRYPT_CONTEXT_V1 */ diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index 361f41ef46c7..fa82579e56eb 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -74,6 +74,21 @@ struct fscrypt_mode fscrypt_modes[] = { .security_strength = 32, .ivsize = 32, }, + [FSCRYPT_MODE_LEA_256_XTS] = { + .friendly_name = "LEA-256-XTS", + .cipher_str = "xts(lea)", + .keysize = 64, + .security_strength = 32, + .ivsize = 16, + .blk_crypto_mode = BLK_ENCRYPTION_MODE_LEA_256_XTS, + }, + [FSCRYPT_MODE_LEA_256_CTS] = { + .friendly_name = "LEA-256-CTS-CBC", + .cipher_str = "cts(cbc(lea))", + .keysize = 32, + .security_strength = 32, + .ivsize = 16, + }, }; static DEFINE_MUTEX(fscrypt_mode_key_setup_mutex); diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c index f4456ecb3f87..9d1e80c43c6d 100644 --- a/fs/crypto/policy.c +++ b/fs/crypto/policy.c @@ -94,6 +94,10 @@ static bool fscrypt_valid_enc_modes_v2(u32 contents_mode, u32 filenames_mode) filenames_mode == FSCRYPT_MODE_SM4_CTS) return true; + if (contents_mode == FSCRYPT_MODE_LEA_256_XTS && + filenames_mode == FSCRYPT_MODE_LEA_256_CTS) + return true; + return fscrypt_valid_enc_modes_v1(contents_mode, filenames_mode); } diff --git a/include/uapi/linux/fscrypt.h b/include/uapi/linux/fscrypt.h index fd1fb0d5389d..df3c8af98210 100644 --- a/include/uapi/linux/fscrypt.h +++ b/include/uapi/linux/fscrypt.h @@ -30,7 +30,9 @@ #define FSCRYPT_MODE_SM4_CTS 8 #define FSCRYPT_MODE_ADIANTUM 9 #define FSCRYPT_MODE_AES_256_HCTR2 10 -/* If adding a mode number > 10, update FSCRYPT_MODE_MAX in fscrypt_private.h */ +#define FSCRYPT_MODE_LEA_256_XTS 11 +#define FSCRYPT_MODE_LEA_256_CTS 12 +/* If adding a mode number > 12, update FSCRYPT_MODE_MAX in fscrypt_private.h */ /* * Legacy policy version; ad-hoc KDF and no key verification. diff --git a/tools/include/uapi/linux/fscrypt.h b/tools/include/uapi/linux/fscrypt.h index fd1fb0d5389d..df3c8af98210 100644 --- a/tools/include/uapi/linux/fscrypt.h +++ b/tools/include/uapi/linux/fscrypt.h @@ -30,7 +30,9 @@ #define FSCRYPT_MODE_SM4_CTS 8 #define FSCRYPT_MODE_ADIANTUM 9 #define FSCRYPT_MODE_AES_256_HCTR2 10 -/* If adding a mode number > 10, update FSCRYPT_MODE_MAX in fscrypt_private.h */ +#define FSCRYPT_MODE_LEA_256_XTS 11 +#define FSCRYPT_MODE_LEA_256_CTS 12 +/* If adding a mode number > 12, update FSCRYPT_MODE_MAX in fscrypt_private.h */ /* * Legacy policy version; ad-hoc KDF and no key verification.
Add LEA-256-XTS, LEA-256-CTS fscrypt support. LEA is a South Korean 128-bit block cipher (with 128/192/256-bit keys) included in the ISO/IEC 29192-2:2019 standard (Information security - Lightweight cryptography - Part 2: Block ciphers). It shows fast performance and, when SIMD instructions are available, it performs even faster. Particularly, it outperforms AES when the dedicated crypto instructions for AES are unavailable, regardless of the presence of SIMD instructions. However, it is not recommended to use LEA unless there is a clear reason (such as the absence of dedicated crypto instructions for AES or a mandatory requirement) to do so. Also, to enable LEA support, it needs to be enabled in the kernel crypto API. Signed-off-by: Dongsoo Lee <letrhee@nsr.re.kr> --- Documentation/filesystems/fscrypt.rst | 12 ++++++++++++ fs/crypto/fscrypt_private.h | 2 +- fs/crypto/keysetup.c | 15 +++++++++++++++ fs/crypto/policy.c | 4 ++++ include/uapi/linux/fscrypt.h | 4 +++- tools/include/uapi/linux/fscrypt.h | 4 +++- 6 files changed, 38 insertions(+), 3 deletions(-)