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. -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
