A good idea with bad usage: /dev/urandom | Hacker News Reader

urandom

insanecoding.blogspot.com

30 pointsmr_tyzic14 comments

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/

[2]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

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.

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....

One or both of us is confused.

EDIT I was confused.

I think the OP is right. The first mistake he mentions is just not reading enough from urandom and thus falling back on unsecure values, which is just sloppy C. Then all the other attack scenarios require the ability to replace /dev/urandom in various insane ways (sparse actual files, symlinks, other devices). It all just seems pretty pointless. Just read /dev/urandom in a loop until you have enough and abort on any other case. That way you assure a secure result as long as the user has a sane environment and abort otherwise.

No kidding.

Talk about looking for problems that don't exist!

I guess that mentality is good in a crypto developer, but he took it to unnecessary extremes.

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...

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.

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.

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

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.

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.

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

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?

Reply on news.ycombinator.com