Hi again, On Thursday 11 September 2008 09:32:14 Geoff Thorpe wrote: > On Thursday 11 September 2008 09:06:39 Harald Welte wrote: > > On Thu, Sep 11, 2008 at 10:22:38PM +1200, Michal Ludvig wrote: > > > 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.
Looking at this in more detail, the current s/w PRNG implementation keeps a running 'entropy' count and when that reaches a certain threshold, it stops maintaining an entropy counter because the PRNG is considered sufficiently seeded. Each platform (roughly speaking) has its own implementation of RAND_poll() which does some canonical seeding, which may be enough to get the PRNG off the ground, or if not, the application will need to RAND_add() (or RAND_seed()) some more entropy before the PRNG is ready. In any case, this doesn't adapt so well to a model where entropy sources live as callbacks and get called by the PRNG when required. It's more a model where an entropy source should just stuff its entropy into the PRNG as soon as it gets a chance, and preferably as much of the stuff as it has handy. It can always add more later and no harm will be done, but there's no obvious way to add a hook to ask for entropy automatically. With this in mind, I'm wondering if the simplest thing to do isn't just to have the padlock (or any other) engine call RAND_add() with some entropy during the init() handler of the ENGINE itself (rather than in a RAND_METHOD). That doesn't solve the problem of adding more entropy as time goes by, but it's better than the current situation (only having a RAND_METHOD mechanism you can't use at all), and moreover it requires no interface changes, just implementation... Thoughts? 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]
