tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Patch: new random pseudodevice

On Fri, Dec 09, 2011 at 06:52:16PM +0200, Alan Barrett wrote:
> On Fri, 09 Dec 2011, Thor Lancelot Simon wrote:
> > An attacker who can break AES might be able to predict 
> > the future output of _one_ instance of the generator.  An 
> > attacker who can break AES and recover the key and defeat the 
> > backtracking resistance designed into CTR_DRBG *might* be able 
> > to recover the prior outputs of the generator for that user. 
> > An attacker who can do all these things *and* recover earlier 
> > entropy-pool output from later entropy-pool output (that is, do 
> > exactly what would have had to be done to break the old design) 
> > can recover keys provided by the generator to other users.  If 
> > he happens to know when exactly they were produced (time is an 
> > input to the algorithm), etc.
> Fair enough, but you still seem to be talking about how good a 
> CSPRNG it is, whereas my concern is that it's pseudorandom, nor 
> random.
> How many different bit streams of length 2^31 can be produced by 
> a generator that has a 128-bit key?  I think it's 2^128 different 
> pseudorandom bit streams of length 2^31.  If they were truly 
> random, then there would be 2^(2^31) of them.
> I still think it's not appropriate for /dev/random to output 
> pseudorandom bits (even cryptographically secure pseudorandom 
> bits) when it has historically output random bits (or at least 
> attempted to output random bits, modulo bugs, design mistakes, 
> etc.).

You are aware of the fact that 99.99% of computers don't have true
random number generators and the bits you claim that are random are not
random at all? They try to be unpredictable. CSPRNG have two roles: turn
few almost unpredictable bits that your machine can gather into many
cryptographically secure pseudo-random bits and to hide those almost
unpredictable bits from consumers.

Returning gathered entropy directly is very, very risky. For one, CSPRNG
output bits generated based on many entropy sources. If one of your
entropy source is for example time intervals between interrupts, an
attacker could provoke interrupts to occur at very predictable for him
intervals. If such entropy would be returned directly to /dev/random
consumer, it will be easly compromised. CSPRNG protects you from
situations when some of your entropy sources are controlled by an
attacker or broken (this is also valid for true random number
generators, which can simply break).

Pawel Jakub Dawidek             
FreeBSD committer               
Am I Evil? Yes, I Am!           

Attachment: pgpmSG7D7i73t.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index