Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!FLASH.BELLCORE.COM!karn
From: karn@FLASH.BELLCORE.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Authentication (was: No more NFS flames)
Message-ID: <8701092303.AA04975@flash.bellcore.com>
Date: Fri, 9-Jan-87 18:03:59 EST
Article-I.D.: flash.8701092303.AA04975
Posted: Fri Jan  9 18:03:59 1987
Date-Received: Fri, 9-Jan-87 23:43:10 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 16
Approved: tcp-ip@sri-nic.arpa

Just encrypting the existing Internet checksum won't protect against someone
monitoring good packets and modifying them in such a way that the checksum
is unchanged.  This is easy since Internet checksums use a simple linear
algorithm; consider that swapping any pair of 16-bit integers within the
message leaves the checksum unchanged.

Also, since the checksum is only 16 bits, it isn't at all hard to watch the
channel and construct a lookup table mapping all 65536 possible checksum
values to their encrypted counterparts.

The value of the cipher checksum needs to depend in a highly nonlinear and
unpredictable (without the key) way on both the values and the positions of
bits within the message. It needs an "error extension" property.  Cipher
block chaining does this.

Phil