HN Hall of Fame Weekly email

Myths about /dev/urandom

Screenshot of www.2uo.de captured 2026-07-20
Page preview · captured 2026-07-20

The originally submitted URL now redirects to the address above. Updating the destination does not change the item’s HN history, Hall membership, or rank.

Resurfaced independently across 7 calendar years, with breakout response in 5 of them.

submissions
12
submitters
12
observed span
2014–2026
peak thread · 171 comments
232 pts
latest 20+ return · 2026-05-14
89 pts

Submission timeline

2007–2026

One slot for every year since HN launched. Height is that year's peak points; orange marks a 100+ point or 50+ comment breakout. Select a bar to open its strongest thread.

First comments on top threads

HN comment order

Could someone explain DJB's point to me: Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that (1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but (2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what…

bredman·232-point thread·

I've given up on the hope that these myths will ever die. Every time it's relevant, someone pipes up complaining urandom isn't safe for use, or will run out of entropy. Have a look at the bugs for Node, Ruby and Wordpress. And inevitably, the appeal to authority ends up referring to these projects. Serious question, if I submitted a patch for the man page detailing the content of this myths page, is there a chance it might go somewhere…

Why hasn't someone qualified re-written that unix man page by now? I've been reading cryptographers trying to explain all of this for a while now. I feel like that would help put a lot of this to rest and save everyone time.

po·186-point thread·

(disclaimer I sell a HW random number generator) I think both the diagrams here are simplistic - in reality pre 4.8 there were 3 pools (an input pool and 2 output pools, one of which blocked) and post 4.8 where there are 2 pools, an input pool and a blocking pool (urandom now pulls from the input pool thru a CSPRNG). One big downside of the new (post 4.8) architecture is that urandom_min_reseed_secs is ignored - pre-4.8 you could ask…

Taniwha·80-point thread·

The first top-level comment from each of the four biggest threads, in HN’s own order. Excerpts are shortened; open a comment for full context.

Breakout years
5

100+ points or 50+ comments

Total points
869

reference only — not used in Hall rules or ranking

Total comments
534

reference only — not used in Hall rules or ranking

Every submission

DateTitle as submittedByPointsComments
2014-03-07Myths about /dev/urandomFirst breakout · Best threadTomte232171
2015-03-22Myths about /dev/urandomTsiolkovsky10
2015-05-23Myths about /dev/urandomalanfranzoni10
2015-08-31Myths about /dev/urandompetrosagg186106
2017-01-06Myths about /dev/urandom (2014)Hall inductionIvoah201104
2018-05-02Myths about /dev/urandomgeorgecmu20
2018-08-17Myths about /dev/urandom (2014)mindcrime8068
2019-11-26Myths about /Dev/Urandomlunchbreak30
2020-02-10Myths about /Dev/Urandomingve50
2020-03-23Myths about /dev/urandomCraneWorm20
2020-03-25Myths about /dev/urandom (2014)labguy6735
2026-05-14Myths about /dev/urandomLatest 20+ point returnsigna118950