Hello. On Fri, 9 Jun 2023 19:14:50 -0700, Eric Biggers wrote: >Why are they having "great difficulties" when the kernel already supports two other "KCMVP-approved block ciphers", ARIA and SEED? Why aren't they using dm-crypt with ARIA or SEED? As you mentioned, the two KCMVP-approved block ciphers, ARIA and SEED, are supported by the kernel. Therefore, we can use dm-crypt with ARIA or SEED. However, LEA, being a relatively new algorithm, has distinct advantages over ARIA and SEED. LEA shows better performance, provides a clearer structure, and offers simpler implementation on SIMD, compared to ARIA and SEED. (Furthermore, SEED only provides up to 128-bit security.) Consequently, there are many products in Korea that use LEA as the default cipher. Considering these advantages, vendors may add LEA to the kernel of the Linux distribution by themselves to develop Linux products that supports LEA. (Some vendors are known to have already attempted this. However, definitely not all vendors have the capability to do so.) Furthermore, supporting the most recent and efficient KCMVP-approved block cipher, LEA, may be very helpful for the vendors to promote their products. It would cause problems if each vendor implements LEA in the kernel on its own. It may lead to fragmentation in kernel implementations, potentially causing compatibility issues among vendors and posing challenges for system maintenance when faced with major kernel changes. In addition, the data-at-rest encryption market is just beginning to grow in South Korea. Therefore, vendors may prefer to use LEA as the default cipher for data-at-rest encryption, since it is the most recent and efficient one of the KCMVP approved block ciphers (as mentioned earlier) and they do not need to worry about the compatibility issues. Lastly, although LEA-XTS may not outperform AES-XTS or Adiantum, it is still worthwhile to add LEA to the kernel, as it can be implemented on various platforms that support SIMD instructions, and it is also an ISO/IEC standard lightweight cipher. On Fri, 9 Jun 2023 19:14:50 -0700, Eric Biggers wrote: >And does LEA (or SEED or ARIA) support in Linux actually solve that problem? >Just adding support for these algorithms to Linux does not mean that Linux automatically becomes a "KCMVP validated cryptographic module", right? Do you have a complete plan that would actually solve the claimed problem? As you said, simply adding support for LEA in the kernel doesn't automatically solve the problem. Of course, additional efforts are needed to solve it. As you may know, KCMVP validates cryptographic modules, which means that when KCMVP validates a Linux-based cryptographic module, it validates the entire module, not just the Linux kernel inside the module. To obtain validation for a product, vendors need to develop various tools that can be used for required testings and write down required documentations. If LEA becomes available in the Linux kernel, we plan to implement data-at-rest encryption using LEA on the previously mentioned Gooroom platform. Vendors can then use it as a reference. We will also develop backporting codes for several LTS kernels, enabling vendors to utilize LEA in the Linux distribution that their product runs on. Additionally, we will implement and provide the necessary tools for KCMVP validation. This series of efforts, starting with adding LEA to the kernel, will assist vendors in developing their own KCMVP-validated products, which means the problem can be solved. Thank you.
