|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: SSL/TLS passive sniffing |  |
- To: [EMAIL PROTECTED]
- Subject: Re: SSL/TLS passive sniffing
- From: Florian Weimer <[EMAIL PROTECTED]>
- Date: Sun, 19 Dec 2004 17:24:59 +0100
- In-reply-to: <[EMAIL PROTECTED]> (Victor Duchovni's message of "Tue, 30 Nov 2004 13:39:42 -0500")
- References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
- Sender: [EMAIL PROTECTED]
 |
| |
* 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]
| |