| Message ID | 20230626084703.907331-1-letrhee@nsr.re.kr (mailing list archive) |
|---|---|
| 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.
This submission contains a generic C implementation of the LEA cipher algorithm and test vectors for it. It also includes modifications to use the LEA in fscrypt. The LEA algorithm is a lightweight block cipher that processes data blocks of 128-bits and has three different key lengths, each with a different number of rounds: - LEA-128: 128-bit key, 24 rounds, - LEA-192: 192-bit key, 28 rounds, and - LEA-256: 256-bit key, 32 rounds. The round function of LEA consists of 32-bit ARX(modular Addition, bitwise Rotation, and bitwise XOR) operations. See [2, 5, 7] for details. LEA is a Korean national standard block cipher, described in "KS X 3246"[1] and is also included in the international standard, "ISO/IEC 29192-2:2019 standard"[2]. It is one of the approved block ciphers for the current Korean Cryptographic Module Validation Program (KCMVP). We expect that the first application of the patch would be disk encryption on the Gooroom platform ('Gooroom' is a Korean word, meaning 'cloud') [3]. Currently, the Gooroom platform uses AES-XTS for disk encryption. The main reason for submitting this patch is to make disk encryption with LEA (e.g. LEA-XTS) available on there. It is possible to use LEA without any additional modifications in dm-crypt, a module that provides disk encryption functionality within the kernel. This patch also includes a modification to enable LEA for use in fscrypt, another data-at-rest method available within the kernel, and a modification to blk-crypto-fallback to enable the "inlinecrypt" mount option in fscrypt. The Gooroom platform is a government-driven Debian-based Linux distribution in South Korea. In Korea, there are many crypto companies that want to bundle Linux into their products and sell them. They create their own Gooroom platforms by modifying the original Gooroom platform for their services. (Of course, the Gooroom platform is not mandatory, and companies wishing to use Linux are free to choose an appropriate distribution.) BTW, in Korea, many crypto companies want to use LEA, because LEA is one of the block ciphers of the KCMVP, a validation program for commercial crypto S/W to be delivered to the Korean government. The Linux Crypto API already has another Korean block cipher, ARIA, also one of the block ciphers of the KCVMP. However, LEA is more widely used than ARIA in industry nowadays, because LEA is one of the lightweight cryptography standard of ISO/IEC [2] and performs well on low-end devices that support 32-bit operations. So we think they are complementary to each other. In general, it's obvious that the hardware-accelerated AES is the best performer. However, there exist not only environments where the hardware-accelerated AES is not supported, but also situations where AES is not preferred for various reasons. In these cases, if someone wants to encrypt using a block cipher, LEA could be an alternative. There are also SIMD implementations for efficiently using LEA, which is not included in this patch. We have SSE2 and AVX2 assembly implementations, some of which were included in the previous version of the patch. The SIMD implementations are being re-implemented to support a wider range of environments. Apart from this, we also have implemented LEA in lightweight environments such as 8-bit AVR, 16-bit MSP and 32-bit ARM [4]. If LEA were to be included in the Linux kernel, it would be possible to modify and supplement the submission with lightweight implementations to provide efficient encryption on embedded linux devices. Although the designers of LEA did not provide test vectors in their paper [5], the ISO/IEC standard [2] and the KS standard [1] do. Furthermore, the Block Cipher LEA Specification("블록암호 LEA 규격서", written in Korean) document on the LEA introduction page [6] and the Wikipedia article on LEA [7] show the same test vectors as in the standards. The test vectors for ECB, CBC, CTR, and GCM modes included in the testmgr module are taken from the KCMVP Cryptographic Algorithm Verification Criteria V3.0("KCMVP 검증대상 암호알고리즘 검증기준 V3.0", written in Korean) [8]. Test vectors for the XTS mode were generated by ourselves, and we crosschecked them using Crypto++ [9] and testmgr on Linux. The implementation has been tested with kernel module tcrypt.ko and has passed the selftest using above-mentioned test vectors. It also has been tested with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS. The fscrypt patch was tested using a modified tool by forking https://github.com/google/fscrypt. [1] KS X 3246, 128-bit block cipher LEA. [2] ISO/IEC 29192-2:2019, Information security — Lightweight cryptography — Part 2: Block ciphers. [3] https://github.com/gooroom https://www.gooroom.kr/ [4] https://github.com/cryptolu/FELICS/tree/master/block_ciphers/source/ciphers/LEA_128_128_v01/source [5] Hong, Deukjo, et al. "LEA: A 128-bit block cipher for fast encryption on common processors.", WISA 2013. [6] https://seed.kisa.or.kr/kisa/algorithm/EgovLeaInfo.do [7] https://en.wikipedia.org/wiki/LEA_(cipher) [8] https://seed.kisa.or.kr/kisa/kcmvp/EgovVerification.do [9] https://www.cryptopp.com/ Changelog: v3: - Added implementations to enable LEA in fscrypt and blk-crypt. v2: - Reimplemented the Generic C implementation as a Loop version. - The decryption code was adapted from an optimized implementation by Eric Biggers. https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/commit/?h=old/wip-lea&id=1d1cbba14380f8a1abc76baf939b9e51de047fb6 - Removed AVX2 SIMD implementation. - Added comments for functions. - Improved the description in Kconfig. - Added test vectors from the standard documentation. Dongsoo Lee (4): crypto: LEA block cipher implementation crypto: add LEA testmgr tests blk-crypto: Add LEA-256-XTS blk-crypto support fscrypt: Add LEA-256-XTS, LEA-256-CTS support Documentation/filesystems/fscrypt.rst | 12 + block/blk-crypto.c | 6 + crypto/Kconfig | 18 + crypto/Makefile | 1 + crypto/lea_generic.c | 410 ++++++++ crypto/tcrypt.c | 73 ++ crypto/testmgr.c | 32 + crypto/testmgr.h | 1241 +++++++++++++++++++++++++ fs/crypto/fscrypt_private.h | 2 +- fs/crypto/keysetup.c | 15 + fs/crypto/policy.c | 4 + include/crypto/lea.h | 44 + include/linux/blk-crypto.h | 1 + include/uapi/linux/fscrypt.h | 4 +- tools/include/uapi/linux/fscrypt.h | 4 +- 15 files changed, 1864 insertions(+), 3 deletions(-) create mode 100644 crypto/lea_generic.c create mode 100644 include/crypto/lea.h