Hacker News Reader

> Obviously I'm missing something here

For a start, there's a long tail of migrating all useful software to /dev/sane_random. Moreover, there's a risk new software accidentally uses the old broken /dev/random.

Besides, /dev/sane_random essentially exists; it's just a sysctl called getrandom().

View on HN

> Moreover, there's a risk new software accidentally uses the old broken /dev/random.

but that risk is at 100% NOW, how is it not worth reducing it?

I fully agree.

It's not that simple; Donenfeld wants to replace the whole LRNG with a new engine that uses simpler, more modern, and more secure/easier-to-analyze cryptography, and one of the roadblocks there is that swapping out the engine risks breaking bugs that userland relies on.

What kind of bugs are visible to userland? I would have thought a random number device would be the least likely thing to have upgrade problems like that: applications should not be able to assume anything at all since the output is literally random...

Shouldn't it be easier than a kernel parameter to compare the performance of specific applications that relied upon the current behaviors; at least for a major rev or two?

Reply on news.ycombinator.com