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

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

>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