I'm actually leaning toward opinion to #if 0 RNG at initial commit to CVS. ... Shall we settle for this for now?
Well ... yes. RNG is not that critical (although it's a loss to not use it when it is there). But go ahead with the CVS commit without RNG.
The idea I'm pondering over is to daisy-chain this engine and default RAND_SSLeay. I mean instead of returning xstore output directly to user we can have the engine feed RAND_SSLeay pool with this data and thus whiten it. But for now RNG is still disabled. Attached is "commit candidate," which is prepared for future processor steppings (*_cipher_omnivorous), optimized for small input (alloca instead of fixed realign buffer size), as well as "ported" to Windows. Could you verify that it works? I mean Linux part (as for Windows how is VMware going?) Then I wonder if you could post performance data for all three key lengths with and without -engine, as well as for smaller PADLOCK_CHUNK values. A lot of thanks in advance. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
