On Thu, Jul 17, 2014 at 10:39:57AM -0700, H. Peter Anvin wrote: > > I saw exactly one complaint to that nature, but that was from someone > who really wanted the "nordrand" option (at which point I observed that > it had inadvertently left RDSEED enabled which quickly got rectified.) > The implication was that this was a request from a specific customer who > presumably have their own "audited" hardware RNG. There was another complaint more recently, that wasn't related to nordrand. And I was rather disturbed that in add_interrupt_randomness() 97% of the entropy was coming from RDSEED. I'm willing to have some of the entropy come from RDSEED by default, but 97% seems to really way too much. And the emergency refill code in random_read() was extremely problematic. First of all, we're dropping 512 bytes on the stack, which is kind of bad, but hopefully all of the code paths which call random_read() won't have a terribly deep stack. Secondly, even after the emergency refill, we block anyway. Which is kind of OK, but what it means is that we are pulling 512 bytes from RDSEED, and giving credit for 2048 bits of entropy; but since we block until the next contribution from interrupt randomness, that means we get 1 bit from the entropy randomness, and 2048 bits of entropy from RDSEED --- which means that from the standpoint of entropy accounting, 99.95% (2048/2049) of the entropy is coming from RDSEED when reading from /dev/random when its entropy pool is empty. Remember, regardless of whether or not you believe (as a former head of NSA's technology directorate recently claimed) that the DUAL-EC p and q were generated using NSA's standard high-quality HW RNG system which they use to generate all of their crypto variables, or (as the NIST advisory panel has recently concluded) that it was highly likely that DUAL-EC was backdoored, it's the optics that matter, because those of us without top-drawer SI security clearances can't prove things one way or another. And when 99.95% of the entropy when reading large quantities of keying material from /dev/random is coming from RDSEED, that just has terrible, terrible optics.... - Ted -- 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
