Am Montag, 28. April 2014, 10:23:50 schrieb Theodore Ts'o: Hi Theodore, > > I am not too convinced of RDRAND due to the lack of usable source code > > (i.e. source code that I can build myself). But that is my personal taste > > :-) > The problem is the FIPS validation would presumably require obeying > the SP-800A requirement for an approved entropy source, and while we > can't audit RDRAND to satisfy ourselves that the US government hasn't > introduced a back door, if the only purpose of the FIPS validation is > so that people can sell into the US government market, presuambly the > US government is OK with a potential NSA-introduced back door. :-) >From a US centric view, you may be right. But there are some FIPS 140-2 aspects which are helpful in general (albeit just a minority). And for those, auditible code is key. Not everybody is delighted to have NSA watching. :-) > > That being said, there is some FIPS compliance code in > drivers/char/random.c, which was introduced while Matt Mackall was > maintaining the driver, and it mystifies me, since I never thought > /dev/random could be an approved FIPS compliant generator --- not that > I care, since I'm not trying to sell into the US government market, > but the FIPS compliance code is largely harmless, so I've never > bothered to remove it. Ok, let me demystify it, because I was the initial trigger of the code changes. Albeit random.c is outside of any FIPS module, NIST requires that even seed sources that are outside the module boundary have a so-called "continuous selftest" as defined in FIPS specification section 4.9.2. If the self test fails, the seed source must become unavailable. > > > Thanks for these suggestions. Shall I take these suggestions and turn them > > into a full patch? > > Sure, go for it. > > > Moreover, I read that even for in-kernel users we should use the blocking > > pool. Or shall we conceive of a third output pool, say, a kernel pool that > > is independent of the output pools to user space? Adding such a pool more > > or less only requires to define a new struct entropy_pool instance. > > I've audited most of the in-kernel users, and most of them aren't even > using them for a session key; they're using it for something less > critical (e.g. ASLR, stack magic, etc.). CIFS is perhaps the only > place where it is generating a session key, and session key generation > is just fine with the /dev/urandom pool. > > So making all of the in-kernel users deal with a blocking interface is > not worth it, IMHO. Sorry, I did not make myself clear: for the purpose of the blocking behavior, shall we draw from blocking_pool or define a new pool used completely for this in-kernel blocking usage? Note, if we use the blocking_pool, any non-root user can stall the in-kernel operation indefinitely by simply reading /dev/random. As the in-kernel use for blocking random numbers would be limited, I was thinking about a new entropy pool that has no user space access. I do not want to convert any existing in-kernel users of random data to use the new entropy pool. Ciao Stephan -- | Cui bono? | -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
