Note that 3rd argument to padlock_xstore is no longer void ** and second argument to more diverse, 1 and 3.
I read somewhere that with edx=3 the RNG gives the "best" random numbers.
Well, it's most "wasty" that's for sure:-) I mean it seem to compress 8 bytes to 8 bits.
Wasty ... maybe. But you usually need not too much bytes with a good entropy instead of a fast flow of numbers with poor entropy. How about using the "slow" variant as RNG and the fast one as PRNG? There are different entries for both in the RAND_METHOD structure.
I'm actually leaning toward opinion to #if 0 RNG at initial commit to CVS. The evaluation report (at via site) maintains that edx=3 should be used for non-secure applications [such as monte-carlo simulations]. For cryptographic applications they recommend to pool values collected with edx=0 and whiten them with secure hash. For all applications they explicitly discourage rep prefix and recommend to thoroughly check returned eax after each xstore instruction. Another concern is that registering RAND_METHOD has an "usurping" effect on RAND_bytes and proposed code provides no error control whatsoever. In other words in my opinion further consideration is required... Shall we settle for this for now?
I also wonder if you have any hints on what one should look for if one wants to build system based on this CPU? Particular CPU models (steppings to avoid), mothercards (would any 370 card do?), cooling required... Stuff like that... A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
