On Thu, Jan 02, 2014 at 08:24:51AM -0800, [email protected] wrote: > So... given the Dual_EC_DRBG backdoor, I think we have a few > interesting leads for investigation. > > Implications of a bad RNG vis-a-vis other algorithms, for example DSA: > > With DSA, the entropy, secrecy, and uniqueness of the random > signature value k is critical. It is so critical that violating any > one of those three requirements can reveal the entire private key > to an attacker.[11] Using the same value twice (even while keeping > k secret), using a predictable value, or leaking even a few bits of > k in each of several signatures, is enough to break DSA.[12] > > In December 2010, a group calling itself fail0verflow announced > recovery of the ECDSA private key used by Sony to sign software for > the PlayStation 3 game console. The attack was made possible > because Sony failed to generate a new random k for each > signature.[13] > > This issue can be prevented by deriving k deterministically from > the private key and the message hash, as described by RFC > 6979. This ensures that k is different for each H(m) and > unpredictable for attackers who do not know x. > > Q0) Does any widely-used DSA implementation NOT do this? > > Q1) Does any other algorithm behave so poorly in the face of a > adversarially-predictable RNG? That is, to reveal a long-term > private key by means of using a single predictable nonce. > It seems designed to fail in a spectacular way under this > condition. > > 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? > > Q3) What are the designs and implementation of the HWRNGs delivered in > mass-market devices? One can reasonably infer that they may be > compromised in similar ways. Can we determine if they are indeed > TRNGs or perhaps CSPRNGs? Can we model them as black boxes and > classify the in any way? Perhaps some will perform exactly like > Dual_EC_DRBG. > > Q4) What are the implications of non-strong RNGs? > > They appear to fall into several categories: > > a) Weak > b) Trojan horsed (predictable to attacker but apparently good) > c) Actively malicious (emitting private keys in subliminal channels) > > Please note that with closed designs, b is quite easy. > > Q5) What about subliminal channels? We know that DSA was designed > with one broadband and three narrow subliminal channels: > > http://en.wikipedia.org/wiki/Subliminal_channel > > Q6) Are any other governmentally-approved DRBG designs suspect? > > Q7) Are any other governmentally-approved algorithms so weak? > > Q8) Who changed the Linux MINT OpenSSL to match te debian bug exactly?
Also, I'd add: Q9) Are there any similar suspect constants (e.g. curves) anywhere, either defined by a standard, or given as an example? We should be skeptical of opaque blobs of data in crypto as we would in firmware. We already have ways of handling this: http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number Q10) Since we have already established certain configurations where a single predictable RNG output can compromise a long-term key, are there protocols where a poor RNG used by a peer can compromise your security? Clearly a predictable RNG on the other side compromises anything the other side wished to protect, but can it compromise what you never intended to reveal? For example, is a server picking a predictable curve or generator going to reveal YOUR long-term key? -- http://www.subspacefield.org/~travis/ Remediating... LIKE A BOSS
pgpsNthnyIs5b.pgp
Description: PGP signature
_______________________________________________ RNG mailing list [email protected] http://lists.bitrot.info/mailman/listinfo/rng
