At 05:50 PM 12/15/00 +0100, Ulf Moeller wrote:
>On Thu, Dec 14, 2000, Tom Biggs wrote:
>
> > I think our hardware's basic method of generating
> > randomness is pretty good, but the HW engineer is going
> > to stir and combine the first stage randoms even further
> > to get really high-quality randomness. This is all to the good.
> > However, it slows the process down since a lot of random bits
> > go into the second stage but few come out.
> >
> > I can see that there is some concept of randomness "quality"
> > in OpenSSL - RAND_METHOD has two methods, one of
> > which is pseudorand(). But outside of the test routines
> > pseudorand() only seems to be called by BN_is_prime_fasttest().
>
>It is both the same algorithm, but on some systems the PRNG must be
>seeded explicitly. There are some applications where you don't need
>that seed, and the pseudorand() method is for those.
>
>If you're not sure that the hardware RNG is sound, you could just xor
>its output with OpenSSL generated numbers.
No, from what I can see, the hardware RNG looks
very good. It's a question of speed - it's going to generate
top-quality RNs, but relatively slowly. I thought there might
have been a need to generate them faster at a slightly
reduced quality, but I guess not.
My other option is to have the hardware RNG
run always, and queue up a bunch of bytes,
which it can give out on demand. (Right now I
think it waits for a request)
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
Tom Biggs
'89 FJ1200 DoD #1146
"The whole aim of practical politics is to keep the populace alarmed -
and hence clamorous to be led to safety - by menacing it with an endless
series of hobgoblins, all of them imaginary." -- H.L. Mencken
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
