Re: swipe working on infinity.c2.org
I got one of the disks. Amusing disclaimers on the back. Haven't tried reading it yet. When I talked to Phil Karn months ago about IP encryption, he was talking about encrypting each packet independently - I guess you have to do that with IP since it's not a reliable protocol. But it sounded a little risky to me - maybe vulnerable to attack via known bits at the start of each encrypted section. Encrypting at the TCP level would allow inter-packet mixing, but then you miss all the UDP protocols such as (old) NFS. Maybe you could post a quick summary of the encryption mode used? --- Jef
When I talked to Phil Karn months ago about IP encryption, he was talking about encrypting each packet independently - I guess you have to do that with IP since it's not a reliable protocol. But it sounded a little risky to me - maybe vulnerable to attack via known bits at the start of each encrypted section. Encrypting at the TCP level would allow inter-packet mixing, but then you miss all the UDP protocols such as (old) NFS.
My unreleased KA9Q NOS version of SwIPe (I really need to converge to ji/mab's version) adds a sequence number in the header just above IP that is covered by the encryption (DES CBC). This acts as an IV that ensures different ciphertext every time even when identical packets are sent. The only part of the packet left in the clear is the IP header. An eavesdropper has no knowledge of the application or the transport protocol in use, or even if there's another IP datagram buried inside the encrypted part (e.g., the swipe boxes are providing a secure tunnel for other hosts). These are all advantages of IP-level encryption over doing it above TCP. The main disadvantage is overhead -- Van Jacobsen TCP/IP header compression breaks. Phil
Phil Karn says:
These are all advantages of IP-level encryption over doing it above TCP. The main disadvantage is overhead -- Van Jacobsen TCP/IP header compression breaks.
Of course, one could simply compress the encapsulated packets -- after all, in some sense any pair of hosts running swIPe between them have produced an odd sort of point to point link between them. Perry
Jef Poskanzer says:
When I talked to Phil Karn months ago about IP encryption, he was talking about encrypting each packet independently - I guess you have to do that with IP since it's not a reliable protocol.
Well, you largely have to. In fact, swIPe doesn't necessarily require that. swIPe in fact requires very little. :-)
Maybe you could post a quick summary of the encryption mode used?
There isn't one per se -- at least in the sense that none is standardized since that would be inappropriate. The kind of encryption gets negotiated in a protocol at another level. swIPe just defines packet formats, really. If you want details, you ought to look at the internet draft (on the disk, or available from ftp://research.att.com/dist/mab), the paper (also on the disk and at research) and the code. I believe that the prototype on the disk is just using DES in CBC mode for the moment, but other modes/cyphers have hooks defined for them. Ports to new platforms, new cyphers, and new functionality are very welcome, btw. Perry
participants (3)
-
Jef Poskanzer -
Perry E. Metzger -
Phil Karn