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

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

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.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]