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: <20131215220910.24012.qmail@science.horizon.com>
Date:	15 Dec 2013 17:09:10 -0500
From:	"George Spelvin" <linux@...izon.com>
To:	linux@...izon.com, price@....EDU, tytso@....edu
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Replace /dev/random input mix polynomial with Brent's xorgen?

> My draft patch series uses Skein/Threefish.  The authors conveniently
> specified a way to use it as a PRNG, and it's very fast without
> special hardware support (consequently, for all kinds of hardware.)
> On my laptop, reading from /dev/urandom becomes about 25 times faster
> for large reads, and about 40% faster for small reads where the
> syscall overhead is more important.

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

One thing i've thought about is adding a /dev/frandom, which is seeded
once at open time and then produces a "reasonably strong" large block of
cryptographic output, very quickly.  (Key size between 128 and 192 bits.)

I understand why Ted didn't do this in the first place, but the number
of people I see doing something like "cat /dev/urandom > /dev/sdx"
to test incompressible data is remarkable.

If the additional code is small, perhaps it's worth doing.

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