All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Ondrej Mosnacek <omosnace@redhat.com>
Cc: linux-crypto@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Steve Capper <steve.capper@arm.com>,
	Milan Broz <gmazyland@gmail.com>
Subject: Re: [PATCH 0/6] crypto: aegis128 - add NEON intrinsics version for ARM/arm64
Date: Mon, 24 Jun 2019 09:56:42 -0700	[thread overview]
Message-ID: <20190624165641.GB211064@gmail.com> (raw)
In-Reply-To: <20190624073818.29296-1-ard.biesheuvel@linaro.org>

On Mon, Jun 24, 2019 at 09:38:12AM +0200, Ard Biesheuvel wrote:
> Now that aegis128 has been announced as one of the winners of the CAESAR
> competition, it's time to provide some better support for it on arm64 (and
> 32-bit ARM *)
> 
> This time, instead of cloning the generic driver twice and rewriting half
> of it in arm64 and ARM assembly, add hooks for an accelerated SIMD path to
> the generic driver, and populate it with a C version using NEON intrinsics
> that can be built for both ARM and arm64. This results in a speedup of ~11x,
> resulting in a performance of 2.2 cycles per byte on Cortex-A53.
> 
> Patches #1 .. #3 are some fixes/improvements for the generic code. Patch #4
> adds the plumbing for using a SIMD accelerated implementation. Patch #5
> adds the ARM and arm64 code, and patch #6 adds a speed test.
> 
> Note that aegis128l and aegis256 were not selected, and nor where any of the
> morus contestants, and so we should probably consider dropping those drivers
> again.
> 

I'll also note that a few months ago there were attacks published on all
versions of full MORUS, with only 2^76 data and time complexity
(https://eprint.iacr.org/2019/172.pdf).  So MORUS is cryptographically broken,
and isn't really something that people should be using.  Ondrej, are people
actually using MORUS in the kernel?  I understand that you added it for your
Master's Thesis with the intent that it would be used with dm-integrity and
dm-crypt, but it's not clear that people are actually doing that.

In any case we could consider dropping the assembly implementations, though.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Ondrej Mosnacek <omosnace@redhat.com>
Cc: Milan Broz <gmazyland@gmail.com>,
	Steve Capper <steve.capper@arm.com>,
	linux-crypto@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH 0/6] crypto: aegis128 - add NEON intrinsics version for ARM/arm64
Date: Mon, 24 Jun 2019 09:56:42 -0700	[thread overview]
Message-ID: <20190624165641.GB211064@gmail.com> (raw)
In-Reply-To: <20190624073818.29296-1-ard.biesheuvel@linaro.org>

On Mon, Jun 24, 2019 at 09:38:12AM +0200, Ard Biesheuvel wrote:
> Now that aegis128 has been announced as one of the winners of the CAESAR
> competition, it's time to provide some better support for it on arm64 (and
> 32-bit ARM *)
> 
> This time, instead of cloning the generic driver twice and rewriting half
> of it in arm64 and ARM assembly, add hooks for an accelerated SIMD path to
> the generic driver, and populate it with a C version using NEON intrinsics
> that can be built for both ARM and arm64. This results in a speedup of ~11x,
> resulting in a performance of 2.2 cycles per byte on Cortex-A53.
> 
> Patches #1 .. #3 are some fixes/improvements for the generic code. Patch #4
> adds the plumbing for using a SIMD accelerated implementation. Patch #5
> adds the ARM and arm64 code, and patch #6 adds a speed test.
> 
> Note that aegis128l and aegis256 were not selected, and nor where any of the
> morus contestants, and so we should probably consider dropping those drivers
> again.
> 

I'll also note that a few months ago there were attacks published on all
versions of full MORUS, with only 2^76 data and time complexity
(https://eprint.iacr.org/2019/172.pdf).  So MORUS is cryptographically broken,
and isn't really something that people should be using.  Ondrej, are people
actually using MORUS in the kernel?  I understand that you added it for your
Master's Thesis with the intent that it would be used with dm-integrity and
dm-crypt, but it's not clear that people are actually doing that.

In any case we could consider dropping the assembly implementations, though.

- Eric

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-06-24 16:56 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-24  7:38 [PATCH 0/6] crypto: aegis128 - add NEON intrinsics version for ARM/arm64 Ard Biesheuvel
2019-06-24  7:38 ` Ard Biesheuvel
2019-06-24  7:38 ` [PATCH 1/6] crypto: aegis128 - use unaliged helper in unaligned decrypt path Ard Biesheuvel
2019-06-24  7:38   ` Ard Biesheuvel
2019-06-24  7:59   ` Ondrej Mosnacek
2019-06-24  7:59     ` Ondrej Mosnacek
2019-06-24  8:01     ` Ard Biesheuvel
2019-06-24  8:01       ` Ard Biesheuvel
2019-06-24  7:38 ` [PATCH 2/6] crypto: aegis - drop empty TFM init/exit routines Ard Biesheuvel
2019-06-24  7:38   ` Ard Biesheuvel
2019-06-24  8:03   ` Ondrej Mosnacek
2019-06-24  8:03     ` Ondrej Mosnacek
2019-06-24  7:38 ` [PATCH 3/6] crypto: aegis - avoid prerotated AES tables Ard Biesheuvel
2019-06-24  7:38   ` Ard Biesheuvel
2019-06-24  8:13   ` Ondrej Mosnacek
2019-06-24  8:13     ` Ondrej Mosnacek
2019-06-24  7:38 ` [PATCH 4/6] crypto: aegis128 - add support for SIMD acceleration Ard Biesheuvel
2019-06-24  7:38   ` Ard Biesheuvel
2019-06-24  7:38 ` [PATCH 5/6] crypto: aegis128 - provide a SIMD implementation based on NEON intrinsics Ard Biesheuvel
2019-06-24  7:38   ` Ard Biesheuvel
2019-06-24 14:37   ` Ard Biesheuvel
2019-06-24 14:37     ` Ard Biesheuvel
2019-06-24  7:38 ` [PATCH 6/6] crypto: tcrypt - add a speed test for AEGIS128 Ard Biesheuvel
2019-06-24  7:38   ` Ard Biesheuvel
2019-06-24 16:56 ` Eric Biggers [this message]
2019-06-24 16:56   ` [PATCH 0/6] crypto: aegis128 - add NEON intrinsics version for ARM/arm64 Eric Biggers
2019-06-25 14:07   ` Ondrej Mosnacek
2019-06-25 14:07     ` Ondrej Mosnacek
2019-06-25 14:57     ` Ard Biesheuvel
2019-06-25 14:57       ` Ard Biesheuvel

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=20190624165641.GB211064@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=gmazyland@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=omosnace@redhat.com \
    --cc=steve.capper@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.