On Thursday 11 September 2008 09:06:39 Harald Welte wrote: > On Thu, Sep 11, 2008 at 10:22:38PM +1200, Michal Ludvig wrote: > > And finally the one you already knew about. That's the final "works for > > me" version ready to be committed to openssl tree current at that time > > (may not apply smoothly anymore, I don't know): > > http://marc.info/?l=openssl-dev&m=115243758508970&w=4 > > Ok, let me dig that out, merge it with current ssl version of openssl, give > it some testing and resubmit it to the mailinglist for inclusion.
Thanks, let me know how you get on. > > I don't think there's any taboo or a strong opposition against the > > patch. It's just that Andy hasn't followed up, I sort of given up and > > moved to other projects and the whole thing has gone forgotten. > > Ok. I hope after my re-merge and testing we can get it integrated this > time. BTW, my memory is vague here, is this Padlock block only able to do one-shot hashing? > > Have a look here: > > http://marc.info/?l=openssl-dev&m=109113625526391&w=2 > > and in the corresponding thread for the discussion. > > > > FWIW even in the Linux kernel the hardware RNGs (incl. VIA PadLock) are > > not used directly for RNG output but instead to feed the entropy pool. I > > quite agree with the reasons why OpenSSL shouldn't use whatever it gets > > from PadLock RNG *directly* as a stream of random numbers. Unfortunately > > as soon as PadLock engine registers as a RNG provider OpenSSL won't do > > any post-processing of the random data and therefore the best bet at > > that time was not to use PadLock's RNG. > > Yes, after reviewing the discussion and documentation I tend to agree. So > the best option really is to make OpenSSL use the userspace interface for > the kernel random number generator, and feed that kernel RNG's entropy pool > from the hardware RNG. Ohhhh, right, I see know. Yes this is a bit crap. The problem IMHO is that RAND_METHOD is the "wholesale replacement" interface. Ie. the entire software PRNG sits behind that interface, no matter how it obtains its entropy, and using an alternative RAND_METHOD will completely bypass the software PRNG. This makes sense for the other ***_METHOD interfaces, because they're alternatives to the s/w implementations - they can be used simultaneously, but work on completely separated contexts. In the case of the PRNG, there are no "separated contexts" nor point to having s/w and replacement PRNGs working independently. I think the sensible thing would be to stick with the s/w PRNG implementation and have it expose an inner interface for its entropy sources and let engines plug themselves into *that*, rather than acting as alternatives/replacements for the entire PRNG. > I'll submit a patch to OpenSSL which gives a more detailed description in > the comment since I think it is sort of like a FAQ for those people who > actually discover the padlocn no-RNG flag :) I will see if I can sketch an ENTROPY_METHOD that would improve this situation. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
