CAcert System Admins discussion list

[Ian G <iang AT iang.org>]

Sam Johnston wrote:
> Hi Teus et al,
>
> This is an interesting discussion - I'm not sure that we could have been 
> considered in any way liable for not detecting it (after all, nobody 
> else did!) but nonetheless we do need to pay attention to this issue 
> (and probably codify it as suggested).


Yup, agreed all points.


> Given OpenSSL on Debian would 
> have been 'best available technology' we may want to do more...


Right that's the trap we are in.  The issue is of course 
that debian was using the best available technology, which 
was OpenSSL.  And OpenSSL was using the best available 
technology which was /dev/random.  And /dev/random was using 
the best available technology which was measuring of disk 
drive times, in a peer-reviewed design, tested and 
authorised and blah blah ...  so forth ad nauseum.

And still it went wrong...


> 'best 
> attainable technology'? perhaps look to have a hardware random number 
> generator at some point?


Hence, using the best available technology isn't going to 
help;  in fact, sometimes, it is better not to use the 
"best" because then we end up with the chain above, with 3-4 
single points of failure, any of which will result in 
complete failure, in an undetectable fashion.



The way around this is to use multiple independent sources, 
and mix them ourselves.  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.

Then, if one source breaks, we're still covered.  If two 
sources break; regenerate.  If all break, then we should 
pack up and go home :)

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!



> I believe there are (Intel?) chipsets that do this and if not we could 
> always hunt for a true random source, or depending on how much of the 
> stuff we need, borrow one to create a pool in advance.
>
> Are there any readily available performance tests for this?


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.

iang

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature