On November 22, 2003 05:40 pm, Dr. Stephen Henson wrote: > On Sat, Nov 22, 2003, Geoff Thorpe wrote: > > BTW: are you sure that it's not just a question of the ncipher > > RAND_METHOD implementation being over-enthusiastic? I'm looking at > > "hwcrhk_rand" right now, and I see that the "bytes()" and > > "pseudorand()" handlers are linked to the same hwcrhk_rand_bytes() > > function. Presumably only "bytes()" *needs* to come from the > > hardware/driver - and "pseudorand()" could perhaps be generated in > > software from hardware/driver seeding? > > Interesting point. > > For the usual static RSA modes only the RSA premaster secret uses > RAND_bytes() and that's done on the client side.
Yeah, there are certain things that would be RAND_bytes(), but I would imagine the critical-loop stuff that grills the PRNG throughput would tend to be RAND_pseudo_bytes() mostly (eg. primality testing, padding, etc). > The server only calls RAND_pseudo_bytes() because all its random data > gets sent (at least for an initial handshake) in plain text anyway. > > EDH ciphersuites (which few browsers use) would use RAND_bytes() for > the ephemeral DH key generation but that wouldn't happen for a resumed > client connection. Yeah, but compared to the cost of generating a DH key, the drain on the RNG should be minor anyway. I think the problem being seen with the ncipher stuff is that it is being asked for too much random data and it gets drained too quickly. AFAICS, if code uses RAND_pseudo_..., then that should be an implicit acknowledgement of the "P" in PRNG and so having that data produced in software from hardware seeding should be perfectly acceptable from a security perspective. Of course, because of that same distinction, RAND_bytes() should come directly from the hardware support (if the driver in turn uses its own PRNG front-end to hardware, that's the vendor's business). Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
