In message <[EMAIL PROTECTED]> on Sun, 23 Nov 2003 13:52:43 -0500, Geoff Thorpe <[EMAIL PROTECTED]> said:
geoff> G'day geoff> geoff> On November 22, 2003 07:32 pm, Richard Levitte - VMS Whacker wrote: geoff> > Hmm, I see what you're saying. It seems to me like the points you're geoff> > raising get in conflict with each other. geoff> geoff> You should be used to it by now... :-) Actually, I think it's the first time I've noticed a conflict like this :-). geoff> > Of course: geoff> > geoff> > geoff> BTW: are you sure that it's not just a question of the ncipher geoff> > geoff> RAND_METHOD implementation being over-enthusiastic? I'm looking geoff> > geoff> at "hwcrhk_rand" right now, and I see that the "bytes()" and geoff> > geoff> "pseudorand()" handlers are linked to the same geoff> > hwcrhk_rand_bytes() geoff> function. Presumably only "bytes()" *needs* geoff> > to come from the geoff> hardware/driver - and "pseudorand()" could geoff> > perhaps be generated geoff> in software from hardware/driver seeding? geoff> > geoff> > ... leads to the possible conclusion that putting together a geoff> > hwcrhk_rand_pseudobytes() that did what I proposed earlier (having it geoff> > check a init flag and possibly seed the OpenSSL pool with hardware geoff> > entropy, then call RAND_SSLeay()->pseudorand()) would be a possible geoff> > route. geoff> geoff> I think this is probably the "right" solution, because geoff> otherwise there's no justification for having distinct handler geoff> callbacks in RAND_METHOD (and the two corresponding API geoff> functions). Then that's what I'll do. 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. [.. deleted idea on how to contextualise ...] geoff> But that's a philosophical suggestion. I haven't looked at the geoff> code so have no idea off the top of my head how easy this would geoff> be to do. That shouldn't be much harder than the NCONF construct I made, which basically was the exact same move on CONF... geoff> However without something like this, I can imagine that linking geoff> a software PRNG into the ncipher code will require new global geoff> state, ugly hooks, and possibly headaches making the ncipher geoff> engine easy to "unplug" at run-time w.r.t. reference counts and geoff> what-not. 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. Listen, I'll code and show you the patch, then you can judge for yourself. Deal? ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. You don't have to be rich, a $10 donation is appreciated! -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See <http://www.stacken.kth.se/~levitte/mail/> for more info. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
