[Resending because the email bounced back from all 3 mailing lists.
Sorry if you get this email twice]
Hi Eric et al.,
I know that this thread is already stale, and I'm sorry I couldn't join
earlier but maybe late is better than never. Allow me to first introduce
myself: my name is Tomer Ashur and
Hi Samuel,
On Thu, Apr 26, 2018 at 03:05:44AM +0100, Samuel Neves wrote:
> On Wed, Apr 25, 2018 at 8:49 PM, Eric Biggers wrote:
> > I agree that my explanation should have been better, and should have
> > considered
> > more crypto algorithms. The main difficulty is that we have extreme
> > pe
> Oh, OK, that sounds like something resembling Naor-Reingold or its
> relatives. That would work, but with 3 or 4 passes I guess it wouldn't
> be very fast.
It most resembles HCH mode https://eprint.iacr.org/2007/028 using two
passes of Poly1305, one pass of ChaCha20, and one invocation of a 128-
On Wed, Apr 25, 2018 at 8:49 PM, Eric Biggers wrote:
> I agree that my explanation should have been better, and should have
> considered
> more crypto algorithms. The main difficulty is that we have extreme
> performance
> requirements -- it needs to be 50 MB/s at the very least on even low-end
Hi Samuel,
On Wed, Apr 25, 2018 at 03:33:16PM +0100, Samuel Neves wrote:
> Let's put the provenance of Speck aside for a moment, and suppose that
> it is an ideal block cipher. There are still some issues with this
> patch as it stands.
>
> - The rationale seems off. Consider this bit from the c
Let's put the provenance of Speck aside for a moment, and suppose that
it is an ideal block cipher. There are still some issues with this
patch as it stands.
- The rationale seems off. Consider this bit from the commit message:
> Other AES alternatives such as Twofish, Threefish, Camellia, CAST6
On Tue, Apr 24, 2018 at 10:58:35PM +0200, Jason A. Donenfeld wrote:
> > Note that Linux
> > doesn't bow down to any particular standards organization, and it offers
> > algorithms that were specified in various places, even some with no more
> > than a
> > publication by the author. In fact, supp
Hi Jason,
On Tue, Apr 24, 2018 at 10:58:35PM +0200, Jason A. Donenfeld wrote:
> Hi Eric,
>
> On Tue, Apr 24, 2018 at 8:16 PM, Eric Biggers wrote:
> > So, what do you propose replacing it with?
>
> Something more cryptographically justifiable.
>
It's easy to say that, but do you have an actual
On Tue, Apr 24, 2018 at 12:11 PM, Jason A. Donenfeld wrote:
> Can we please not Speck?
>
> It was just rejected by the ISO/IEC.
>
> https://twitter.com/TomerAshur/status/988659711091228673
Yeah, but here was the reason given
(https://www.wikitribune.com/story/2018/04/20/internet/67004/67004/):
On Tue, 24 Apr 2018 at 13:58, Jason A. Donenfeld wrote:
> On Tue, Apr 24, 2018 at 8:16 PM, Eric Biggers wrote:
> > So, what do you propose replacing it with?
> Something more cryptographically justifiable.
I'm keen to hear recommendations here, if there are options we should be
considering I'd
Hi Eric,
On Tue, Apr 24, 2018 at 8:16 PM, Eric Biggers wrote:
> So, what do you propose replacing it with?
Something more cryptographically justifiable.
> outside crypto review, vs. the many cryptanalysis papers on Speck. (In that
> respect the controversy about Speck has actually become an ad
Hi Jason,
On Tue, Apr 24, 2018 at 06:11:26PM +0200, Jason A. Donenfeld wrote:
> Can we please not Speck?
>
> It was just rejected by the ISO/IEC.
>
> https://twitter.com/TomerAshur/status/988659711091228673
So, what do you propose replacing it with?
As I explained in the patch, the purpose of
Can we please not Speck?
It was just rejected by the ISO/IEC.
https://twitter.com/TomerAshur/status/988659711091228673
Hello,
This series adds Speck support to the crypto API, including the Speck128
and Speck64 variants. Speck is a lightweight block cipher that can be
much faster than AES on processors that don't have AES instructions.
We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an
option f
14 matches
Mail list logo