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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <560A7EB3.6070407@gmail.com>
Date:	Tue, 29 Sep 2015 08:06:11 -0400
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	Theodore Ts'o <tytso@....edu>, Jeff Epler <jepler@...ythonic.net>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	kirill.shutemov@...ux.intel.com, herbert@...dor.apana.org.au,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 1/3] Make /dev/urandom scalable

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.


Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)