[2599] in cryptography@c2.net mail archive
Re: safety of SSL 2?
daemon@ATHENA.MIT.EDU (EKR)
Tue Apr 28 17:26:33 1998
To: Eric Young <eay@cryptsoft.com>
Cc: Rick Smith <rick_smith@securecomputing.com>,
Rodney Thayer <rodney@sabletech.com>, cryptography@c2.net
From: EKR <ekr@terisa.com>
Date: 28 Apr 1998 14:19:10 -0700
In-Reply-To: Eric Young's message of "Tue, 28 Apr 1998 15:47:42 +1000 (EST)"
Eric Young <eay@cryptsoft.com> writes:
> On Mon, 27 Apr 1998, Rick Smith wrote:
> > There are several problems with SSL 2, but my "favorite" is the use of the
> > same crypto key for both encryption and integrity protection. So if you're
> > talking in "international" mode with 40 bit keys, you face an integrity
> > risk as well as a disclosure risk, assuming the adversary has some really,
> > really serious computing power available for real time cracking. This
> > should still be safe enough for commercial credit card transactions, but
> > it's probably not safe enough for significant, irreversible transactions
> > ("launch nukes").
>
> But this is still the case with SSLv3 and TLSv1. This is an issue of export
> ciphers. Granted, there is the SSLv2 'rolback to export cipher' attack.
> SSLv3 introduced seperate authentication/encryption keys, (ephemeral DH)
> but just about no-one implements them (until recently it was only SSLeay and
> most of the java implementation). There is more of a security hole because of
> the lack of backward security if the server key is ever compromised. All
> trafic in the past is disclosed. (I'm ignoring the ephemeral RSA which
> only operates if you have an export cipher or signing only RSA keys).
Uh, not quite. SSLv3 introduced two types of separation:
Asymmetric: Separate Signature and Key Establishment keys
Symmetric: Separate Traffic Encryption and Message Authentication keys.
In SSLv2, the master key is composed of a clear section and an
encrypted section. For export ciphers, the encrypted section
is 40 bits long. The combined master key is used to generate
the traffic encryption keys (which also serve as the MAC keys).
So, since there are only 40 bits of entropy, it's straightforward
to search the keyspace and recover the keys. (This has been
demonstrated.) Once you have the keys, you can mount a
message integrity attack as well as read the traffic.
In SSLv3, the master key is large and completely secret. This is
run through an expansion function to generate both the
message encryption keys and the traffic authentication keys.
For export ciphers, the high order 40 bits of the traffic encryption
keys are run through an expansion function (along with some
public data) to generate the actual traffic encryption keys.
Consequently, mounting a message integrity attack requires searching
the whole message authentication key space (128/160 bits depending.)
though mounting an attack dedicated to reading the traffic only
requires searching 40 bits of keyspace for export ciphers.
As you indicate, SSLv23 also provides for separation of Key Establishment
Keys and Signature Keys. The effect of this separation is to permit
frequent changes of Key Establishment Keys, this minimizing the
impact of compromise of any one key. This is relevant in two cases:
1. You want to use a much longer signature key than you use
a key establishment key. (For instance, because US export regulations require
that you use 512 key establishment keys).
2. You want to provide "Perfect Forward Secrecy" (what you're calling
backward security).
This separation doesn't have any impact on the relative security
of Message Authentication as compared to Traffic Encryption because
the master key is always exchanged using the Key Establishment Key
no matter what.
In short, even in the common static RSA case, SSLv3 offers superior
resistence to integrity attacks when exportable ciphers are used.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."
