5 ms·
excuse my potential ignorance, but I thought that /dev/random was at risk of exhaustion in the general case, with /dev/urandom not being so... e.g. http://www.
by raesene6 11y ago
excuse my potential ignorance, but I thought that /dev/random was at risk of exhaustion in the general case, with /dev/urandom not being so...
e.g. http://www.onkarjoshi.com/blog/191/device-dev-random-vs-urandom/ http://www.onkarjoshi.com/blog/191/device-dev-random-vs-uran... or http://security.stackexchange.com/a/14293/37 http://security.stackexchange.com/a/14293/37
- cyphar 11y agoI got schooled about this a few days ago. Here's the thread: https://news.ycombinator.com/item?id=11485832 https://news.ycombinator.com/item?id=11485832. The tl;dr is that basically you should just use /dev/urandom unless you're in very weird circumstances. Entropy doesn't "run out" in that sense.
- raesene6 11y agooh yes I agree /dev/urandom is the way to go, but the original comment said that the paper's suggestion that a container could exhaust the pool on /dev/random was false and that's what I was curious about. I thought it was possible to exhaust /dev/random...
- cyphar 11y agoI think all of the ancestors where saying that you couldn't use containers to "reduce the entropy" (which probably is meant to be "cause CSPRNG state to be known") won't happen because /dev/random blocking is done by some arbitrary statistic that has dubious reasons for existing. True, you can cause /deb/random to block, but that doesn't result in anything bad happening. Unless you have bad software that does bad things when reads block.