Thread by @RoigJV

@AaronToponce (1/n) Yeah, more stuff doesn't have AES-NI, and the spec cripples the performance anyway, so it doesn't matter.

There is an interesting discussion here (userspace rng vulns, urandom, etc) but first, here: research.jvroig.com/linuxrand/ Nutshell: 40 terabytes of randomness tested.

@AaronToponce (2/n) Link has pre-print (to be presented in 2 weeks) and raw results that contribute hard data for devs to see that, quality-wise, dev/urandom and /dev/random produce indistinguishable output. You'll see that Thomas Ptacek link cited in reference (sockpuppet link you posted)

@AaronToponce (3/n) A little more about the paper: it's of no value to cryptographers, as of course both random devices will produce randomness with similar characteristics; it's so that we can share hard quantitative data to devs in Stack asking "should I use /dev/random for better security?"

@AaronToponce (4/n) The answer, of course, is no, and that producing over 40TB of randomness in total, from both /dev/random and /dev/urandom, pretty much reveals the exact same random characteristics in their output. So that's that. Just mentioned that, so you know we're in the same boat.

@AaronToponce (5/n) Moving on to more interesting matters - why is there this concern? Even as I'm about to present that paper, a more recent Stack question popped up: security.stackexchange.com/questions/1860…

@AaronToponce (6/n) That question dealt with a more nuanced problem: /dev/urandom never blocks even when it should (very early in the boot process/startup), but /dev/random always blocks even when it doesn't have to. It's not about just the raw quality of randomness.

@AaronToponce (7/n) We know that sort of nuance is legit, because that's exactly what led to Heninger et all (2012) in factorable.net. In the age of containerized apps and deployments, legit to worry about it. Of course, the new getrandom() is best, but switching to it isn't simple.

@AaronToponce (8/n) I would argue that the real problem that underlies these difficulties is the problem of entropy collection. If it were trivial - and it could be - none of these things would have to happen. There wouldn't be a dev/random vs urandom debate.

@AaronToponce (9/n) There wouldn't be a concern about VMs, containers, etc. They can just reseed trivially. Heninger et al's "Mining Your Ps and Qs" wouldn't have happened, even for every embedded and headless device, if seeding & reseeding were trivial.

@AaronToponce (10/n) So from where I see things, the most urgent problem and the one that will actually cascade and fix almost all these other related problems, is a standard way to collect entropy that is also trivially triggerable at will.

@AaronToponce (11/n) That req't disqualifies things like keystrokes, mouse, network activity, etc - these are exactly the culprits in Heninger et al (2012). Entropy collection should be strong and reliable enough that even minimal human interaction is not required - good for embedded&headless

@AaronToponce (12/n) Of course, you'll know my answer, that was the other paper I sent months ago (to be presented in 2 weeks). It does not need human interaction. Works even on a lowly Arduino Uno (16MHz, with a poor 4-microsecond-precision timer), entropy throughput of ~3K bits/second

@AaronToponce (13/n) OK, so assuming we get to a future where entropy collection in all types of devices get standardized so that it needs 0 human interaction, we remove:
-/dev/random vs urandom issue
-VM/containerized apps entropy
-headless/embedded low-entropy concerns

@AaronToponce (14/n) If this standardized entropy collection is based on a CPU side channel like I propose, then we get the bonus of having backdoor/tamper-resistant algo for all types of devices, from Arduino Uno-sized devices to big iron servers.

@AaronToponce (15/n) Linux kinda made the issue more difficult with the whole urandom debacle and misleading manpage, something I deal with in the pre-print. Just my thoughts on the matter. Before we can move on from userspace RNG and trust, we gotta have entropy collection standardized.

@AaronToponce (16/n) Also, I asked about if OpenSSL added a personalization string as the NIST AES-CTR DRBG spec allows, because I was thinking maybe they combined OS randomness with their own. Looked at OpenSSL code before, don't want to again; once in my life is enough.

@AaronToponce (17/17) To close this ramble on randomness and devices, well, a trivial, standardized entropy collection will prevent a lot of the vulns we had, but devs making small mistakes due to language unfriendliness, like javascript wallets and such, will forever be with us.