undefined | Better HN

0 pointsahh9y ago0 comments

The biggest problem with "always use /dev/urandom" is that the kernel developers themselves--wrongly--think that this problem is more difficult than it is, and think that you shouldn't do just that.

This manifests in issues like scalability: some patches were merged to (slightly) improve scalable performance of /dev/urandom...and these were phrased as "Sure, we can do this, because idiots might want that and it costs us little--but we should emphasize this sort of thing isn't an actual supported feature!"

The people who maintain /dev/urandom aren't stupid, but for some reason they really don't seem to get (or agree with at least) your argument. I'd really like to understand why; I don't.

(I am technically a linux developer--I work on the kernel we use internally, and have actual patches to my name upstream--but am not a deep part of the external community.)

0 comments

2 comments · 1 top-level

tptacek9y ago· 1 in thread

T'so is simply wrong. I don't know that it's worth going into any more detail than that. You can look to threads on HN where he's commented about the utility of weak and strong random to see that concerns simply aren't rooted in cryptographic reality. He is simply not a cryptographer.

Meanwhile, teams of people who are cryptographers of world renown, such as the Bernstein, Lange, and Schwabe team that designed and implemented Nacl, just use urandom.

This case is closed. Use the system call interface by all means if it's available to you! But don't use userspace RNGs, like OpenSSL and GPG do, and don't use /dev/random.

ahhOP9y ago

Right! I agree with you! I'm saying that because T'so is wrong, that the kernel RNG, while still better than other options, will not be as good as it should or could be.

j / k navigate · click thread line to collapse