Message-ID: <003801d9a029$b89228b0$29b67a10$@nsr.re.kr>
Date:   Fri, 16 Jun 2023 17:08:23 +0900
From:   Dongsoo Lee <letrhee@....re.kr>
To:     'Eric Biggers' <ebiggers@...nel.org>
Cc:     'Herbert Xu' <herbert@...dor.apana.org.au>,
        linux-crypto@...r.kernel.org, davem@...emloft.net,
        linux-kernel@...r.kernel.org, letrhee@...il.com
Subject: RE: [PATCH v2 0/2] crypto: LEA block cipher implementation


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.

Powered by blists - more mailing lists