Re: [PATCH 1/3] Make /dev/urandom scalable

From: Austin S Hemmelgarn
Date: Tue Sep 29 2015 - 08:06:24 EST

On 2015-09-25 16:24, Theodore Ts'o wrote:
On Fri, Sep 25, 2015 at 03:07:54PM -0400, Austin S Hemmelgarn wrote:

Interestingly, based on what dieharder is already saying about performance,
/dev/urandom is slower than AES_OFB (at least, on this particular system,
happy to provide hardware specs if someone wants).

Yeah, not surprised by that. We're currently using a crypto hash
instead of AES, which means we're not doing any kind of hardware

Crazy applications that want to spend 100% of the CPU generating
random numbers instead of you know, doing _useful_ work
notwithstanding, /dev/urandom never had high performance as one of its
design goals. The assumption was that if you needed that kind of
performance, you would use a user-space cryptographic random number
While I do understand that, it's abysmal performance compared to any of the others I tested. Part of the standard testing in dieharder is reporting how many random numbers it can source from the generator per second (it's some bit-width of integers, I just don't remember which). Here's the actual numbers I got:

AES_OFB| 1.11e+07
random-glibc2| 6.11e+07
mt19937| 3.30e+07
/dev/urandom| 6.53e+05

That much difference in speed is kind of interesting, and reinforces my statement that you should just use /dev/urandom for seeding other RNG's, just for a different reason than my original statement.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature