Make a unique filesystem path, without creating the file

Marko Rauhamaa marko at
Tue Feb 23 14:04:15 EST 2016

Paul Rubin < at nospam.invalid>:

> Marko Rauhamaa <marko at> writes:
>> It is also correct that /dev/urandom depletes the entropy pool as
>> effectively as /dev/random. 
> I think see what's confusing you: the above is a misconception that is
> probably held by lots of people.  Entropy is not water and from a
> cryptographic standpoint there is essentially no such thing as
> "depleting" an entropy pool.  There is either enough entropy (say 256
> bits or more) in the PRNG or else there isn't.  If there's not enough,
> urandom can misbehave by giving you bad output because it doesn't block
> until more is gathered.  If there is enough, /dev/random misbehaves by
> blocking under this bogus concept of "depletion".

You are making my point. /dev/random is correct to block until
top-quality random numbers can be supplied. That's not misbehaving.

> So once /dev/random unblocks, it should never again block, the behavior
> of getrandom.

What you are saying is that /dev/random has no reason to exist (and the
GRND_RANDOM flag to getrandom() is redundant).

I'm no cryptographer and can't judge that. However, as long as the
distinction is maintained, I have to abide by the documented

> No really, all you've done is repeat bad advice. The people cited in
> that article are very knowledgeable and the stuff they say makes good
> mathematical sense. The stuff you say makes no sense and you haven't
> given any convincing reason for anyone to listen to you.

Thing is, neither you nor me nor the cited articles has provided any
more info than insisting on a position, my position being relying on the
documented API.

So we have

 * /dev/urandom vs /dev/random

 * getrandom(0) vs getrandom(GRND_RANDOM)

 * GCRY_STRONG_RANDOM ("Use this level for session keys and similar
   purposes") vs GCRY_VERY_STRONG_RANDOM ("Use this level for long term
   key material") (in libgcrypt)

You don't need to convince me that that distinction is silly. You need
to convince the crypto facility providers.


More information about the Python-list mailing list