On Wed, January 22, 2014 8:28 am, Paul Hoffman wrote: > On Jan 22, 2014, at 8:13 AM, Dan Harkins <[email protected]> wrote: >> >> I see value in draft-eastlake-randomness3 and I also see value in an >> Informational RFC on a good DRBG for those who feel the need to have >> a belt as well as suspenders. > > We disagree here; the chance that the person writing the belt will get it > wrong and make their crypto trivial to break for an attacker who knows the > weakness seems much higher to me than the change that the OS got it wrong. > Yes, we could put some warning at the front of the new document about > this, but that warning will be ignored by programmers who are sure they > know this stuff. > > I could see writing something that forces them to mix in randomness from > the OS to their possibly-borked DRBG in the hopes that at least that step > will fix their problems. However, if we do that, nearly all the > interesting technical stuff in the current document is just confusing > fluff. The new document reduces to "use an HMAC with the randomness from > your OS as the key and whatever stuff you think is random as the data; > done".
To minimize the possibility of someone borking their DRBG implementation we can include some test vectors-- instantiating with A produces state of B; reseeding of state B with C produces state D; generating with state D produces E, etc. The more people that implement anything will increase the probability of a broken implementation somewhere, I definitely agree. But it is an accepted economic truth that relying on a single source for anything is a bad idea. Dan. _______________________________________________ dsfjdssdfsd mailing list [email protected] https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
