Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Dongsoo Lee <letrhee@nsr.re.kr>
To:     'Eric Biggers' <ebiggers@kernel.org>
Cc:     'Herbert Xu' <herbert@gondor.apana.org.au>,
        linux-crypto@vger.kernel.org, davem@davemloft.net,
        linux-kernel@vger.kernel.org, letrhee@gmail.com
References: <20230525121301.722682-1-letrhee@nsr.re.kr> <ZHh1H3yKPU68J7Uv@gondor.apana.org.au> <008d01d99518$33db63f0$9b922bd0$@nsr.re.kr> <20230602213946.GD628@quark.localdomain>
In-Reply-To: <20230602213946.GD628@quark.localdomain>
Subject: RE: [PATCH v2 0/2] crypto: LEA block cipher implementation
Date:   Fri, 9 Jun 2023 20:57:36 +0900
Message-ID: <005601d99ac9$954f0c70$bfed2550$@nsr.re.kr>
MIME-Version: 1.0
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQGzeUtGMegR59VrglJnt6HijaycHAEgJe7QAN4WbOYB+Jo+66+u6H7A
Content-Language: ko
Precedence: bulk


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.