On November 20, 2003 08:49 pm, Richard Levitte - VMS Whacker wrote: > I think piggy-backing would be the best approach. At this point, I'm > seriously messing the function pointer int (*poll)(void) in > RAND_METHOD (I can add it to 0.9.8-dev, but I think we need to do > something for 0.9.7-stable as well). Such a pointer would make it > possible to have a polling function in the hw_ncipher.c module that > would simply fetch a bunch of bytes from the nCipher box and > RAND_add() them. This would require, of course, that all other > function pointers in the engine's RAND_METHOD be a copy of the > pointers in the structure reference returned by RAND_SSLeay().
Hmm. I guess this is one way to do it. I think the fundamental problem is that openssl really wants the PRNG to be a different layer to the RNG. This is what your vtable tricks try to achieve (kind of analogous to what is done with most engine RSA_METHODs, where the bn_mod_exp and rsa_mod_exp handlers sit below generic/reused "padding-layer" handlers). Given that openssl uses randomness for loads of stuff like padding, primality testing, [etc], it would make sense to stick RNG plugins behind the heaving frothing masher that is RAND_SSLeay(), so in "normal" situations the RNG is used only for (periodic) seeding rather than ongoing PRNGeneration. This way, we could make the PRNG replacable too (PRNG_METHOD?), with perhaps an alternative builtin implementation that passes through directly to the RNG back-end without using md_rand.c. Eg. this would be useful to run reproducible debugging tests, or use high-speed randomness sources directly without requiring message-digests, etc. In a sense, the current RAND_METHOD vtable tries to achieve this using just the one "layer" - and again, this is analogous to RSA_METHOD which provides one "layer" for what is really more like two interfaces layered one on top of the other. > For 0.9.7-stable, I suggest the following hack: > > have hwcrhk_rand_bytes and hwcrhk_rand_status check a static variable > (initilized to 0), and if it's 0, they will grab a bunch of random > bytes from the box and feed them into the OpenSSL pool with > RAND_seed(), and then call RAND_SSLeay()->bytes() and so on, > respectively. This requires, again, that all other function pointers > in hwcrhk_rand have the same values as in the structure returned by > RAND_SSLeay(). I would at least discuss this with someone from ncipher.com - considering that 0.9.7 is supposed to be stable, people might get a bit stroppy if something as security-sensitive as PRNG handling changed on them without warning. In particular, the EU laws mandating hardware crypto in certain situations are presumably for reasons of (i) key-management and (ii) PRNG. So if we make a change that transparently causes the hardware to only be used for initial seeding instead of ongoing PRNG functions, are we inadvertently creating non-compliance? Yeah I agree, this would be a crock if it were true - but not everything works on technical merit in this world ... :-) (Check the world's main desktop O/S, for example.) > geoff> The other thing would be to not set the nCipher RAND_METHOD as > geoff> a default, and instead have the nCipher engine's "init()" > geoff> handler offer hardware entropy to whatever *is* the default > geoff> method. :-) Yeah I know, sick sick sick. > > Yup, it is, so I'd avoid that method... Well, it's arguably a more *honest* solution than vtable-switching that cuts the ncipher out of ongoing PRNG duties and leaving it for seeding only. But the thing that worries me more than this is to what extent we can change underlying PRNG-mechanics in a stable branch. Particularly one that is security-sensitive and could cause anal/security/audit types to throw a hissy fit. The head of CVS is less of an issue IMHO. 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]
