In message <pan.2005.10.02.14.00.51.227089@pc313.imc.cas.cz>, Pavel Cahyna writ
es:
>On Tue, 27 Sep 2005 09:14:31 -0400, Steven M. Bellovin wrote:
>
>Hello,
>
>> Lack of integrity-checking in a crypto protocol is indeed serious.  For 
>> telnet, it's' slightly worse for CFB than for CBC, but both are 
>> seriously flawed against replay attacks.
>
>Is this flaw a problem in practice? If the connection data are encrypted
>with a secret key, how can an attacker replace them with different data
>without producing just uncontrollable garbage? If he can replay
>previously transmitted data, what can he achieve, since he don't know what
>actually he's replaying?
>

We've seen little of in practice, since buggy software is a much easier 
way in to most systems.

For discussion of how some ciphers fail badly with lack of integrity 
checking, see http://www.cs.columbia.edu/~smb/papers/badesp.pdf (or 
.ps), a paper of mine from 1996.  That focuses on CBC and stream 
ciphers such as RC4, since those were the ones of interest for IPsec.

As for knowing what you're replaying -- traffic analysis can yield an 
amazing amount of information about what's going on.  Or consider this 
attack.  Record the ciphertext traffic during a session.  Wait for a 
pause, then send the target some email that will merit a resopnse.
When the typing starts, and you think your target is working on the 
reply -- typed text sticks out like a sore thumb, because of very 
characteristic inter-character delays -- replay the ciphertext of 
interest.  If the replayed text includes the reply to another email, 
there's probably a ^D in there, ending this one, too.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb