Michal,

thanks so much for your detailed feedback. It is much appreciated.

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.

> 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.

>> which seems to indicate that Michal Ludvig's original code has it enabled,
>> but OpenSSL mainline disabled it.
>>
> 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.

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 :)

Cheers,
-- 
- Harald Welte <[EMAIL PROTECTED]>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Attachment: signature.asc
Description: Digital signature

Reply via email to