Make a unique filesystem path, without creating the file

[Marko Rauhamaa]

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? Are there any nagging fears that weaknesses
could be found in the deterministic sequence?

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

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)?

   <URL: http://article.gmane.org/gmane.linux.kernel/47437>

> If you don't trust the CSPRNG, then you shouldn't trust it whether it comes 
> from /dev/random or /dev/urandom. If you do trust it, then why would you 
> want it to block? Blocking doesn't make it more random.

It might not make it more secure cryptographically, but the point is
that it should make it more genuinely random.

> That's not how it works. It just makes you vulnerable to a Denial Of
> Service attack.

Understood. You should not use /dev/random for any reactive purposes
(like nonces or session encryption keys).

> There's that myth about urandom being "less random" than random again,
> but even this guy admits that the difference is "extremely hard"
> (actually: impossible) to measure, and that CSPRNG's "work". Which is
> precisely why OpenBSD uses arc4random for their /dev/random and
> /dev/urandom, and presumably why he wants to bring it to Linux.

That's for the cryptographic experts to judge. CSPRNG's aren't always as
CS as one would think:

   In December 2013, a Reuters news article alleged that in 2004, before
   NIST standardized Dual_EC_DRBG, NSA paid RSA Security $10 million in
   a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE
   cryptography library, which resulted in RSA Security becoming the
   most important distributor of the insecure algorithm.

   <URL: https://en.wikipedia.org/wiki/Dual_EC_DRBG>

> The bottom line is, nobody can distinguish the output of urandom and
> random (apart from the blocking behaviour). Nobody has demonstrated
> any way to distinguish the output of either random or urandom from
> "actual randomness". There are theoretical attacks on urandom that
> random might be immune to, but if so, I haven't heard what they are.

What I'm looking for is a cryptography mailing list (or equivalent)
giving their stamp of approval. As can be seen above, NIST ain't it.

It seems, though, that cryptography researchers are not ready to declare
any scheme void of vulnerabilities. At best they can mention that there
are no *known* vulnerabilities.

> What evidence do they give that /dev/urandom is weak? If it is weak,
> why are they using it as the default?

It's a big mess, but not a mess I would disentangle. Once the crypto
libraries, utilities, facilities and the OS come to a consensus, I can
hope they've done their homework. As it stands, the STRONG vs VERY
STRONG dichotomy seems to be alive all over the place.


Marko