CAcert System Admins discussion list

["Sam Johnston" <samj AT samj.net>]

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). Given OpenSSL on Debian would have been 'best available technology' we may want to do more... 'best attainable technology'? perhaps look to have a hardware random number generator at some point?

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?

Sam

On Fri, May 30, 2008 at 11:46 AM, Teus Hagen <teus AT theunis.org> wrote:

Agree with Pat. It was a stupidity of Debian distro commenting out and
decreasing the quality of key generation below acceptable level (and the
believe of engineers around the person who did it that he was doing ok:-( ).
The problem is does one believe a distribution? (OpenSSL as such was not
failing). It is risk management nothing more. Answer probably to my
question is yes: Debian is accepted and qualified and the world used
experts to control it (and we will fail and learn).
The question arises: which of the open source distro's ("assemblies" of
OSS) do quality assessment on themselves? (I guess that even probably eg
IBM is not doing it?).

Is it a failure that CAcert did not detected it?

teus

On 29/05/08 19:50, Pat Wilson wrote:
>
> On May 29, 2008, at 11:30 AM, Ian G wrote:
>
>> With the OpenSSL/debian debacle fresh in our minds, it seems
>> that this would be a good time to think about CAcert's need
>> for good random numbers.
>>
>> It has frequently been pointed out that random numbers are
>> devilishly difficult to deal with, something made apparent
>> with the recent events.  To deal with them requires some
>> sort of process and/or check and/or alternate sources, it
>> would seem.
>>
>> As Pat is writing the Security Manual, it would seem that
>> this is the place for such a thing;  does anyone have a view
>> on a simple procedure for creating a sequence of RNs that is
>> useful for the tasks?
>>
>> I'm expecting to see something that overcomes simple things
>> like "OpenSSL delivers all zeros and we didn't notice..."
>>
>> I'd guess there are two parts:  root keys (high quality
>> needed) and routine protocol work (OpenSSL/httpd, SSH, etc,
>> so "regular" randoms needed, whatever that means).
>>
>> Any thoughts?  Pat, is there an easy place for this in the SM?
>>
>> http://wiki.cacert.org/wiki/SecurityManual
>
> I'd think there's not much chance of OpenSSL having a problem
> (yes, the Debian distro did, buy only because someone commented
> out useful code), and would sort of expect it to be encompassed by
> our use of "best available technology".  If you wanted to put something
> in explicitly, though, the scope of section 2.3 "Application Security"
> could
> be broadened to include a statement about "best available", "thorough
> code review", or something of that nature.
>
> --paw
>

> ------------------------------------------------------------------------

>
> _______________________________________________
> CAcert-sysadm mailing list
> CAcert-sysadm AT lists.cacert.org
> https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-sysadm
_______________________________________________
CAcert-sysadm mailing list
CAcert-sysadm AT lists.cacert.org
https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-sysadm