[3942] in cryptography@c2.net mail archive
Re: AUCRYPTO: Bidzos pro-wassenaar posturing.
daemon@ATHENA.MIT.EDU (Eric Young)
Mon Jan 11 09:28:22 1999
Date: Mon, 11 Jan 1999 16:29:42 +1000 (GMT+1000)
From: Eric Young <eay@uq.net.au>
To: Enzo Michelangeli <em@who.net>
Cc: Darren Reed <darrenr@reed.wattle.id.au>, Julian Assange <proff@iq.org>,
cryptography@c2.net
In-Reply-To: <022f01be3b79$cb99f9e0$88004bca@home>
On Sat, 9 Jan 1999, Enzo Michelangeli wrote:
> It's been a while that I've been wondering why no popular browser (either
> commercial or free) seems to support SSL3's
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite, which does not require any
> algorithm controlled by RSADSI. The thing is puzzling, especially
One could argule that cryptozilla does,...
This is something I've had an opinion on for quite some time. I believe
it is basically people only implemented the lowest common denominator.
SSLeay, as far as I could tell, was about the only C SSL library to
implement the EDH ciphers and that was more because it was a protocol
implementation instead of a requirement for a product. There are a few
Java based SSL implementations implementing them (EDH/DSS). Ignoring the
RSA patent issue, EDH with RSA/DSA gives far better security than RSA
since once the EDH key is wiped, there is no decoding sessions with the
servers RSA key.
The largest problem most people seem to be having with implementing TLS is
that they never implemented the EDH ciphers, which are manditory with TLS.
For SSLeay, it was basically a matter of fix some error codes, put in
HMAC, and there was TLS support (mostly :-). I took the pain adding SSLv3
into SSLeay while most others are now going to take it going to TLS.
The main negative for EDH is that it is very CPU expensive and this is not
a good thing to do to a web server. An approximate rule of thumb is that
the CPU load for the same size key (512 RSA vs 512 EDH/RSA) is that the
EDH is 9 times as great (or 5 times if you 'reuse' the temp EDH key a
few times). The client takes this full CPU load as well (8 times RSA
private).
For that 486-66 client, this would mean a one second wait, instead of the
near zero cost of a public key RSA operation. If the session-id caching
is not working very well, this would be brutal to slow clients.
eric
--
Eric Young | eay@pobox.com
