Re: SSL/TLS passive sniffing

[Victor Duchovni <[EMAIL PROTECTED]>]

On Sun, Dec 19, 2004 at 05:24:59PM +0100, Florian Weimer wrote:

> * 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?
> 

Actually reasoning along these lines is why Lutz Jaenicke implemented
PRNGD, it is strongly recommended (at least by me) that mail servers
use PRNGD or similar.  PRNGD delivers psuedo-random numbers mixing in
real entropy periodically.

EGD, /dev/random and /dev/urandom don't produce bits fast enough. Also
Postfix internally seeds the built-in OpenSSL PRNG via the tlsmgr process
and this hands out seeds for smtp servers and clients, so the demand for
real entropy is again reduced.

Clearly a PRNG is a compromise (if the algorithm is found to be weak we
could have problems), but real entropy is just too expensive.

I use PRNGD.

-- 

 /"\ ASCII RIBBON                  NOTICE: If received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]