Don't mess with my random numbers

Posted Oct 25, 2015 5:29 UTC (Sun) by malor (guest, #2973)
In reply to: Don't mess with my random numbers by abatters
Parent article: Other approaches to random number scalability

I'm in this camp; I would rather see the existing interfaces left alone, and then a new /dev/frandom device provided for people who need mass quantities of semi-random bits. (like for disk wiping).

I presently use urandom for that, which I have just learned today is something I'm not supposed to be doing. That's fine, but I'd rather see a facility for doing what I'm doing (using a flood of semi-random data as a drive wiper), rather than seeing urandom weakened in any way.

Yes, I'm a urandom abuser, and probably deserve a hearty finger shake and a tsk or two, but I think trying to defend against scurrilous people like me, by changing the quality of the bits provided, could be a really severe hidden issue. People truly depend on that stuff, and it's quite possible that predictable output from /dev/urandom could end up killing someone. No hyperbole there.... if a repressive government known for mass surveillance is able to break into privileged communications that depended on the strength of /dev/urandom, both parties could be executed.

Further, it's going to be real hard to test from outside, and as a user of bits, you'd want some kind of signal that you were no longer getting ones with the same guarantee anymore. I don't even know how you'd do that. And writing test cases to make sure that it was doing what it was supposed to do, under all circumstances, would be very hard, and testing the heuristic 'only punish abusers' code would be almost impossible.

/dev/urandom is understood to not be as good as /dev/random, and people aren't *supposed* to use it for really important stuff, but they might be doing it anyway. I'd say preserving existing guarantees is probably more important than scalability. Rather, switch jerks like me to the ChaCha20 cipher with /dev/frandom. I'd be perfectly happy to switch (and could probably wipe drives a fair bit faster, to boot.)

That just seems safest on every front. The random pools are NOT things to screw around with lightly.

to post comments

Don't mess with my random numbers

Posted Oct 27, 2015 0:47 UTC (Tue) by eternaleye (guest, #67051) [Link]

> I presently use urandom for that, which I have just learned today is something I'm not supposed to be doing.

Not quite; "abuser" is being used very loosely on the ML.

> rather than seeing urandom weakened in any way.

Thinking that the proposed idea would weaken urandom is "correct" in the same way as thinking that because ZFS uses 128-bit sizing it's less likely to run out of space on your computer than ext4 which uses 64-bit sizing: the math is correct, but the actual expenditure needed to even approach it being _relevant_ is so unrealistic in terms of *physics* as to be laughable.

> People truly depend on that stuff, and it's quite possible that predictable output from /dev/urandom could end up killing someone.

Considering that ChaCha20 has exactly the same weight on its shoulders, this is again true but irrelevant. (If ChaCha20 is weak in a way that affects using it in urandom, then TLS is in a lot of trouble).

> Further, it's going to be real hard to test from outside, and as a user of bits, you'd want some kind of signal that you were no longer getting ones with the same guarantee anymore.

The *existing* Linux RNG is hard to test - incidentally, researchers did it anyway. Turns out it's an ad-hoc mess and makes *worse* guarantees than ChaCha20. Funny, that.

> /dev/urandom is understood to not be as good as /dev/random

Not only wrong, but *dead* wrong, and actively harmful, to the point of causing vulnerabilities to DOS and other attacks: see http://sockpuppet.org/blog/2014/02/25/safely-generate-ran...

Cryptographers have long-since come to the conclusion that entropy estimation _doesn't work_ worth a damn, and the only difference between /dev/urandom and /dev/random is that the latter blocks based on entropy estimation.