linux-kernel - Re: Replace /dev/random input mix polynomial with Brent's xorgen?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131216003253.GC7790@athena.dialup.mit.edu>
Date:	Sun, 15 Dec 2013 19:32:53 -0500
From:	Greg Price <price@....EDU>
To:	George Spelvin <linux@...izon.com>
Cc:	tytso@....edu, linux-kernel@...r.kernel.org
Subject: Re: Replace /dev/random input mix polynomial with Brent's xorgen?

On Sun, Dec 15, 2013 at 05:09:10PM -0500, George Spelvin wrote:
> Well, /dev/urandom is documented as being *deliberately* slow.  It's meant
> only to produce 128 to 256 bits of seed material for CPRNG.  I don't
> know if Ted considers speeding it up to be goal or an antigoal. :-)

Hmm, I don't think I've seen that documentation.  I don't see anything
about that point in the comments of drivers/char/random.c.  The
urandom(4) man page says /dev/urandom "is designed for security, not
speed, and is poorly suited to generating large amounts of random
data."  Which is quite different from being designed for slowness!

The great thing about the state of cryptography in 2013 is that we
don't have the kind of tradeoff between speed and security that we had
in the past.  Skein and Salsa20 and some other hashes and ciphers from
within the past decade are all very fast, and they've also been
attacked hard by cryptanalysts (motivated by competitions), and held
up very well.  From my understanding of the literature, moving to
either one from our current SHA-1-based scheme would only increase the
level of confidence one should have in the security of the random driver.

I think it would be great to be able to change the documentation to
"is designed for security and is also very fast and well suited to
generating large amounts of random data".  Users are always tempted by
speed, and if we can reduce that temptation by making our CSPRNG
faster (and still secure), it will be good for security.

> BTW, if it helps on 32-bit platforms I can get you rotate constats for
> a 32-bit version of threefish.  I haven't generated a key scheduling
> constant, though.

Interesting.  So, the generic Skein implementations in the SUPERCOP
testing/benchmarking suite are about four times slower on x86_32 than
x86_64.  Which means Skein should still be about 6x faster than the
current /dev/urandom implementation, but it'd be nice to be faster
still.  I imagine the same rough comparisons will hold on other 64-bit
and 32-bit architectures, though the gap between x86_32 and x86_64 is
probably wider because of the scarcity of registers on x86_32.

I wouldn't want to compromise on security to do it, though.  My
confidence in Skein/Threefish's security comes mostly from the SHA-3
competition, where many expert cryptanalysts attacked it and didn't
get very far except in understanding why it seems to be hard to break.
To make, or even evaluate, a 32-bit variant of Threefish seems like
it'd require much deeper understanding of the design of Threefish and
its cryptanalysis than I've tried to develop.  How do you plan to
evaluate the security of your 32-bit Threefish?

Regards,
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/