On Mon, Aug 28, 2017 at 12:04:51PM +0200, Thomas Schmitt wrote: > Hi, > > Curt wrote: > > Here's a fresh (20 July of this year) view by Theodore Ts'o: > > https://lkml.org/lkml/2017/7/20/993 > > An opinion of substantial weight, indeed. > > Nevertheless it would be more interesting to learn the reason why > Linux did not simply make /dev/random behave like /dev/urandom long > ago.
Because that would obfuscate the difference in nature between the two. AIUI /dev/random is simply the input feed to /dev/urandom and the fact /dev/random is world readable is now an historic artifact, but also quite possibly still useful in certain, very specific/ narrow, circumstances. The main problem is folks not knowing which one to use. There are no shortcuts in the world of secure algorithms - that is, if you want security/ secure software, you -must- know the nature of your inputs, and /dev/random vs /dev/urandom provides this (essential) distinction. > And again, the argumentation of Theodore is that there is always > enough entropy at hand. Unclear wording. I would say Ted Ts'o is making sure that /dev/urandom delivers on its API promise/ expectation, which is really important, and great to know that Ts'o is on this! > I understand that in this situation there is no difference > between /dev/random and /dev/urandom. No. Here's Ted Ts'o (from above link): "I don't really care about /dev/random performance. What's is **far** more important is that the entropy estimations behave correctly, across all of Linux's architectures, while the kernel is going through startup, before CRNG is declared initialized." /dev/random performance/ api promise is "deliver truly random bits, even if this is slow to do so, since we'll be using these bits in absolutely critical places, such as seeding /dev/urandom" > The difference appears only when the assumption of wealth is not > fulfilled. ... parse fail > Also one should note that Theodore uses the argument of a > deprecated /dev/random as answer to a side note of his discussion > partner, not as general statement. But see his general statement above, which is almost the same thing as "if you want performance, consider /dev/random deprecated", i.e. he said "I don't really care about /dev/random performance." > The main point of Stephan Müller is that the system could collect > more entropy. The answer of Theodore is that it already collects > more than enough and does not have to care about being drained by > /dev/random because that draining is deprecated. Exactly - don't use /dev/random, use /dev/urandom instead, as designed, and as has been made publicly clear for ~10 years now. > So one would have to ask him, whether this opinion does not hold > under all circumstances or what else blocks him from just making > both mechanisms equal. Hopefully the above explains the principles involved. If for any reason you want high speed "hardware/ physical random" number stream, then you will have to go for a HRNG, and as Ted points out in the above link, there are many drivers for these in the kernel already - in other words, EVERY use case is abundantly provided for by the Linux kernel. Causing /dev/random to be the same as /dev/urandom would only make sense if the current /dev/random implementation were made completely private i.e. "internal to the kernel and not accessible by userspace" - then /dev/random could simply be a symlink to /dev/urandom - but there are disadvantages to doing this, not the least of which would be certain very specific yet limited use cases for which the existing /dev/random is an essential dependency! > (Normally i would dare to approach him. But i guess he is already > annoyed by the topic and man page reading cowards like me.) Confront the man page! And Wikipedia too ... Then write, your Haiku :) > Have a nice day :) You too, and a Haiku new.
