On Thu, Jan 02, 2014 at 10:52:47AM -0800, coderman wrote: > On Thu, Jan 2, 2014 at 8:24 AM, <[email protected]> wrote: > > So... given the Dual_EC_DRBG backdoor, I think we have a few > > interesting leads for investigation. > > ... > > Q2) Was it designed this way intentionally as a multi-stage attack, > > where the algorithm is weak to bad RNGs and gets widely deployed, > > with the compromised RNG inserted (standardized) later? > > > it was intentionally designed as a classic "master key" backdoor, > which you can now play with yourself :)
It's certainly interesting, and it's interesting that most protocols expose random numbers directly (nonces, challenges, IVs) and only a few might not. > not quite the same thing, but the Intel RDRAND and RDSEED instructions > are both explicitly designed to avoid scrutiny of raw hardware random > source samples. they both are masked by an AES-CBC compressor, with > an additional AES NIST DRBG round for RDRAND. I think if anyone isn't giving you access to a full (digitized) analog source samples, before any whitening, they're either cutting corners or trying to "pull a fast one" on you. It doesn't matter which; you should just treat it as opportunistic entropy and not something you rely on. If they don't understand customer desire to validate the source, they don't understand RNGs enough to be trusted to make a good one. Are you sure about the RDRAND invoking Dual_EC_DRBG? That would be really suspicious and not indicated in the Wikipedia page: http://en.wikipedia.org/wiki/RdRand As suggested by the FreeBSD 10 response of feeding all HWRNG into Yarrow, as a BCP, should defensively written code whiten all RNG sources? IOW, should we establish new trust boundaries and where? We should definitely not blindly trust hardware RNGs, which is what I've been saying for nearly 15 years. But based on the Dual_EC_DRBG news, neither should we blindly trust any deterministic bit generator when we have access to real random bits. It makes sense to me to combine the best properties of both in such a way that you can always stub out or simulate a TRNG for testing. -- http://www.subspacefield.org/~travis/ PGP: the original social network
pgpiSLpR8tqju.pgp
Description: PGP signature
_______________________________________________ RNG mailing list [email protected] http://lists.bitrot.info/mailman/listinfo/rng
