On Tue, Aug 29, 2017 at 09:06:07AM +0200, Thomas Schmitt wrote: > Hi, > > Zenaan Harkness wrote: > > AIUI /dev/random is simply the input feed to /dev/urandom [...]
I should have wrote "/dev/random should be treated as though it is the input feed to /dev/urandom" (sorry about that). > This is what the article by Thomas Huehn > https://www.2uo.de/myths-about-urandom/ That's a really good description of various myths. Well worth reading for those who are interested in this topic. It's first debunk is this, which is clear, certainly clearer than my attempt to communicate on this topic :) "Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems." > calls a myth, illustrated by diagram > https://www.2uo.de/myths-about-urandom/structure-no.png That diag seems sort of useful, but less clear than it could be. [edit: that diagram is what's NOT happening!] [which means: we're simply not understanding one another] The debunked myths seems much clearer to me - but that could just be because my second brain cell isn't function so well or is failing to properly cross heisenberg's uncertainty of existence threshold - either way, my first brain cell is somewhat limited in its capacity sorry. This debunk is particularly useful to a lot of straw men that get thrown about: That's all good and nice, but even the man page for /dev/(u)random contradicts you! Does anyone who knows about this stuff actually agree with you? Fact: No, it really doesn't. It seems to imply that /dev/urandom is insecure for cryptographic use, unless you really understand all that cryptographic jargon. and the subsequent paragraph is exactly what that eponymous brain cell of mine failed to clearly explain: The man page does recommend the use of /dev/random in some cases (it doesn't hurt, in my opinion, but is not strictly necessary), but it also recommends /dev/urandom as the device to use for “normal” cryptographic use. Really great myth-debunking article - it be the true go to view, to send folks to who do pursue a crypto clue, or two. > Andy Smith stated in > https://lists.debian.org/debian-user/2017/08/msg01594.html > that the article is correct. > > > > if you want security/ secure software, you -must- know the nature of > > your inputs, > > I thought that i knew from the man page. But people with probably more > knowledge than me contradict that page. Well that debunking article actually backs up the man page - if you find a particular sentence confusing, feel free to paste it here and we can all take pot shots at how shitty its wording is :D I kid, I kid! I actually have never read that man page... > I wrote: > > > I understand that in this situation there is no difference > > > between /dev/random and /dev/urandom. > > > No > > So this diagram about the situation before kernel 4.8 is wrong ? > https://www.2uo.de/myths-about-urandom/structure-yes.png Ahah! That's a better diagram - that explains why I found it confusing, because it was I guess trying to explain what does not happen :) Seems even my first brain cell needs a cup of caffeine... > The new situation as stated in > https://www.2uo.de/myths-about-urandom/structure-new.png I always thought (even pre- Kernel 4.8) that structure-new was how it worked. But on the other hand, it's just a diagram - use the source, Duke! > is a bit more obscure, because it is not clear what exactly happens inside > the "randomness pool". Is it only a buffer ? Does it always grow when new > data arrive ? Or does it merge the new bits into a constant size pool ? Use the source, and write a Haykiyui when you grok the fine differences :) > > > The difference appears only when the assumption of wealth is not > > > fulfilled. > > > ... parse fail > > "Wealth" = Well filled randomness pool which makes blocking unnessessary. That's exactly what /dev/urandom provides - so go forth in wealth :) We have awesome API/ functionality abundance in the libre software world, so you can strut around in a highly superior stance FTW (or the fall on the pride sword which would deliciously follow). > > don't use /dev/random, use /dev/urandom instead, as designed, > > Urm. Your argumentation up to this point was that they differ sigificantly. They do. And so in general, if you want cryptographically safe random numbers for user-space programs, use /dev/urandom - what's not to grok here? > > and as has been made publicly clear for ~10 years now. > > The kernel people won't get us users to change our behavior unless the > man page gets clarified and the experts take the responsibility to teach us > what https://www.2uo.de/myths-about-urandom/ tries to teach us. No, simply understanding is what's needed. "Some" users, yes, but the man pages are actually our responsibility to update - perhaps you're assuming it was the responsibility of the kernel devs? Those assumptions ... ;) > The current statements look like a lame compromise after some of the > participating experts objected the flat deprecation of /dev/random > even after the system had a few seconds of collecting erratic events. > > But what are these objections and why are they important enough to > cause a statement like > "Choice of random source > Unless you are doing long-term key generation (and most likely not > even then), you probably shouldn't be reading from the /dev/random [...]" > in > http://man7.org/linux/man-pages/man7/random.7.html > > The clause "most likely not" puts the whole statement in question without > giving a clue about the proper answer. > Further it implies a vague security difference between both devices. No doubt your man-page wording enhancement patches shall be soon forthcoming, and many future users shall explode in gratitude for your persistent diligence on a frankly vital topic of understanding for specific domains of software development and use! > > Confront the man page! > > If only this would give more clarity ... X-| > > > My current compilation of all info is like this: > > /dev/random was originally designed to possibly block, but is now said > not to do this any more in practice. No! That's the whole point of why /dev/random should in general (for user space software) not be used when you want cryptographically secure random numbers - it's returning guaranteed entropy bits, which do result in cryptographically secure numbers, and in most circumstances is not needed by end user programs. If you're not a software developer, don't worry about it. If you are, use a library that is widely used and known to have had a few (now fixed) bugs in the past. > /dev/urandom was originally designed to hand out lower quality random No. /dev/urandom was designed to hand out cryptographically secure numbers whilst not blocking. Only in rare circumstances does blocking for "#N pure entropy bits" actually gain you anything in the crypto world. If you're not gaining anything, why use it and risk blocking? > if /dev/random would block, but is now said not to do this any more. I don't know about that last bit - AIUI this is also wrong - /dev/random CAN block, which is the whole point of providing /dev/urandom. At this point, if you really want certainty, you will need to read the code, or go to someone who can speak with authority on the actual kernel code. I thought Ted Ts'o was quite clear in that email of his previously linked. I could be not understanding his words properly. Good luck,
