lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230428231952.GA3150@sol.localdomain>
Date:   Fri, 28 Apr 2023 16:19:52 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Dongsoo Lee <letrhee@....re.kr>
Cc:     linux-crypto@...r.kernel.org,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        "David S. Miller" <abc@...t.nsr.re.kr>,
        Dongsoo Lee <letrhee@...il.com>
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/20180507232000.GA194688@google.com), 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ