[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Cfrg] Re: [saag] Bad day at the hash function factory



At 07:28 AM 8/30/2004, Russ Housley wrote:
Scott:

Can you confirm that the TLS 1.1 specification addresses these concerns?
(See draft-ietf-tls-rfc2246-bis-*,txt)

Well, the first concern is discussed in the implementation note in 6.2.3.2. If the implementation actually pays attention to it (and obeys the MUST found there), the implementation should be immune to it.


The second concern exploits the implicit predictable IV in TLS 1.0. The explicit IV in TLS 1.1 (and the recommended procedures for generating the IV listed in section 6.2.3.1) would eliminate it as a concern.


Russ


At 06:03 PM 8/26/2004, Scott Fluhrer wrote:

Actually (since you bring it up), there are two known potential weaknesses in SSL if you use a block cipher that don't apply if you use RC4:
- Vaudenay published an attack on SSL based on modifying an encrypted record, and distinguishing a 'bad padding' error vs. a 'bad MAC' error. The RFC doesn't mandate that those two situations be distinguishable by an attacker, but there have been real implementations where they are.
- If the attacker has partial control over the data being encrypted, he can select initial plaintext blocks so that (with the IV from the previous ciphertext) allows him to validate potential decryptions of previous ciphertext blocks.


Neither of these attacks are that serious (as they involve somewhat obscure conditions), but they are weaknesses that SSL with RC4 does not have.


The real point I'm trying to make: "stream cipher bad/block cipher good" is a drastic oversimplication. An unsound implementation can use a block cipher insecurely, just like it can use a stream cipher insecurely. In either case, it is important to be aware of the strengths and limitations of whatever cryptographical primitives you use.


_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg


_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg