[16567] in cryptography@c2.net mail archive
Re: SSL/TLS passive sniffing
daemon@ATHENA.MIT.EDU (Florian Weimer)
Wed Dec 22 11:26:33 2004
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: Florian Weimer <fw@deneb.enyo.de>
To: cryptography@metzdowd.com
Date: Sun, 19 Dec 2004 17:24:59 +0100
In-Reply-To: <20041130183942.GR27261@piias899.ms.com> (Victor Duchovni's
message of "Tue, 30 Nov 2004 13:39:42 -0500")
* 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 majordomo@metzdowd.com
