Re: strengthening /dev/urandom

From: Paul Rubin (//phr.cx_at_NOSPAM.invalid)
Date: 08/20/04 

Date: 19 Aug 2004 16:39:10 -0700

Tom St Denis <tomstdenis@iahu.ca> writes:
> The output of /dev/random is actually the output of SHA-1. That
> makes it a PRNG.

Um, there's something missing here. /dev/random doesn't just run sha-1
and supply the output. It also supplies sha-1 with an INPUT. Generating
the input is the most important part of of what it does. The security
claim--whether correct or not--is that the input contains enough true
randomness to be useable for security apps.

> I never said there is zero entropy in the pool. I said making conclusions
> about the entropy in the pool is meaningless. There is no 100% answer to
> this problem. If you don't have an initial seed then the only way to get
> any security is to have some events. Wherether you estimate their entropy
> count or not you're still stuck at "until enough data comes in".

"Until enough data comes in" means "for some specific amount of time"
which depends on the rate of entropy collection. Computing that time
requires an entropy estimate.

Let me ask it in practical terms. Say some client comes to you with a
security problem. He needs to set up a box that runs some crypto
protocol that requires generating unguessable 128-bit keys. The
client knows you were involved in implementing the new Fortuna-based
/dev/random, so he wants your advice about generating keys with it.
You have to tell him one of the following:

  1) No, you should never trust /dev/random for secure keys; there's
     just no way to know if PC's create enough real entropy, so you
     better buy a hardware RNG. He's not happy, but he trusts your
     expertise so he goes and buys the hardware RNG. But if this is
     what you believe, why are you messing with /dev/random at all?

  2) Yes, you can use a PC and generate those keys with /dev/random.
     Just wait for N minutes after booting before reading /dev/random,
     and the output will be unguessable. He's happy with this and
     sets up his software to wait N minutes. But what is N? Any
     specific N implies an entropy estimate.

  3) You tell him "you have to wait until enough data comes in" but
     "making conclusions about the entropy in the pool is meaningless"
     so you won't tell him how long it takes for "enough data to come in".
     Of course if you tell him this, he fires you and hires someone who
     can supply him with concrete numbers that he can actually use.
     The work you're doing might be academically interesting, but it's
     useless for purposes of real-world engineering.

  4) Something else?

It seems to me that you're holding out for answer #3, the most
noncommittal and therefore useless answer.

Relevant Pages

  • Re: Fortuna
    ... I certainly agree that information-theoretic security is a stated goal ... >state collisions (therby reducing pool entropy). ... start with any entropy, then information-theoretically secure randomness ... extraction is impossible -- at least in principle. ...
    (Linux-Kernel)
  • Re: is this double CBC?
    ... You designed something that is not supposed to add to security, instead it is designed to consume entropy, and so significantly weakens security. ... and then you go on this completely seperate tangent about how i am destroying the security of AES and CBC and everything else under the sun because i am 'consuming entropy' which i know for a fact i am not. ...
    (sci.crypt)
  • Re: is this double CBC?
    ... ahhh but if it is not truly random then there is no real entropy. ... what you said "weakens security" the difference in words here is very ... village idiot can destroy that. ... that it weakens the security, simply for the sake of consuming computation ...
    (sci.crypt)
  • Re: is this double CBC?
    ... understand the difference between algorithm and implementation. ... the place of a cipher, and that it fails to meet the security requirements, therefore it is weak. ... if it was designed to work in place of a cypher, i wouldn't be using AES now would i. once again i will state, i didn't code the AES module, someone who knows cryptography better than i do coded it. ... You designed something that is not supposed to add to security, instead it is designed to consume entropy, and so significantly weakens security. ...
    (sci.crypt)
  • HTDig on the forum archive is borked
    ... another List to resolve my FreeBSD 5.3-RELEASE issue at startup. ... I'm all about security, believe me. ... everything basically fails because of the lack of entropy. ... Mount failures for one slice of a RAID ...
    (freebsd-questions)
Quantcast