* Victor Duchovni: > The third mode is quite common for STARTTLS with SMTP if I am not > mistaken. A one day sample of inbound TLS email has the following cipher > frequencies: > > 8221 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) > 6529 (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))

The Debian folks have recently stumbled upon a problem in this area: Generating the ephemeral DH parameters is expensive, in terms of CPU cycles, but especailly in PRNG entropy. The PRNG part means that it's not possible to use /dev/random on Linux, at least on servers. The CPU cycles spent on bignum operations aren't a real problem. Would you recommend to switch to /dev/urandom (which doesn't block if the entropy estimate for the in-kernel pool reaches 0), and stick to generating new DH parameters for each connection, or is it better to generate them once per day and use it for several connections? (There's a second set of parameters related to the RSA_EXPORT mode in TLS, but I suppose it isn't used much, and supporting it is not a top priority.) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]