Stephen's protocol would address one particular type of PRNG screw up, the case where the PRNG is so badly screwed up that duplicate keys are seen.
A more common screw up is the Netscape bug where the PRNG has a sound algorithm but is working on too little initial entropy (about 30 bits I seem to recall). In the Netscape case the only way to fix the problem was to reverse engineer the code. After conversations with Jeff Schiller, Alan Schiffman and others I had a long conversation with Marc Andressen on the design of the PRNG in the early editions of Navigator. This was after I broke SSL 1.0 in ten mins and he wasn't too keen talking to me. Eventually I managed to convince them that putting 30 bits worth of entropy through MD5 would not produce 128 bits of randomness. Marc then did something he should have done at the start and they finally hired some real crypto people (Taher & the bros Wienstein). They also asked me how to do the job right so I sent the design notes for the code in Shen. A year later the PRNG bug was rediscovered. I asked what had happened and the response I got back was that they had looked at the design notes for the PRNG and they were so comprehensive they didn't feel the need to check the code. So the moral I draw from that is that where the PRNG is concerned there really is no substitute for checking the code where public key algorithms are concerned. This is not the case for symmetric algorithms where it is sufficient for either side to introduce a sufficient amount of entropy. On Mon, Feb 20, 2012 at 3:03 PM, Martin Rex <[email protected]> wrote: > Nico Williams wrote: >> >> Phillip Hallam-Baker <[email protected]> wrote: >> > >> > It would be really nice if there was some way to audit >> > RNGs algorithmically... >> >> Separate the HW RNG and other entropy gathering parts from the rest of >> the RNG (i.e., the entropy pool, the mixer, the extractor), and you >> provide a per-device seed for testing. > > Correct. You can and should test the entropy _inputs_ whether they > meet your assumption of "unpredictability". Testing the output > of the CPRNG is of limited value (it would only ring bells if both, > the randomness in the entropy inputs are way behind their assumed > properties, plus there is a serious problem in your CPRNG in > moving from state n to state n+1). > > >> >> But you have to make sure that >> any test modes can't be enabled without tampering with the physical >> device. Once the device is sealed you should not be able to test the >> RNG in any way other than by statistical analysis of its outputs. > > This rings my "snake-oil" alarm bells. > > If your assessments of the entropy of your inputs is correct, then > there will NOT be a problem to offer the test mode when the device > is in use. You just need to ensure that the test mode reveals only > surplus samples that your CPRNG does not use. > Most devices should be able to produce much more samples that what > is needed/consumed by the CPRNG, and there should not be a problem > _per_se_ by allowing the testing of samples when the device is in > productive use. > > Not revealing anything may result in the *real* randomness being stronger > than the conservative assessment from the design. But you should be > using a sufficient safety margin ( factor >= 2 ) in assessing the effective > randomness of your input parameters anyway. And letting unauthenticated > peers pull entropy input samples is probably always a bad idea. > > > -Martin -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
