In message <[EMAIL PROTECTED]> on Thu, 20 Nov 2003 20:20:18 -0500, Geoff Thorpe <[EMAIL PROTECTED]> said:
geoff> Howdy, geoff> geoff> On November 20, 2003 06:56 pm, Richard Levitte - VMS Whacker wrote: geoff> > So, an idea could be, at least for the hw_ncipher.c/e_ncipher.c code geoff> > to use the nCipher RNG only to seed the internal OpenSSL pool. We geoff> > made a hack yesterday that gave exactly that effect, and it gave much geoff> > better performance than the .5s stalls about every 15th request :). [...] geoff> So, one possibility is to make the ncipher RAND_METHOD piggy geoff> back on top of software mashing/whitening logic (presumably geoff> topping up with hardware entropy from time-to-time) - or just geoff> have rand_lib.c treat certain NULLs or flags in RAND_METHOD as geoff> an indication to take care of this automatically. This just geoff> goes hand-in-hand with needing a RAND_METHOD implementation to geoff> furnish what has always been expected from the default builtin geoff> vtable. 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(). 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(). 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... Thoughts on my ideas above? ----- 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]
