Re: Telnet Encryption Specification

["Theodore Y. Ts'o" <tytso at mit.edu>]

   Date: Tue, 03 Feb 1998 19:24:26 -0500
   From: Ken Hornstein <kenh at cmf.nrl.navy.mil>

   Mark Eichin made a cryptic comment a little while ago that the
   current CFB encryption mode used by the V5 telnet (the fact that
   it just XOR's your plaintext against the encryption stream to get
   the output) opens you up to an attack.  I confess that I didn't
   quite understand what he was talking about, but someone smarter
   than me (perhaps Mark himself) should look at this and possibly
   propose a new encryption option that fixes this problem.

This certainly is true of OFB, which merely runs DES in a feedback loop
and then XOR's your plaintext against the resulting "pad".  If you'll
note, I added a "security considerations" paragraph about why this is
weak, and noting that perhaps in this day and age, maybe we should drop
it.

In cipher feedback mode, though, it's more than a simple XOR plaintext
against an encryption stream.  CFB looks like this:


    key --->+-----+
         +->| DES |--+
         |  +-----+  |
	 |           v
 INPUT --(--------->(+)+---> DATA
         |             |
	 +-------------+
        

Given that you're still doing an XOR with the data, it's possible to do
a known-plaintext substitution attack --- if you know what the stream
is, you can diddle bits in the cipher text to cause text of your choice
to come out the other end.  This attack only works for bytes in a single
eight bytes chunk, though, since the result of the next eight bytes of
decryption will be garbaged as a result.  So while this is a real
weakness, the fact that the following eight bytes of data get garbaged
generally means that the attack can get noticed, but that of course is
no guarantee.

The fix for this would be to use CBC(*), but that has the down side of
being slower and requiring more bytes on the wire, since telnet is a
character-at-a-time protocol, and CBC requiers that you block data into
8 byte chunks.  (The advantage of CFB and OFB is that they work well
with streaming protocols.)

It would certainly be possible to write a specification for DES-CBC.
Volunteers to help out in writing a DES-CBC mode or a 3DES-CBC mode
would be greatfully received.  :-)  If you're interested, let me know...

					- Ted

(*) Note: Cryptographers would say that even using CBC isn't the best
way to protect against this; DES provides data confidentiality; data
integrity is a completely different service, and if you want data
integrity, you should be using a message authentication code service
instead.  Unfortunately, this is even more painful for streaming
applications like telnet.  You can do it, but the overhead hit starts
getting fairly high.