G'day On November 22, 2003 07:32 pm, Richard Levitte - VMS Whacker wrote: > Hmm, I see what you're saying. It seems to me like the points you're > raising get in conflict with each other.
You should be used to it by now... :-) > On one hand, you've raised > the point that changing the behavior of the hwcrhk_rand_bytes() would > be a kind of betrail (sp?) of what has been promised with the current > code in terms of security. On the other hand, leaving the choice to > the user becomes another issue of forcing them to change their code. > I feel that we need to make a compromise somewhere, or perhaps simply > not bother with it (and thereby leaving it to the user to make ugly > hacks to get around the performance problem that they see). Yup. > Of course: > > geoff> BTW: are you sure that it's not just a question of the ncipher > geoff> RAND_METHOD implementation being over-enthusiastic? I'm looking > geoff> at "hwcrhk_rand" right now, and I see that the "bytes()" and > geoff> "pseudorand()" handlers are linked to the same > hwcrhk_rand_bytes() geoff> function. Presumably only "bytes()" *needs* > to come from the geoff> hardware/driver - and "pseudorand()" could > perhaps be generated geoff> in software from hardware/driver seeding? > > ... leads to the possible conclusion that putting together a > hwcrhk_rand_pseudobytes() that did what I proposed earlier (having it > check a init flag and possibly seed the OpenSSL pool with hardware > entropy, then call RAND_SSLeay()->pseudorand()) would be a possible > route. I think this is probably the "right" solution, because otherwise there's no justification for having distinct handler callbacks in RAND_METHOD (and the two corresponding API functions). > Geoff, I don't want to make a unilateral decision here. No sweat - it's just that you're the one coding it, so ... :-) Well, as you asked. I think one of the main problems is that there's no context type in crypto/rand/ - there is essentially just global state, so IMHO having the vtables is of dubious value anyway. Should we contextualise the crypto/rand/ code using a RAND object type? One way to migrate to this would be to declare a global RAND object to replace the current global state, declare new "_ex()" functions and deprecating the old ones (but reimplement them to use the newer _ex() ones), and have it such that supplying a NULL pointer to the "_ex" functions amounts to specifying the global RAND object. This way, nesting a software PRNG into the ncipher engine becomes pretty easy - all it needs is its own RAND object (hooked to the RAND_SSLeay() vtable/method) and then it knows that its state won't get "polluted" (or "drained") by independant PRNG operations that don't go through the ncipher RAND implementation. But that's a philosophical suggestion. I haven't looked at the code so have no idea off the top of my head how easy this would be to do. However without something like this, I can imagine that linking a software PRNG into the ncipher code will require new global state, ugly hooks, and possibly headaches making the ncipher engine easy to "unplug" at run-time w.r.t. reference counts and what-not. 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]
