public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Dongsoo Lee <letrhee@nsr.re.kr>
Cc: linux-crypto@vger.kernel.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org,
	"David S. Miller" <abc@test.nsr.re.kr>,
	Dongsoo Lee <letrhee@gmail.com>
Subject: Re: [PATCH 0/3] crypto: LEA block cipher implementation
Date: Fri, 28 Apr 2023 16:19:52 -0700	[thread overview]
Message-ID: <20230428231952.GA3150@sol.localdomain> (raw)
In-Reply-To: <20230428110058.1516119-1-letrhee@nsr.re.kr>

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

  parent reply	other threads:[~2023-04-28 23:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-28 11:00 [PATCH 0/3] crypto: LEA block cipher implementation Dongsoo Lee
2023-04-28 11:00 ` [PATCH 1/3] " Dongsoo Lee
2023-04-28 23:29   ` Eric Biggers
2023-04-29  2:20     ` Letrhee
2023-04-28 11:00 ` [PATCH 2/3] crypto: add LEA testmgr tests Dongsoo Lee
2023-04-28 11:00 ` [PATCH 3/3] crypto: LEA block cipher AVX2 optimization Dongsoo Lee
2023-04-28 15:54   ` Dave Hansen
2023-05-16  4:29     ` Dongsoo Lee
2023-04-28 23:19 ` Eric Biggers [this message]
2023-05-16  4:27   ` [PATCH 0/3] crypto: LEA block cipher implementation Dongsoo Lee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230428231952.GA3150@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=abc@test.nsr.re.kr \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=letrhee@gmail.com \
    --cc=letrhee@nsr.re.kr \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox