Tom Biggs <[EMAIL PROTECTED]>:
> The hardware that I am creating an ENGINE module for
> is capable of generating random numbers, so I'm adding
> a RAND_METHOD.
>
> 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().
No, it is used at some other places too. The 'pseudorand' method is
meant for random numbers that are not necessarily unpredictable, but
still are 'unique' -- i.e., if the PRNG is used again, it won't
produce identical pseudorandom number sequences with more than the
usual probability. Seeding a cryptographic PRNG with data such as
time and the current PID is enough to do this; but since such seeding
is quite predictable, it is unsuitable for generating cryptographic
keys and similar secrets. The 'bytes' method is for generating
random numbers that must be unpredictable. This does not mean
information-theoretic security -- once the PRNG has had enough
initial seeding, it will dispense any number of bytes requested.
(It would be hard to change this because we don't have any "waiting
for random seeding" states -- if some function needs randomness
and the PRNG reports an error, this is considered fatal.)
Feeding in new seed bytes is recommended, though. This would
be a good application of the hardware randomness generator.
Earlier, I wrote:
< It makes sense to use hardware randomness devices in the default method.
< I can think of three different functions for obtaining randomness
< from a hardware device (a device may define any subset of these):
<
< 1. Obtain n pseudo-random numbers of bad or good quality, like
< /dev/urandom. This function should return an entropy estimate, if
< available, or 0 otherwise. The default method should use this as
< an additional byte source where it uses /dev/urandom.
<
< 2. Obtain up to n random bytes; return only as many bytes as the
< hardware-device's entropy count allows. This too could be
< used where /dev/urandom is used, if no function of type 1 is
< available.
<
< 3. Obtain n random bytes if the entropy count has ever exceeded this
< amount, return nothing otherwise. The default RAND_METHOD
< should use this function if RAND_bytes is called when the pool's
< entropy count is not yet sufficient.
<
< 3'. If the entropy count has never exceeded n bytes, then block until
< it does.
<
< 4. Obtain n random bytes if the entropy count allows, return nothing
< otherwise. The default RAND_METHOD could use this as a fallback
< if 3 is not available.
<
< 4'. Obtain n random bytes, blocking until these are available.
< (Unlike with 3' and 3, getting bytes cannot be separated from
< blocking -- otherwise there'd be a race condition.)
<
< No use for functions 3' and 4' in the default randomness method comes
< to my mind, but other RAND_METHODs that intend to provide
< information-theoretic security may need something like that.
< (There'd also have to be a way for the application to tell
< the PRNG whether it is allowed to block or not, so the standard
< RAND_METHOD interface would not be enough in these cases.)
<
< This list of functions is assuming that you plan to make RAND_METHOD
< orthogonal to the engine. I may have forgotten other useful functions
< for accessing the hardware randomness device, but I think the
< above list covers most useful cases (including those that are
< missing from /dev/*random et al., but are useful).
And:
< > [...] define a new RAND_METHOD and populate most of its member
< > functions with copies from RAND_SSLeay() and just overload one
< > (or two) of them to hook them up with CryptoSwift's randomness
< > stuff? [...]
<
< My idea would be to make this orthogonal -- keep RAND_METHOD mostly as
< it is now, but add a hook for telling the software PRNG about the
< hardware PRNG (with about the list of functions that I sent you in my
< previous message). Then md_rand.c would call these functions as
< needed, e.g. obtain /dev/urandom-like seeding where it now uses
< /dev/urandom. An obvious new RAND_METHOD would be one that only
< copies bytes from the hardware PRNG, which works only if the hardware
< device has a non-blocking interface for doing this. But it also
< should be possible to use the hardware device just as an additional
< entropy source for md_rand.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
