On 08/16/16 15:28, H. Peter Anvin wrote: > On 08/15/16 22:45, Stephan Mueller wrote: >> Am Montag, 15. August 2016, 13:42:54 CEST schrieb H. Peter Anvin: >> >> Hi H, >> >>> On 08/11/16 05:24, Stephan Mueller wrote: >>>> * prevent fast noise sources from dominating slow noise sources >>>> >>>> in case of /dev/random >>> >>> Can someone please explain if and why this is actually desirable, and if >>> this assessment has been passed to someone who has actual experience >>> with cryptography at the professional level? >> >> There are two motivations for that: >> >> - the current /dev/random is compliant to NTG.1 from AIS 20/31 which requires >> (in brief words) that entropy comes from auditible noise sources. Currently in >> my LRNG only RDRAND is a fast noise source which is not auditible (and it is >> designed to cause a VM exit making it even harder to assess it). To make the >> LRNG to comply with NTG.1, RDRAND can provide entropy but must not become the >> sole entropy provider which is the case now with that change. >> >> - the current /dev/random implementation follows the same concept with the >> exception of 3.15 and 3.16 where RDRAND was not rate-limited. In later >> versions, this was changed. >> > > I'm not saying it should be *sole*. I am questioning the value in > limiting it, as it seems to me that it could only ever produce a worse > result. > Also, it would be great to actually get a definition for "auditable". A quantum white noise source which exceeds the sampling bandwidth is an ideal RNG; how do you "audit" that? If what you are doing is looking for imperfections, those imperfections can be trivially emulated. If what you mean is an audit on the chip or circuit level, that would require some mechanism to know that all items were built identically without deviation, which may be possible for intelligence agencies or the military who have full control of their supply chain, but for anyone else that is most likely an impossible task. How many people are going to crack the case and look at even a discrete transistor circuit, and how many of *those* are going to be able to discern if that circuit is subject to RF capture, or its output even used? I have been trying to figure out how to reasonably solve this problem for a long time now, and it is not just a problem for RDSEED (RDRAND is a slightly different beast.) The only reason RDSEED exposes the problem particularly harshly is because it is extremely high bandwidth compared to other noise sources and it is architecturally integrated into the CPU, but the same would apply to an external noise generator connected via PCIe, for example. Incidentally, I am hoping -- and this is a personal statement and nothing official from Intel -- that at some future date RDRAND (not RDSEED) will be fast enough that it can completely replace even prandom_u32(), which I really hope can be non-controversial as prandom_u32() isn't cryptographically strong in the first place. -hpa -- 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
