[147414] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

[Cryptography] Linux /dev/random and /dev/urandom

daemon@ATHENA.MIT.EDU (Isaac Bickerstaff)
Tue Oct 1 14:53:56 2013

X-Original-To: cryptography@metzdowd.com
Date: Tue, 01 Oct 2013 11:10:24 -0700
From: Isaac Bickerstaff <jsd@av8n.com>
To: cryptography@metzdowd.com
In-Reply-To: <20130930162837.582BA228EF8@palinka.tinho.net>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

On 09/30/2013 09:28 AM, dan@geer.org wrote:

> If there is anything I've learned about "the Internet" it is that
> if you ask a difficult question you will get very little in the
> way of answers you can trust a priori.  However, if you make a false
> claim, then people will come out of the woodwork to tell you that
> "You are a doofus and here is why."

That reminds me of the Linux device driver for /dev/random and 
/dev/urandom.

We know it is highly reliable, because it is used for a wide 
range of critical applications, and nobody would use it if it
weren't reliable.  Users -- as well as kernel developers -- 
are all keenly aware of how much modern cryptography depends 
on random numbers ... and how much security depends on attention 
to detail.

We know it is a "strong" RNG, because it says so, right at the 
top of the file, the drivers/char/random.c file.  Therefore there
is no need for anybody to review the code, let alone measure its
performance under real-world conditions.

I'm sure the driver was written by highly proficient cryptographers,
and subjected to a meticulous code review.

There is no way the code could have bugs that waste entropy.  There
is no way the code could have bugs that waste buffer capacity,
degrading the response to peak demand.  There is no way a variable
could be used with one undocumented meaning and then used with a
different undocumented meaning a few lines later.  There is no 
way anybody would ever create a PRNG with no lower bound on how
often it gets reseeded.

I haven't looked at the code -- heaven forbid -- but it "must" 
be well commented, in accordance with the high standards found 
throughout the kernel.

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

home help back first fref pref prev next nref lref last post