Bodo Moeler wrote about the truerand library (at
ftp://ftp.research.att.com/dist/mab/librand.shar):
>It's not that portable (for getting CFS to work, I had to replace the
>roulette() function by an implementation that simply reads from
>/dev/urandom -- for reasons I did not investige further, SIGALRM never
>occurred, resulting in an endless loop).
May be the "count" variable should be declared as "volatile" (I have had
this problem with my own Windows implementation).
And what about the version using threads? perhaps it would be effectively
portable?
> Also note that the software
>self-describes as "a dubious, unproven hack for generating "true"
>random numbers in software."
I hoped that we could get some cryptanalysis from this mailing list.
This random package is so promissing: easy to use (no user input),
availability (no hardware /dev/urandom), fast, secure (at least potentialy
more secure than typical screen image, system statistics...) than it would
desirve such an analyse.
Now I realise that this mailing list bars developers only (any cryptanalyst
out there?) when could we get some reliable feedback?
>In any case, the library should never automatically call stuff
>like this (although it might be provided in standard functions
>that applications may use if it's deemed appropriate).
If you mean because it is not proven to be cryptanalitically secure, this is
not a real problem because we know how to add entropy sources in a secure
way. Adding an entropy source even if it is a weak source will not open a
security breach.
Still, a new function could be added and used if the developper calles it,
would be the best solution.
In any case, thank you Bodo, for your time already spent on this specific
issue (and others).
Nicolas Roumiantezeff.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]