>>
>> 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.
>
>We don't add kernel algorithms without an in-kernel user.  Is there an
existing in-kernel user that can use this as is or are you going to add one?
>
>Thanks,

Our current goal is to encrypt with LEA in a data-at-rest environment.

One option we are considering is utilizing the `dm-crypt` module for disk
encryption. The `dm-crypt` module can use various ciphers provided by the
Linux Crypto API. By specifying the `lea-xts-plain` option in the
`cryptsetup` tool, it can immediately work without further modification.

Additionally, we are exploring the possibility of using `blk-crypto` for
encryption. Currently, the ciphers available for `blk-crypto` are
AES-256-XTS, AES-128-CBC-ESSIV, Adiantum, and SM4-XTS. We would like to add
LEA-256-XTS to these.

( https://github.com/torvalds/linux/blob/master/block/blk-crypto.c#L21 )

Instead of disk encryption, it is also possible to use `fscrypt` to encrypt
the file system for data-at-rest environments. `fscrypt` currently supports
AES-256-XTS, AES-256-CTS-CBC, AES-128-CBC-ESSIV, AES-128-CTS-CBC, SM4-XTS,
SM4-CTS-CBC, Adiantum, and AES-256-HCTR2.

( https://github.com/torvalds/linux/blob/master/fs/crypto/keysetup.c#L16 )

The above are what we will do with LEA.

Thank you.

On Fri, Jun 02, 2023 at 03:05:16PM +0900, Dongsoo Lee wrote:
> Additionally, we are exploring the possibility of using `blk-crypto` for
> encryption. Currently, the ciphers available for `blk-crypto` are
> AES-256-XTS, AES-128-CBC-ESSIV, Adiantum, and SM4-XTS. We would like to add
> LEA-256-XTS to these.
> 
> ( https://github.com/torvalds/linux/blob/master/block/blk-crypto.c#L21 )
> 
> Instead of disk encryption, it is also possible to use `fscrypt` to encrypt
> the file system for data-at-rest environments. `fscrypt` currently supports
> AES-256-XTS, AES-256-CTS-CBC, AES-128-CBC-ESSIV, AES-128-CTS-CBC, SM4-XTS,
> SM4-CTS-CBC, Adiantum, and AES-256-HCTR2.
> 
> ( https://github.com/torvalds/linux/blob/master/fs/crypto/keysetup.c#L16 )
> 

Currently the only user of blk-crypto is fscrypt.  So the above two paragraphs
are really talking about the same thing.

I haven't seen any patch that proposes adding LEA support to fscrypt.  Also, I'm
not sure that the information you've provided so far is sufficient motivation
for adding it to fscrypt.  I did recently allow another national pride cipher,
SM4, to be added to fscrypt, but that was only because a user said they were
being *required* to use SM4.  It's not clear that's the case for LEA.

- Eric

On Fri, 2 Jun 2023 14:39:46 -0700, Eric Biggers wrote:
> I haven't seen any patch that proposes adding LEA support to fscrypt.
> Also, I'm
> not sure that the information you've provided so far is sufficient
> motivation
> for adding it to fscrypt.  I did recently allow another national pride
> cipher,
> SM4, to be added to fscrypt, but that was only because a user said they
> were
> being *required* to use SM4.  It's not clear that's the case for LEA.

Hello,

We thought that having the dm-crypt module as an in-kernel user of this
patch is enough to apply it. Of course, it would have been better to include
fscrypt in the patch, as file system encryption is very important for
data-at-rest encryption along with disk encryption.

Unfortunately, currently, vendors trying to supply Linux-based data-at-rest
encryption products by utilizing the dm-crypt or the fscrypt modules to
government agencies or public institutions in Korea are experiencing great
difficulties.

According to Korean regulations, the data transmitted and stored by
government agencies and public institutions must be protected using KCMVP
validated cryptographic modules. (KCMVP, the Korean Cryptographic Module
Validation Program, is a Korean security accreditation program for
cryptographic modules, like the CMVP in the United States.) According to the
KCMVP, cryptographic modules that are to be adopted in government agencies
and public institutions are required to use the approved cryptographic
algorithms to encrypt data. As mentioned earlier, LEA, SEED, and ARIA are
the only KCMVP-approved block ciphers.

As you know, the best approach to performing data-at-rest encryption on
Linux is using kernel modules like dm-crypt or fscrypt. Therefore, applying
the proposed patch would be very beneficial for the vendors wanting to
supply Linux products to government agencies or public institutions in
Korea, since they must use the KCMVP-approved cryptographic algorithms such
as LEA.

We kindly request a positive response to enable the utilization of
data-at-rest encryption in such special circumstances, thereby improving
Korea's Linux environment.

Thank you.

On Fri, Jun 09, 2023 at 08:57:36PM +0900, Dongsoo Lee wrote:
> Unfortunately, currently, vendors trying to supply Linux-based data-at-rest
> encryption products by utilizing the dm-crypt or the fscrypt modules to
> government agencies or public institutions in Korea are experiencing great
> difficulties.

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?

> According to Korean regulations, the data transmitted and stored by
> government agencies and public institutions must be protected using KCMVP
> validated cryptographic modules.

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?

- Eric

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.