Make a unique filesystem path, without creating the file

[Steven D'Aprano]

On Thursday 25 February 2016 17:54, Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python at pearwood.info>:
> 
>> On Wednesday 24 February 2016 18:20, Marko Rauhamaa wrote:
>>> Steven D'Aprano <steve at pearwood.info>:
>>>> And that is where you repeat something which is rank superstition.
>>> 
>>> Can you find info to back that up.
>>
>> The links already provided go through the evidence. For example, they
>> explain that /dev/random and /dev/urandom both use the exact same
>> CSPRNG.
> 
> A non-issue. The question is, after the initial entropy is collected and
> used to seed the CSPRNG, is any further entropy needed for any
> cryptographic purposes?

The short answer: "yes".

The long answer: "probably not, but it can't hurt".

The longer answer: "probably not, and it usually won't hurt, but it could".

If, somehow, an attacker manages to work out the state of your CSPRNG, 
including the entropy pool, then they can predict what values you get until 
they no longer know the state of the CSPRNG. The idea is that if, somehow, 
somebody knows the current state of the CSPRNG (including the entropy pool), 
but can't influence what future values go into the entropy pool, then they 
will only be able to predict the output values for a short time.

But it's hard to think of any actual attack where somebody can see what's in 
the entropy pool but can't influence the values going into it. It seems to 
me that this is an unrealistic attack:

"Assume that you're kidnapped by somebody with no arms or legs..."

The conventional wisdom is that adding poor sources of entropy into the pool 
will never hurt, but that is actually wrong. If an attacker knows what is in 
the entropy pool, and can craft the values going in, they can force the 
CSPRNG to return more predictable values. So sometimes adding more entropy 
can hurt. And it usually won't help. It *might* help if your system is 
compromised, but if so, it's not really clear how the attacker has 
compromised your current entropy pool but not the future ones.


> Are there any nagging fears that weaknesses
> could be found in the deterministic sequence?

Of course there are. Nobody really knows what capabilities the NSA have, but 
they almost surely aren't *that* advanced. CSPRNGs are subject to much the 
same sort of issues as other crypto, such as hash functions:

http://valerieaurora.org/hash.html

and encryption algorithms. (The main real difference between a hash function 
and encryption algorithm is that hashes don't have to be reversible.)

Expect the current crop of CSPRNGs (Yarrow, AES, whatever Linux uses) to be 
replaced long before there is a proven attack on them.


> /dev/random is supposed to be hardened against such concerns by stirring
> the pot constantly (if rather slowly).

As is /dev/urandom.


> Here's what Linus Torvalds said on the matter years back:
> 
>    > No, it says /dev/random is primarily useful for generating large
>    > (>>160 bit) keys.
> 
>    Which is exactly what something like sshd would want to use for
>    generating keys for the machine, right? That is _the_ primary reason
>    to use /dev/random.
> 
>    Yet apparently our /dev/random has been too conservative to be
>    actually useful, because (as you point out somewhere else) even sshd
>    uses /dev/urandom for the host key generation by default.
> 
>    That is really sad. That is the _one_ application that is common and
>    that should really have a reason to maybe care about /dev/random vs
>    urandom. And that application uses urandom. To me that says that
>    /dev/random has turned out to be less than useful in real life.
> 
>    Is there anything that actually uses /dev/random at all (except for
>    clueless programs that really don't need to)?

Most other Unixes have decided that /dev/random is unnecessary, and urandom 
is the right thing to do. SSH uses urandom by default, but allows the 
paranoid/clueless to use /dev/random if they insist. 



-- 
Steve