[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-dev
Subject:    Re: Stalling hardware randomness a possible problem.
From:       Geoff Thorpe <geoff () geoffthorpe ! net>
Date:       2003-11-25 2:41:08
[Download RAW message or body]

G'day,

On November 24, 2003 04:47 am, Richard Levitte - VMS Whacker wrote:
> geoff> Well, as you asked. I think one of the main problems is that
> geoff> there's no context type in crypto/rand/ - there is essentially
> geoff> just global state, so IMHO having the vtables is of dubious
> geoff> value anyway.
>
> I *entirely* agree with everything you say there, except for the
> dubious value.  Granted, the value is small compared to other methods
> in OpenSSL, but it still allows a user (or an engine :-)) to change
> the default RNG.

True, but my point had merely been that the RAND_METHOD encapsulation is 
arbitrary - they could have all been global callback pointers and it 
would make no difference. The method is just a grouping of those pointers 
into a single structure. What makes a method/vtable is the object it 
hangs off, and in the case of the randomness, there is no object/state to 
tie a method/vtable to.

> That shouldn't be much harder than the NCONF construct I made, which
> basically was the exact same move on CONF...

Cool. I've since seen you posted diffs. Haven't had a chance to scrutinise 
yet, but will do so ASAP.

> Hmm, considering that we already replace the default RAND_METHOD with
> the engine one (when an engine has one), isn't the unplugging part
> already handled?  And after all, having the nCipher feed the internal
> OpenSSL randomness pool doesn't mean it's suddenly more tied to the
> nCipher engine, it only means it was seeded with more entropy.  The
> only thing is that the nCipher engine uses the internal OpenSSL pool,
> that's all.  I see no real problems here.

But I'm not sure that the ncipher should be seeding any global pool, 
particularly if the ncipher engine isn't set as a default but is used 
selectively by creation of RAND objects. Any if the ncipher engine is set 
as default, then this isn't an issue either because its own "object" will 
be the global one anyhow. Ie. I think the advent of a RAND object type 
should keep the entire PRNG state-machine contained within this object 
(state and hooks for pseudo-random generation as well as the hook for 
*real* random input/seeding).

Which reminds me, what happens in the software implementation when seeding 
is needed? Is it possible to scope a software-based PRNG object such that 
if it needs seeding, it can use a handler in the RAND_METHOD vtable to 
call(back) out to retrieve it? If not, should it be extended to do this? 
(Looking at this superficially, it looks like RAND_METHOD only has 
handlers for explicitly adding entropy in but no handlers for the 
internal implementation to request more - perhaps I'm confused though).

> Listen, I'll code and show you the patch, then you can judge for
> yourself.  Deal?

:-) Sure, I'll try and take a closer look in the next day or two.

Cheers,
Geoff

-- 
Geoff Thorpe
geoff@geoffthorpe.net
http://www.geoffthorpe.net/

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majordomo@openssl.org
[prev in list] [next in list] [prev in thread] [next in thread]