[cryptography] urandom vs random

Ben Laurie ben at links.org
Sat Aug 17 08:12:03 EDT 2013


On 17 August 2013 08:05, ianG <iang at iang.org> wrote:

> On 17/08/13 14:46 PM, Ben Laurie wrote:
>
>>
>>
>>
>> On 17 August 2013 06:01, ianG <iang at iang.org <mailto:iang at iang.org>>
>> wrote:
>>
>>     On 17/08/13 10:57 AM, Peter Gutmann wrote:
>>
>>         Nico Williams <nico at cryptonector.com
>>         <mailto:nico at cryptonector.com>**> writes:
>>
>>             It might be useful to think of what a good API would be.
>>
>>
>>         The problem isn't the API, it's the fact that you've got two
>>         mutually
>>         exclusive requirements, the security geeks want the (P)RNG to
>>         block until
>>         enough entropy is available, everyone else wants execution to
>>         continue without
>>         being blocked.  In other words a failure of security is
>>         preferred to a failure
>>         of functionality.  Until you resolve that conflict, no API
>>         (re)design is going
>>         to help you.
>>
>>
>>
>>     (not answering the posts sepcifically but) the rule of thumb I've
>>     always used is this:
>>
>>     If you don't care so much about security then use the tools that are
>>     provided, and suffer an occasional glitch.  Don't worry too much
>>     about the glitches coz your business already told you, you don't
>>     care too much about the security / randomness.  All those
>>     cypherpunkian arguments can go to hell, you've got customers to care
>>     for.
>>
>>     OTOH, if you care a lot, then you have to write your own.  The
>>     design is now very well established.  Many sources -> mixer/pool ->
>>     deterministic PRNG.  It's really not that hard, this is an intern
>>     level project, folks.
>>
>>     In result, if you care enough to argue about random v. urandom then
>>     you already put yourself in the second camp, and your problem is
>>     solved. Just use urandom and collect some other sources yourself.
>>       You no longer care.
>>
>>
>> That's terrible advice. Implement your own crypto of any sort widely
>> leads to complete fail, as we see repeatedly.
>>
>
>
> :)  Perhaps the distinction is that, if you care, when you "repeatedly
> fail" then you can repeatedly fix it.  OTOH, if you're using external
> crypto, you're up the creek without a paddle.


What "external" crypto can you not fix? Windows? Then don't use Windows.
You can fix any crypto in Linux or FreeBSD.


>
>
>
>  Also, if there are other sources, why are they not being fed in to the
>> system PRNG?
>>
>
>
> I agree in principle, but reality slaps us around a bit:
>
> Linux and BSD can't agree on the basic definitions of urandom and random.


So what? BSD's definition is superior. Linux should fix their RNG. Or these
people who you think should implement their own should. Or they could just
switch to BSD.


>  Some don't agree whether Intel's RNG is safe or not for Linux purposes.


All entropy feeds are safe.


>  Zooko & Jon don't agree whether open source is a sufficient / necessary
> proof.
>

Yet they're both selling it.


>
> And, as you say, FIPS don't agree with anyone:
>

Again: so what?


>
> > Amusing story: FIPS 140 requires self-tests on the PRNG. There was a
> > bug in FIPS OpenSSL once where the self-test mode got stuck on and so
> > no entropy was fed into the PRNG.
> >
> > Also, back when I was doing FIPS 140 they made me remove some of the
> > entropy feeds into the PRNG - particularly ones that protect against
> > pool duplication over forks.
>
>
>
>
>
> iang
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130817/6cab4e1c/attachment.html>


More information about the cryptography mailing list