2023-04-28 23:21:41

by Eric Biggers

[permalink] [raw]
Subject: Re: [PATCH 0/3] crypto: LEA block cipher implementation

Hi Dongsoo,

On Fri, Apr 28, 2023 at 08:00:55PM +0900, Dongsoo Lee wrote:
> The Korean e-government framework contains various cryptographic
> applications, and KCMVP-validated cryptographic module should be used
> according to the government requirements. The ARIA block cipher, which
> is already included in Linux kernel, has been widely used as a symmetric
> key cipher. However, the adoption of LEA increase rapidly for new
> applications.
>
> By adding LEA to the Linux kernel, Dedicated device drivers that require
> LEA encryption can be provided without additional crypto implementation.
> An example of an immediately applicable use case is disk encryption
> using cryptsetup.
>
> The submitted implementation includes a generic C implementation that
> uses 32-bit ARX operations, and an optimized implementation for the
> x86_64 environment.

Can you elaborate further on the use case for this cipher? Your description
above is very vague. What is the actual use case when so many other ciphers
already exist, including much better studied ones? Are people being required to
use this cipher, and if so under what situations? There is also already another
"national pride" block cipher from Korea (ARIA); do we really need another one?

BTW, in 2018, I investigated LEA and various other ciphers as options for
storage encryption on ARM processors without the crypto extensions. We ended up
not selecting LEA for several different reasons (e.g. see
https://lore.kernel.org/r/[email protected]), and we later
created Adiantum for the use case. But, it sounds like "storage encryption on
processors without crypto instructions" isn't the use case you have in mind at
all anyway, seeing as the only assembly code you're providing is for x86_64.
What sort of use case do you actually have in mind? Is this perhaps a PhD
thesis type of thing that won't actually be used in a real world application?

IIRC, one of the issues with LEA was that the LEA paper doesn't provide test
vectors, so I couldn't be certain that I had actually implemented the algorithm
correctly. It sounds like there are now test vectors available. How confident
are you that they actually match the original algorithm?

> The implementation has been tested with kernel module tcrypt.ko and has
> passed the selftest using test vectors for KCMVP[4]. The path also test
> with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled.

There is a KASAN out-of-bounds error in lea_set_key() when running the
self-tests.

- Eric