Re: Malleability of CIPE traffic

Hello,

> CRCs appear to provide non-malleability, but they are not
> cryptographically strong, even when encrypted.  For example, if one

Yes, that's a known weakness in CIPE, which was recently discussed on
the mailing list too [I'm CCing the list]. The original reason for
choosing the CRC checksum was performance; however with today's
computers this is rather moot.

I think the next version of the protocol should use either plain SHA-1
or HMAC/SHA-1 as checksum. But then I'd like to redesign the packet
format anyway, so no compatibility glue is needed.

> You could *reduce* the bandwidth usage by using sequential 32-bit IVs
> and never sending more than 2^32 packets without rekeying (which is
> what you should do with 64-bit random IVs anyway).  Sequential IVs also
> make replay detection much easier.

Although I don't see an actual attack coming out of that, this
proposal somewhat makes me nervous...

(The maximum of 2^32 packets without rekeying is actually implemented
in CIPE but as a maximum of 2^16, see MAXBLKS and cipe_checkskey() /
cipe_checkrkey())

> You could save a few more bytes by using "ciphertext stealing", a
> trick with CBC to make the ciphertext exactly the same size as the
> plaintext.  Probably not worth it, and it reveals a little more about
> each packet.

This is a lesser concern nowadays. (Originally, I worried much about
packet overhead, but those were the days of 2400bps modems.)

> You might want to mention traffic analysis on your "vulnerabilities"
> section.  A lot of information can be recovered from keystroke timings
> (about 1-2bits per character of a password, for example) and many many
> systems send a packet for each keystroke (ssh, telnet, X, VNC, etc...)

I think this is mentioned somewhere; I have hooks in the protocol for
filling the line with dummy packets (but that's not implemented in the
driver; if really needed a userspace daemon could do this too.)

> password.  There's really not a lot you can do about traffic
> analysis without drastically affecting responsiveness or bandwidth
> usage; the only systems I know of that convincingly address the
> problem are mixmaster (for email), freedom(TM) (for IP), and
> anon-proxy (for HTTP).  In each case, they rely on mixing your packet

okay, these are the heavyweight solutions. But since CIPE packets are
designed to look like random garbage (for this reason there is no
analyzable header and I'm proposing to do away even with the one bit
of unencrypted stuff we have now in each packet) it should probably be
sufficient to fill the line with more true random garbage and pad the
payload to a random length too, if this is needed.

> with a swarm of other packets to conceal your traffic patterns.
> Mixmaster uses packets of a uniform length (10 kb?) and keeps a pool
> of packets, sending a random one out whenever one comes in.  Such
> tactics are just not going to cut it for IP.  (Well, you could

This will _kill_ performance of any TCP connection running over that
line...

> In short, resistance to traffic analysis is a hard problem, not
> well-studied, and I don't think there's any hope of solving it
> satisfactorily; just warn your users that it's a problem.

I think this is a fact everyone analyzing a system that deeply should
know, but more mention of it could be in order.

regards

Olaf


--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>