On 02/20/2012 08:46 PM, Phillip Hallam-Baker wrote:
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.
Well, anything detectable from the public key (and a signature I
guess, hard to see what that might be but who knows). So both the
common factors thing and e.g. the blacklisted keys from the earlier
debian problems could be detected.
I guess really stupid lengths could be barfed on too and
even even RSA moduli. (I know, these should ever happen,
but...)
Point is that a protocol can help with (some) new types
of problem too as we discover that those problem kinds of key
have gotten out there and been discovered.
Its an open question as to whether this is worthwhile, (e.g. maybe
nobody would offer such a service) but I think it'd be good to have
it (properly) spec'd in case it does turn out to be useful.
(I'd be glad to get more review to get "properly" bit sorted
btw - I'm bound to have done something dumb:-)
S.
PS: I do entirely agree about fixing implementations as well but
am just focusing on another aspect myself.
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
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey
