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

[Scott Fluhrer <sfluhrer at cisco.com>]

At 12:22 PM 8/26/2004, Hallam-Baker, Phillip wrote:
> > This is like saying that hacksaws are not recommended because some
> > people manage to lose fingers using them.
>
> In my basement I have a Delta unisaw, if used improperly it can
> throw the wood you are cutting back at you at 200 mph. So I have
> safety equipment fitted that prevent this.
>
> The saw can be used safely without the safety equipment, and in
> fact sometimes it can't be used. But that does not make it
> recommended.
>
>
> RC4 has related key weaknesses that make it a poor choice of
> cipher. Shamir's attack was a cryptanalytic one.

Actually, how WEP used it caused other significant weaknesses, even beyond 
what we found:
- Only 2^24 distinct keystreams.  This means that after (at best) 16 
million packets, you're reusing keystreams, even if RC4 had no related key 
weakness.
- No real packet authentication.  With WEP, this mean that if he collects 
an encrypted packet and guesses its contents, he can then spoof *any* 
packet (possibly limited to packets of the same length).



> > The trivial attack you mentioned is irrelevant because there
> > should not
> > be a second plaintext enciphered with the same stream.
>
> There should not be known plaintext either, but there usually
> is known plaintext arround.

Actually, real ciphers don't make any such assumption.


> I don't think that any stream cipher should ever be recommended,
> they should only be used if a cryptographic specialist looks
> at the application and comes to a conclusion that the implementation
> is sound.
>
> I would prefer there to always be a block cipher available as an
> alternative since empirically block ciphers turn out to be pretty
> robust in the face of bad crypto design. SSL 1.0 and WEP 1.0 are
> both much more secure if you use a block cipher.

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.

--
scott


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