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

To: "CIPE-list" <cipe-l,AT,inka,DOT,de>
Subject: Re: What do you guys think about this?
From: "Hans Steegers" <hsx,AT,dds,DOT,nl>
Date: Tue, 23 Sep 2003 13:40:07 +0200
Reply-to: "Hans Steegers" <steegers,AT,steegers,DOT,nl>

I am not a crypto expert [IANACE], but:

1. CIPE is NOT "Linux's answer to MS-PPTP". CIPE claims to be "a protocol
for ultra lightweight IP encryption". No more, no less.

2. CIPE's protocol description states clearly: "The protocol gives only
limited protection against replay attacks." (Section 4 security
considerations).

3. 32 bit CRC: CRC size could easily be increased at the expense of
additional overhead. Maybe a new option to specify 32, 64, 96 or 128 bits
CRC's to let the user decide: more speed or more security.

4. 3-bit padding length: AES can't be used. So what! This is not a flaw.
Future versions could (and will?) increase the number of padding bits to
allow additional cyphers.

5. No protection against message insertion/deletion: I am not sure if this
is really relevant: TCP packets include sequence/acknowledge numbers and UDP
is a connectionless "best effort" protocol and relies on higher levels for
reliability and flow control. However, a sequence option could easily be
implemented, if required, at the expense of 8 more bytes overhead.

6. Dynamic key exchange:
* The statement "For example it looks like keyex packets will always be 24
bytes long, while tunneled TCP packets will never be that short. " is wrong:
The CIPE protocol description states: "The [key dialogue] packets consist of
a type octet followed by protocol data followed by a random amount of
padding random data, so that the packet is at least 64 octets long."
(section 3: 2nd alinea)
* "Dynamic keys have a limited life-time" (15 minutes; section 3 - last
alinea) .
* "The use of a random IV for each packet means at least that identical
(retransmitted) packets encrypt to different ciphertexts."
* The dynamic key exchange is not that vulnerable, but could (and should?)
be improved in future versions. And it is certainly NOT 'beyond repair'.
* PKCIPE is still experimental and should be used as such.

My personal impression is:

This is mostly Gutmann's VIAGRA for his EGO: He is the expert, and bored at
his friend's home, had a glance at "Linux's answers to MS-PPTP" and
quick-jumps to juicy and belittling conclusions to erect his ego and
possibly to increase his quotation marks as well. I didn't find any
contribution of Gutmann in the CIPE mailing list. The fact that he wasn't
aware of the existence of CIPE and other VPN-like O.S. projects just tells
me what kind of crypto expert he is. The lack of response on the MIT
cryptography list tells me more: he is (so far) completely ignored. He
should have invested more time than "a quick look" to investigate the
protocols and implementations properly before writing these far reaching and
condemning conclusions.

However, having said that:

* Some of his remarks are valid and some suggestions could improve CIPE's
level of security.
* If implemented as options, the user can decide the level of security he
needs at the expense of (some) speed.
* The new 2.6 Linux kernel will provide cypher and compression logic as
kernel modules, so a new version of CIPE is needed to make use of them
(instead of duplicating the logic) and why not also incorporate additional
security enhancements as options?

The bottom line for me is that CIPE is not less secure compared to many
commercial products. The CIPE protocol is not that easy to break as
suggested by Gutmann, but the protocol surely has room for improvements.
If you enable data compression (CipeX) it is even more complicated to break
the protocol: you first need to decrypt to de-compress, and it is extremely
difficult to guess the contents of a compressed ip-packet, which guessed
content is needed to break the encryption.

Just another opinion.

Hans Steegers


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