Re: Modem encryption proposal

Crypto synchronization seems to be a problem mainly in real-time
appliations like digital voice, where you don't have a reliable
protocol underneath you.

I advocate two approaches that don't seem to have been pursued much
yet, at least in the Internet: per-packet encryption (and possibly)
authentication) just above the IP layer, and stream encryption just
above TCP.

The former technique has the advantage of denying your adversary the
maximum amount of information, because only the IP header is in the
clear.  The transport header and all user data is protected, so an
eavesdropper can't tell which applications are communicating. And with
IP-in-IP encapsulation, you can even deny him knowledge about which
machines are actually communicating - a network-level service
analogous to anonymous remailers. With authentication, network level
security also provides good protection against replay attacks.

The latter technique (encrypting above TCP) has the advantage of being
more efficient (it doesn't break Van Jacobson TCP/IP header
compression), which may make it desirable for some interactive
sessions. This is essentially how encrypted Kerberos Telnet works now,
although I would like to generalize the service to work with any TCP
client.

Phil

-----BEGIN PGP SIGNED MESSAGE-----

> Crypto synchronization seems to be a problem mainly in real-time
> appliations like digital voice, where you don't have a reliable
> protocol underneath you.

Phil, there is more to this than meets the eye.  What happens if I, as
an attacker, start feeding extra characters onto the modem line?
Granted, I wont know what you are saying, since the link is encrypted,
but if I can get an extra character on there, then the decryption will
lose sync, and wont return the proper value...

For example...
	Sender:  	more foo
	Encrypted data:	HaoVwAog

	Received data:	HaooVwAog
	Decrypted:	morOmf&sm

Now what?  The sender and receiver are out of sync....  I believe this
was what Nickey was talking about..  I was discussing this problem
with a few people and haven't come up with a good, viable solution...
yet.

> This is essentially how encrypted Kerberos Telnet works now,
> although I would like to generalize the service to work with any TCP
> client.

Uhh, there is a kstream package somewhere (or am I thinking of
vapor-ware, it's late and I'm tried).  This wouldn't be very hard to
create.  In fact, I was hoping to do something like this with my
Thesis...  Although it might get left for "future work".  This depends
upon having a clearly denoted stream, which neither telnet nor kermit
provide a good interface.  (Trust me on this -- it took me a while to
try to create one for the little I've hacked them for my Thesis).

- -derek

PGP 2 key available upon request on the key-server:
	pgp-public-keys@toxicwaste.mit.edu
- --
  Derek Atkins, MIT '93, Electrical Engineering and Computer Science
     Secretary, MIT Student Information Processing Board (SIPB)
           MIT Media Laboratory, Speech Research Group
           warlord@MIT.EDU       PP-ASEL        N1NWH

-----BEGIN PGP SIGNATURE-----
Version: 2.2

iQBuAgUBK8qLvTh0K1zBsGrxAQG39QLFFn0/Nz1zVRi6kHp+j+R0KAQQlEL6588d
RfSshGGFhuXIJE/S8BP8kqLrKeSeRgSbil3zBLQZNeconnExaq6VUeO5Yvn9U/0S
cHggKYBTlcz1zqjp7BLxLz8=
=TBaq
-----END PGP SIGNATURE-----

>> Uhh, there is a kstream package somewhere (or am I thinking of
>> vapor-ware, it's late and I'm tried).  This wouldn't be very hard to
	kstream was written by Ken Raeburn of Cygnus as part of our
Cygnus Network Security work (support for Kerberos V4) and was
included in the MIT Kerberos V4 patchlevel 10 "final" release. Our
kerberized rlogin and rcp use it to handle encryption, it cleans up
the code a bit and makes it easier to modify other programs.

				_Mark_ <eichin@athena.mit.edu>
				MIT Student Information Processing Board
				Cygnus Support <eichin@cygnus.com>