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

["George Spelvin" <linux@horizon.com>]

>> Well, /dev/urandom is documented as being *deliberately* slow.

> 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!

I guess the comment has evaporated.  I know it used to be there,
either in the source or old mailing list discussion.  However,
it's almost 20 years old now and I'm having a hard time tracking
down a source.

The comment wasn't, as the trailing :-) indicated, entirely serious.
There's no actual *problem* with making it faster, but I remember Ted
being very clear that he actually wanted to *discourage* people from
reading lots of data from it.

That's what I was alluding to.

> 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.

Absolutely.  No argument.

>> 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.

> 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?

The designers posted the search program they used to generate the rotation
constants, as part of proving there are no back doors.  They say in the
paper that a 32-bit version is possible, although they didn't generate
rotation constants.

Porting the program to 32 bits is a bit of a pain, as 64-bit assumptions
crept in all over, but it's not that hard.

As was pointed out in the competition, an attack on *any* fairly-random
set of threefish rotation constants would be alarming.  The set that was
chosen uses general principles for making a good choice, but if there
is some non-obvious criterion that can create a significant weakness,
that would be a major problem for the entire ARX structure.