On 2015-09-25 16:24, Theodore Ts'o wrote:
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: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.
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.
smime.p7s
Description: S/MIME Cryptographic Signature
