lkml.org 
[lkml]   [2015]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/3] Make /dev/urandom scalable
From
Date
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
> acceleration.
>
> 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
> generator.
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.

[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2015-09-29 14:21    [W:0.082 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site