CAcert System Admins discussion list

[Philipp Gühring <pg AT futureware.at>]

Hi,

> The way around this is to use multiple independent sources,
> and mix them ourselves.  

That's what OpenSSL did. They used about 5-10 independent sources. 
(I guess about 6 sources from /dev/random and 2-3 other sources from OpenSSL.)
Still they failed.

PGP also failed in a similar way.
They had several sources, and read them with something like
buf[0]=read(source,buf,1);
So they actually retrieved good, mixed, random numbers, and used multiple 
sources. Still it went wrong.


From the perspective of key-generation:
What is needed is end-to-end quality control. It doesn't matter where the 
random numbers come from. It doesn't matter much how they are mixed. 
The question is, whether good random numbers end up in the keys and end up in 
the nonces, ...

I've seen "broken" hardware random number generatos. I've seen "broken" 
software random number generatos. And I've seen 3 good examples of software 
that actually got randomness from several sources, and still didn't ensure 
that the random numbers end up in the keys correctly.

PGP and Debian-OpenSSL are good examples for good random numbers not being 
used
Netscape and Debian-OpenSSL are good examples for several entropy sources not 
ending up in the keys
Javacard, are good examples for hardware doing it wrong
ECC-RNG is a good example of a backdoored RNG

> So, if we really care about 
> something, then we could simply specify that multiple
> sources of random numbers are used, mixed and fed in to the
> using software.

Yes, and how do you ensure that it ends up being used correctly?

> Then, if one source breaks, we're still covered.  

Yes, and if the usage breaks, you are broken.

> If two 
> sources break; regenerate.  If all break, then we should
> pack up and go home :)

I think that's what I suggested after I reviewed Ricardo ...

> E.g., if OpenSSL is used for the root key generation, feed
> in some more stuff.  (Apparently there is a command to do
> that, add some more randomness from an external file.)  We
> might think that this is good enough for critical uses, but
> too much trouble for regular uses ... so try and strike a
> balance.   e.g.:
>
>     1.  root keys are critical grade A.  We use three
>     independent sources of randomness, mixed together:
>       a. /dev/random (from drive times)
>       b. hardware RNG (purchased from blah blah)
>       c. encrypt of mp3; key & mp3 chosen by fair dice roll
>     all done under two witnesses who authenticate each step.
>
>     2.  SSH server keys are critical grade B.  We use
>     two sources of randomness:
>       a. /dev/random
>       b. hardware RNG
>
>     3.  all other protocol work is grade C, we use just
>     one source:
>       a. /dev/random
>
>     We test a,b above from before uses 1,2 by:
>       a. compression
>       b. re-cycle comparison
>       c. diehard and NIST test blah blah.
>
> Or somesuch.  There is a long list of possibilities that
> Philipp has collected here:
>
> http://sig.cacert.at/cgi-bin/rngresults
>
> Time to put that list to some use!

Yes, this should be used to determine the quality of every single source of 
randomness and of the mixes of randomness and of the correct usage of 
randomness.

> This is one of the core reasons why this happened;  there
> are no easy / good / perfect tests for random numbers.  Have
> a look at that list above;  it's impossible to understand,
> how are we to know what is good or not...
>
> If there was an easy / good test, then OpenSSL would have
> had it and it would have picked up that debian had broken.
> Hence, the way to get around this dependency is to
> diversify:  mix in different independent sources.

Doesn't help. 
OpenSSL had 3,5 different sources and mixed them. Adding more sources helps a 
bit, but it doesn't solve the main problem, since it still doesn't ensure 
good keys.
You have to ensure that the entropy ends up in the keys and in the nonces.


Best regards,
Philipp Gühring