From: Eric Biggers <ebiggers@kernel.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: linux-crypto@vger.kernel.org, linux-fscrypt@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
Paul Crowley <paulcrowley@google.com>,
Greg Kaiser <gkaiser@google.com>,
Michael Halcrow <mhalcrow@google.com>,
Samuel Neves <samuel.c.p.neves@gmail.com>,
Tomer Ashur <tomer.ashur@esat.kuleuven.be>,
stable@vger.kernel.org
Subject: Re: [PATCH] crypto: remove speck
Date: Mon, 6 Aug 2018 18:19:37 -0700 [thread overview]
Message-ID: <20180807011937.GA133621@gmail.com> (raw)
In-Reply-To: <20180806230437.21431-1-Jason@zx2c4.com>
Hi Jason,
On Tue, Aug 07, 2018 at 01:04:37AM +0200, Jason A. Donenfeld wrote:
> These are unused, undesired, and have never actually been used by
> anybody. The original authors of this code have changed their mind about
> its inclusion. Therefore, this patch removes it.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: stable@vger.kernel.org
For context, in your commit message can you include a link to my email
mentioning Android's Speck decision
(https://marc.info/?l=linux-crypto-vger&m=153359499015659)?
Also: "speck" => "Speck".
Also I think the fscrypt code points should be reserved so they don't
get reused for something else:
#define FS_ENCRYPTION_MODE_SPECK128_256_XTS 7 /* removed */
#define FS_ENCRYPTION_MODE_SPECK128_256_CTS 8 /* removed */
Otherwise:
Acked-by: Eric Biggers <ebiggers@google.com>
For the record, I think the statements Paul and I have made evaluating
Speck from a technical perspective remain substantially accurate.
However, clearly today there are more than just technical considerations
when choosing cryptographic primitives. So ultimately, enough people
didn't *want* Speck that we weren't able to offer it, even though it was
only meant to replace no encryption. We've also designed and proposed
an alternative solution for the ARMv7 disk encryption use case, HPolyC.
So given the above, and that I no longer know of any specific users of
the Speck code (so in principle it can still be removed without breaking
userspace), and that it's possible that similar considerations will make
Speck difficult for others to use, and that some people heavily object
to Speck being optionally supported in the kernel at all, I'm okay with
it being removed...
Thanks,
- Eric
next prev parent reply other threads:[~2018-08-07 1:19 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-06 22:32 [RFC PATCH 0/9] crypto: HPolyC support Eric Biggers
2018-08-06 22:32 ` [RFC PATCH 1/9] crypto: chacha20-generic - add HChaCha20 library function Eric Biggers
2018-08-06 22:32 ` [RFC PATCH 2/9] crypto: chacha20-generic - add XChaCha20 support Eric Biggers
2018-08-06 22:32 ` [RFC PATCH 3/9] crypto: chacha20-generic - refactor to allow varying number of rounds Eric Biggers
2018-08-06 23:16 ` Jason A. Donenfeld
2018-08-06 23:48 ` Paul Crowley
2018-08-07 0:15 ` Jason A. Donenfeld
2018-08-07 1:06 ` Paul Crowley
2018-08-07 10:21 ` Samuel Neves
2018-08-07 21:51 ` Eric Biggers
2018-08-08 0:15 ` Eric Biggers
2018-08-06 22:32 ` [RFC PATCH 4/9] crypto: chacha - add XChaCha12 support Eric Biggers
2018-08-06 22:32 ` [RFC PATCH 5/9] crypto: arm/chacha20 - add XChaCha20 support Eric Biggers
2018-08-06 22:32 ` [RFC PATCH 6/9] crypto: arm/chacha20 - refactor to allow varying number of rounds Eric Biggers
2018-08-06 22:32 ` [RFC PATCH 7/9] crypto: arm/chacha - add XChaCha12 support Eric Biggers
2018-08-06 22:32 ` [RFC PATCH 8/9] crypto: arm/poly1305 - add NEON accelerated Poly1305 implementation Eric Biggers
2018-08-07 12:09 ` Ard Biesheuvel
2018-08-07 23:19 ` Eric Biggers
2018-08-22 10:00 ` Ard Biesheuvel
2018-08-06 22:33 ` [RFC PATCH 9/9] crypto: hpolyc - add support for the HPolyC encryption mode Eric Biggers
2018-08-06 23:04 ` [PATCH] crypto: remove speck Jason A. Donenfeld
2018-08-07 1:03 ` Jeffrey Walton
2018-08-07 20:18 ` Eric Biggers
2018-08-07 1:19 ` Eric Biggers [this message]
2018-08-07 2:38 ` Jason A. Donenfeld
2018-08-07 3:12 ` Eric Biggers
2018-08-07 3:15 ` Theodore Y. Ts'o
2018-08-07 12:51 ` Ard Biesheuvel
2018-08-07 6:22 ` [PATCH v2] crypto: remove Speck Jason A. Donenfeld
2018-08-07 6:57 ` Ard Biesheuvel
2018-09-04 4:55 ` Herbert Xu
-- strict thread matches above, loose matches on Subject: below --
2018-04-24 16:18 [PATCH] " Jason A. Donenfeld
2018-04-24 18:24 ` Eric Biggers
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=20180807011937.GA133621@gmail.com \
--to=ebiggers@kernel.org \
--cc=Jason@zx2c4.com \
--cc=gkaiser@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhalcrow@google.com \
--cc=paulcrowley@google.com \
--cc=samuel.c.p.neves@gmail.com \
--cc=stable@vger.kernel.org \
--cc=tomer.ashur@esat.kuleuven.be \
/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;
as well as URLs for NNTP newsgroup(s).