<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: cipe-l,AT,inka,DOT,de
Subject: About Peter Gutmann's critique of CIPE
From: Olaf Titz <olaf,AT,bigred,DOT,inka,DOT,de>
Date: Thu, 25 Sep 2003 21:34:12 +0200
Cc: pgut001,AT,cs,DOT,auckland,DOT,ac,DOT,nz
Organization: private Linux site, southern Germany

Hello all (and Peter to whom I'm CCing),

rather than answering all of the many mails (too little time :-() I'll
focus on Peter Gutmann's orignal article. He makes the following valid
points on the packet format:

1. CRC32 makes a bad message integrity protection.
2. Message padding is too small.
3. No ciphers of big block sizes can be used (related to 2).
4. No replay protection.

The part about the key exchange is less well researched:

5. Possible weak-key insertion (related to 1).
6. No replay protection in the KX.
7. Bad KX packets are ignored.
8. KX packets can be distinguished by their length.

I'll try a short answer on all of these.

1-5: The historical excuse for the packet format is performance
concerns from the days of 386 CPUs and 2400bps modems. These are
invalid nowadays, and of course a proper packet format would have
arbitrary block length, arbitrary padding, timestamps and SHA1
checksums. I've more than once dreamed of a completely new packet
format along these lines, but I'm afraid I'll not be able to implement
it because of a lack of time (and need; I'm not even using CIPE by
now...) Help is greatly appreciated. More on that later.

6: Half wrong because of the timestamps, half right because of the too
long timeout.

7: Okay, that's a problem (which is mentioned in the protocol docs
somewhere IIRC). But it doesn't matter if you can not tell the KX from
the data packets, and you are not supposed to. With a proper packet
format and an option to not use the static key for data at all, this
only leads to a DoS attack (and you always can DoS the receiver in the
ways described).

8: Wrong. KX packets are padded to a random length for precisely this
reason. Isn't that documented?

So how can that be fixed? I think the biggest problem is the packet
format, which needs a complete overhaul for a number of reasons. I'm
still not convinced that the KX is too broken as to be useful; I don't
see an attack on that when the packet format has been fixed.

_Perhaps_ an SSL-based control channel could be thought of, but this
should be integrated with PKCIPE. I'm a bit unhappy with PKCIPE too,
it really should be based on SSL, but this would ruin the easy
configuration. You would have to use (or set up yourself) a CA to use
SSL certs for authentication (something that I have already thought of
when designing PKCIPE).

So how could a new packet protocol look like? Something like this:

    m octets  IV
    2 octets  flags            ##
    4 octets  seqno/timestamp   #
    n octets  payload data      #
    p octets  padding           # encrypted
    q octets  checksum         ##

The cipher to use would still have to be pre-arranged, which also
implies the block length (m) and the checksum (q). The recommended
standard algorithms would be AES and SHA1.

The flags word should contain the following fields:

    3 bits    packet type and content format
    5 bits    ??
    8 bits    padding length in octets

Replay protection can be achieved by using a timestamp (in seconds,
maximum deviation 1s unless specially configured for high-delay links,
requiring machines to be snyc'd using NTP) or a sequence number (which
has issues regarding reordered packets or long periods of silence). I
prefer the former but don't exactly know about hard criteria which one
to use.

Instead of using a bit in the IV as key-use flag, it should now (with
today's computing power) be possible to just try the dynamic key, if
this fails to decrypt try the static key. Don't use the static key for
any payload data, use it only for KX/control purposes. This may make
DoS attacks by overloading a bit easier but increase cryptographic
security.

What is out of the question (perhaps unfortunately) with the current
architecture of the software is utilizing real SSL/SSH/similar data
formats, unless they are (a) lightweight enough to be linked into the
kernel, with no need to use a special library, and (b) usable for pure
datagram transfer - duplicated, lost or reordered packets included.

If someone wants to take over development on that, I'll be happy to
participate in discussion a bit and let others do the coding. :-)
Answer if you are interested. We already have a sourceforge repository...

Another question is whether CIPE is still needed at all, since by now
there are usable implementations of IPSEC - the lack of which was
precisely the reason for this development. The added flexibility
gained from the UDP encapsulation (dynamic addresses, SOCKS) may be a
reason however.

kind regards,

Olaf

PS. "Author contacted, no response": yeah, right; a lot of legitimate
mail including that from Peter recently has landed in my spamfilter :-(
(but is recoverable). I'm currently busy with fixing that.


<< | Thread Index | >> ]    [ << | Date Index | >> ]