
A good idea with bad usage: /dev/urandom - mr_tyzic
http://insanecoding.blogspot.com/2014/05/a-good-idea-with-bad-usage-devurandom.html
======
stouset
Can we please stop cargo-culting the "fact" that /dev/random outputs raw
entropy while /dev/urandom is the output of a CSPRNG? They are _both_ outputs
from the _same_ CSPRNG algorithm[1].

Edit: I'm eagerly awaiting the tptacek takedown of this article. Comments like
"even a regular user can run: cat /dev/random > /dev/null & cat /dev/zero >
/dev/random... entropy will be degraded" do not give me confidence in this
guy's understanding of the systems involved. Same with his blatant misreading
of RNDZAPENTCOUNT and RNDCLEARPOOL, which simple research[2] reveals only
clears the entropy _count_ and does nothing to the underlying entropy pool
itself.

[1]: [http://www.2uo.de/myths-about-urandom/](http://www.2uo.de/myths-about-
urandom/)

[2]:
[http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1468)

~~~
SAI_Peregrinus
Especially because /dev/random's ability to block when it doesn't have enough
entropy is dependent on accurate entropy estimation. Since the entropy
estimator isn't accurate (it can't be, it's an undecidable problem) there will
be attacks possible on the entropy estimator, either causing it to block when
it shouldn't (DOS) or output data with insufficient entropy.

------
davrosthedalek
I might be mistaken, but doesn't changing /dev nodes require super user
rights? If an attacker has those, he could simply overwrite your libressl
binary. Or patch the kernel. Or....

~~~
poizan42
Yes:

    
    
       EPERM  mode requested creation of something other than a regular
                  file, FIFO (named pipe), or UNIX domain socket, and the caller
                  is not privileged (Linux: does not have the CAP_MKNOD
                  capability); also returned if the filesystem containing
                  pathname does not support the type of node requested.
    

Of course there is still the theoretical problem that you could be running in
a chroot where some unprivileged user has write access to the root and/or /dev
so that she can create symlinks or move files around there. I don't think that
should be the responsibility of the library to defend against though; but the
responsibility of whoever created that chroot dir...

~~~
davrosthedalek
I agree, but it's really theoretical: If the user has write access to the
chroot environment, she can just replace the binary or play tricks with the
libraries. No way the (then not even run) binary can defend against that.
Didn't try it, but I would guess that subverting crypto is /slightly/ easier
if you can run your own code instead of just manipulating the random seeds.

------
truantbuick
Lots of errors in this article. It particularly rankles my sensibilities when
he says randomness doesn't actually exist and it's just when humans can't
track all the variables.

Randomness is much more interesting than that, and while it would make a lot
more sense for the sake of classical mechanics, it cannot possibly be
explained away so neatly according to Bell's Inequality.

~~~
davrosthedalek
Bell's inequality (plus the corresponding measurements) only rule out _local_
hidden variable theories. But yes, that paragraph was a low point.

~~~
truantbuick
I didn't imply otherwise.

I just didn't explicitly mention global variables because that will always
remain a possibility that lurks over everything. Technically, we can never
rule them out because it's possible that all the universe and all the events
of universe were preordained by one massive global variable, without any
particular rhyme or reason for rules and laws for mechanics of local behavior.

~~~
davrosthedalek
Oh yeah, absolutely. I just wanted to mention it because not everybody might
be aware of it. I doubt the blog author had that in mind anyway.

------
PhantomGremlin
The second paragraph of the article is fundamentally wrong:

    
    
       Now randomness doesn't really exist. When we humans see
       something as random, it's only because we don't know or
       understand all the details. Therefore, any perceived
       randomness on your part is your inability to track all
       the variables.
    

(The currently accepted explanation of) quantum mechanics says otherwise. The
essence of quantum mechanics is not certainly but _probability_. But this
annoyed even Einstein, who famously said "God does not throw dice". Einstein
was (probably) wrong about this.

Stephen Hawking says:

    
    
       God does play dice with the universe. All the evidence
       points to him being an inveterate gambler, who throws
       the dice on every possible occasion. [1]
    

[1] [http://www.hawking.org.uk/does-god-play-
dice.html](http://www.hawking.org.uk/does-god-play-dice.html)

------
yaur
The first issue he brings up seems legit. Whter it is exploitable or not
depends heavily on if an unprivileged account can trigger a read to
/dev/urandom to abort early by triggering an interrupt. I don't know Linux
internals well enough to know if this is the case, but since this is
documented behavior it seems reasonable to concede that there could be some
platform where its true.

Everything else seems specious. If you are in an environment controlled by an
attacker there is no case where you can reliably generate random numbers. Sure
as an attacker that already has root access I could replace /dev/urandom with
a link to /dev/zero, but why would I do that when I could just install a
kernel module that silently sent me whatever real random seed I decided to
give you or patch your process to send the keys that are the end product of
that randomness to my self?

