lkml.org 
[lkml]   [2020]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: drivers/char/random.c needs a (new) maintainer
On Wed, Dec 23, 2020 at 4:26 PM Stephan Mueller <smueller@chronox.de> wrote:
>
> Am Mittwoch, dem 23.12.2020 um 15:32 +0100 schrieb Jason A. Donenfeld:
> >
> > I would, however, be interested in a keccak-based construction. But
> > just using the keccak permutation does not automatically make it
> > "SHA-3", so we're back at the same issue again. FIPS is simply not
> > interesting for our requirements.
>
> Using non-assessed cryptography? Sounds dangerous to me even though it may be
> based on some well-known construction.

"assessed" is not necessarily the same as FIPS. Don't conflate the
two. I don't appreciate that kind of dishonest argumentation.

And new constructions that I'm interested in would be formally
verified (like the other crypto work I've done) with review and buy-in
from the cryptographic community, both engineering and academic. I
have no interest in submitting "non-assessed" things developed in a
vacuum, and I'm displeased with your attempting to make that
characterization.

Similarly, any other new design proposed I would expect a similar
amount of rigor. The current RNG is admittedly a bit of a mess, but at
least it's a design that's evolved. Something that's "revolutionary",
rather than evolutionary, needs considerably more argumentation.

So, please, don't strawman this into the "non-assessed" rhetoric.

\
 
 \ /
  Last update: 2020-12-23 16:37    [W:0.068 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site