Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Myths about /dev/urandom (2014)

2uo.de

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Myths about /dev/urandom (2014)

#31

Post by nothrabannosir »

vbezhenar wrote: post #27
matbess wrote: post #16

This article naturally leads to a question that I didn’t see addressed, perhaps you can answer it here: If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?

/dev/random is more secure than /dev/urandom because it blocks if there's not enough entropy. So if you want to generate private key, you should use /dev/random or you risk getting weak keys.

I'm so confused. I feel like literally every single point in the actual article is saying the exact opposite?

I find /dev/random frustratingly confusing.

Re: Myths about /dev/urandom (2014)

#32

Post by vbezhenar »

nothrabannosir wrote: post #31
vbezhenar wrote: post #27

Earlier quoted context omitted.

/dev/random is more secure than /dev/urandom because it blocks if there's not enough entropy. So if you want to generate private key, you should use /dev/random or you risk getting weak keys.

I'm so confused. I feel like literally every single point in the actual article is saying the exact opposite? I find /dev/random frustratingly confusing.

In low-entropy conditions (e.g. right after OS in VM has been installed) /dev/random is better but it might block (for minutes or hours). /dev/urandom is always issues some data, so your application won't hang because of it, but it might issue not very crypto strong bytes in those conditions. Best solution is to use hardware crypto or pass random data from host to VM or something like that. Also you might consider to use getrandom syscall. It's non-blocking if entropy pool has been initialized, otherwise it blocks (AFAIK the same as FreeBSD /dev/random). Probably the best of both worlds. That's how I understand the whole topic anyway.

Re: Myths about /dev/urandom (2014)

#33

Post by gpvos »

vbezhenar wrote: post #27
matbess wrote: post #16

This article naturally leads to a question that I didn’t see addressed, perhaps you can answer it here: If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?

/dev/random is more secure than /dev/urandom because it blocks if there's not enough entropy. So if you want to generate private key, you should use /dev/random or you risk getting weak keys.

After the system has been running for a few minutes, there is no difference in security between the two.

Re: Myths about /dev/urandom (2014)

#34

Post by brennebeck »

Taniwha wrote: post #5

(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-…

While I agree with what you’re saying, I think it should be pointed out that the author clearly states that it’s a simplistic model and even mentions the multiple pools briefly (though I’m unsure if that was add post-comment, as author is on hn also).

Re: Myths about /dev/urandom (2014)

#35

Post by gpvos »

vbezhenar wrote: post #32
nothrabannosir wrote: post #31

Earlier quoted context omitted.

I'm so confused. I feel like literally every single point in the actual article is saying the exact opposite? I find /dev/random frustratingly confusing.

In low-entropy conditions (e.g. right after OS in VM has been installed) /dev/random is better but it might block (for minutes or hours). /dev/urandom is always issues some data, so your application won't hang because of it, but it might issue not very crypto strong bytes in those conditions. Best solution is to use hardware crypto or pass random data from host to VM or something like that. Also you might consider to…

> That's how I understand the whole topic anyway.

This suggests that you're not an expert. Therefore, it is wise to just stick to what the experts write, in articles such as this. That's what I do. Cryptography is a very complex subject; non-experts who give advice without knowing exactly why they are saying what they're saying are contributing to the problem, so please avoid doing that.

Re: Myths about /dev/urandom (2014)

#36

Post by Tomte »

brennebeck wrote: post #34
Taniwha wrote: post #5

(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-…

While I agree with what you’re saying, I think it should be pointed out that the author clearly states that it’s a simplistic model and even mentions the multiple pools briefly (though I’m unsure if that was add post-comment, as author is on hn also).

No, the page hasn‘t been changed in quite some time. The last real change was the 4.8 change, long after 4.8 was out.

Re: Myths about /dev/urandom (2014)

#37

Post by Tomte »

gpvos wrote: post #35
vbezhenar wrote: post #32

Earlier quoted context omitted.

In low-entropy conditions (e.g. right after OS in VM has been installed) /dev/random is better but it might block (for minutes or hours). /dev/urandom is always issues some data, so your application won't hang because of it, but it might issue not very crypto strong bytes in those conditions. Best solution is to use hardware crypto or pass random data from host to VM or something like that. Also you might consider to…

> That's how I understand the whole topic anyway. This suggests that you're not an expert. Therefore, it is wise to just stick to what the experts write, in articles such as this. That's what I do. Cryptography is a very complex subject; non-experts who give advice without knowing exactly why they are saying what they're saying are contributing to the problem, so please avoid doing that.

Nota bene: I‘m not an expert, just quoting them. :-)

I used to be very confused, too, and after learning something about it, I wrote that page. Almost didn‘t finish and publish it when tptacek put his page up, but by that time I had already invested most of the effort, and I wanted to be less terse.

Re: Myths about /dev/urandom (2014)

#38

Post by semi-extrinsic »

nothrabannosir wrote: post #29
acqq wrote: post #24

Earlier quoted context omitted.

GPL 3.0 for a few obvious lines seems to be really an unfitting license. Non-licensed English language version, containing the same information: Once per second, read /proc/sys/kernel/random/entropy_avail and if the resulting number is more than 1500 perform a read of 1000 bytes from /dev/random.

(this is more of a tangential licensing PSA, since we're on the subject) Not licensing something is, ironically, restrictive. If you want to release to public domain (or equivalent), you have to explicitly mention that. E.g. by licensing under CC0. Otherwise, default copyright and "all rights reserved" applies. https://creativecommons.org/share-your-work/public-domain/cc... (But, IMO, nothing wrong with publicizing u…

I think GP is getting at something else. As the length/complexity of the code goes to zero, the copyright and "all rights reserved" vanishes; this is well established, or else we'd all have to license "Hello world" examples from Kernighan and Ritchie's book.

If someone writes the same one-sentence pseudocode as GP in a book or blogpost, nobody could reasonably claim that an implementation would fall under the copyright of that book. And I think you'd be very hard pressed to argue it's copyrightable just because someone typed it out into real code.

Re: Myths about /dev/urandom (2014)

#39

Post by gpvos »

Tomte wrote: post #37
gpvos wrote: post #35

Earlier quoted context omitted.

> That's how I understand the whole topic anyway. This suggests that you're not an expert. Therefore, it is wise to just stick to what the experts write, in articles such as this. That's what I do. Cryptography is a very complex subject; non-experts who give advice without knowing exactly why they are saying what they're saying are contributing to the problem, so please avoid doing that.

Nota bene: I‘m not an expert, just quoting them. :-) I used to be very confused, too, and after learning something about it, I wrote that page. Almost didn‘t finish and publish it when tptacek put his page up, but by that time I had already invested most of the effort, and I wanted to be less terse.

True, maybe I should have added ...and non-experts who try to faithfully summarize them for us mere mortals.

Edit: actually, I think I would recommend everyone interested in this subject to read at least a few texts by actual experts (professors in cryptography and people who work for high-stakes security businesses), to get a taste of what it's all about.

Re: Myths about /dev/urandom (2014)

#40

Post by tptacek »

jMyles wrote: post #14
tptacek wrote: post #3

Earlier quoted context omitted.

I don't think you're going to find too many cryptography engineers recommending that you use /dev/random, or, for that matter, the blocking variant of getrandom(2). This might be a live debate on message boards, or on the wrong stack overflow boards --- though Pornin's answer[1] on this question is one of the all-time good Stack Overflow answers --- but among practitioners, this is long settled. [1]: https://security…

Well, perhaps you have a better answer to my question than forest's answer, to which I awarded the bounty. For my money, I think that's one of the finest and most balanced pieces of writing on this topic available on the internet today. > I don't think you're going to find too many cryptography engineers recommending that you use...the blocking variant of getrandom(2). It depends on what you mean by "the blocking var…

Regarding that Stack Exchange answer: avoiding the Linux KRNG in favor of alternate RNG's like OpenSSL's is literally the opposite of what cryptographic software security engineers will tell you. For the past decade and a half, virtually all notable cryptographic failures owing to bad randomness came from systems that weren't using the kernel RNG.
Post reply on HN