Messages in this thread | | | Subject | Re: [PATCH 1/3] Make /dev/urandom scalable | From | Austin S Hemmelgarn <> | Date | Tue, 29 Sep 2015 08:06:11 -0400 |
| |
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] | |