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 [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
