[NBLUG/talk] My response to both the analysis of CIPE by Gutmann, Slashdot and the response by the CIPE list

[Jake Appelbaum]

Please allow me to introduce myself.

I am neither a CIPE developer nor a cryptanalysis expert.

I am however a security consultant who deals primarily in Free/Open
Source Software. I have used CIPE in the past as well as other
Free/Open/Non-Free products for use in a VPN solutions.

I wanted to contribute an outsiders perspective.

I first read Peter Gutmanns analysis [1] as linked from Slashdot [2] and
later I found the archive for cipe-l [3].

After reading Gutmann's short but to the point email a few points that
he made seemed obvious. Some of the flaws were not so obvious. CIPE
seemed to have some very simple flaws and some of the fixes were easy to
implement.

I found a some of it delivered in such a manner that would upset people
who were highly vested in the projects he was criticizing. Perhaps it was
the comment that I also found to be so amusing, something to do with
sound waves. Amusing as it may be, it's still quite harsh.

I then read through the posts on Slashdot that declared CIPE to be
dead. I found these to be really immature and silly considering the
nature of F/OSS.

The need for some change is now, not the time for it's funeral.
Thanks to the F/OSS method of development this is all very possible.

The only series of comments on Slashdot worth reading (IMHO) were by Dan
Kaminsky [4].

I also went ahead and read the CIPE FAQ [5].

A few statements seemed a little hard to believe after Gutmanns pointing
out of using CRC-32 (as opposed to say SHA1).

These really stuck out:

"To date one case of a potentially exploitable bug has been found,
luckily in a version which never was widely used. Another bug has been
found which could lead to denial of service attacks. Both have been
fixed."

[...]

"As for CIPE vs. IPSEC, they should be equivalent security-wise, with
CIPE giving a bit better performance because of the lightweight
protocol."

Peter Gutmann had stated that some of his findings were actually found
years prior, thus the first statement seems to be false.

The second statement is just a bald faced lie, unless it was written by
someone from a decade ago. The CIPE protocol description [6] says
outright that CIPE uses CRC-32 for *integrity protection*.

An important statement to take into account from the protocol
description:

"The primary goal of this software is to provide a facility for secure
(against eavesdropping, including traffic analysis, and faked message
injection) subnetwork interconnection across an insecure packet
network such as the Internet."

With that said and with the analysis by Gutmann, let's get onto the list.

The list I assumed would be delighted to have a professional
cryptographer take a look at their tool of choice. I think the going
rate for an actual security audit by a trained professional is somewhere
around $60,000 (USD). This is a security related tool and as such needs
this type of attention. Tools that would not like this type of audit
might as well be snake oil. 

However deep this audit went, it does point out a number of problems.
Actual problems that need to be addressed for the users of CIPE and
fixes that need to be coded by the developers.
Some of them are very valid at the time of writing, some of them are not
practical without using a stateless encryption system (as Dan Kaminsky
explains in his Slashdot posts).

There are (as of this writing time) three major threads on the subject
of Gutmanns email.

The major first thread has responses ranging from defending CIPE and
understanding the authors stated claims [7]. The author of this post
creates a nice numbered list to respond to. He misunderstands the
statement about CIPE being "Linux's answer to MS-PPTP." He also goes on
to start questioning Gutmann about things including message insertion.

It also extends to a personal attack about Gutmanns ego. The message is
then summed up as: "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."

These statements are preposterous. With an arbitrary comparison to
"many commercial products," whatever metric that is. That it's "hard"
for "someone" to break, but that it's still very much possible. Being
alright with this is quite amazing. This is a security project.
Difficulty is very relative and for Johnny hacker, it might be hard.
However an example of making it hard to decrypt by using compression is
a great example of misunderstanding. A UDP packet with a static key that
has a compressed payload can be replayed over and over and over again. No
key required. The compression isn't going to be a secret either right?
So it's still going to be possible to do plain text attacks of the same
magnitude regardless of the way the data is before cyphers are applied.

The follow ups to this are much like a rally behind a weak player [8]
with a few exceptions [9].

Others want to wait for Olaf (the primary author of CIPE) to speak on
this issue before making any major conclusions [10]. Some people are
thanking for tool that has some major flaws as pointed out by a well
respected cryptographer [11] and some think it could be pro money making
FUD [12].

The fact that Olaf hasn't replied is a huge problem for my assurances
that this project is on track to fix these problems, I know that I am
not alone [13]. What is more shocking to me is the lack of understanding
about a protocol/security method being broken. It seems that many people
doing small tests of their own [14] find it to be acceptable because it
will fit their clients needs. Their own greed and the ease of setup
being the bottom line. 

Other people seem just fine with CIPE being "less than a bank vault" and
I find this just amazing [15]. This is a project that claims the highest
in industry stands. These are people giving away secure systems. That
type of response is insane. One poster even seemed happy with these
statements against CIPE and bragged of it's use in "every sector you can
imagine" [16].

Perhaps the most together response has been by someone running a small
company who had customers upset by Gutmanns statements [17]. This person
acknowledges many of the concerns but down plays some of the more
important ones. Statements that Gutmann is playing up the CRC-32
problems (in relation to SSHv1) making it sensationalist are invalid. This
is very much a valid concern. However he does a great run down of the
concerns and is very much an important statement.

Gutmann himself writes "A Coda to "Linux's answer to MS-PPTP" [18]."
This is a well thought out response to the letters he has no doubt been flooded by.

This product has been adopted by people around the world who may or may
not depend on it as much as the next person. This however says to me
that it's very important to have a response by Olaf, fixes implemented
and even though Gutmann was rude, he should be thanked. If these fixes
are implemented, people who depend on CIPE will have something that is
not broken. It is clearly broken and it needs to be addressed, users
need to be alerted. A proof of concept should not be needed in this
case. I imagine however that it won't be very long before someone writes
a proof of concept ettercap plug-in to mess with CIPE if this isn't
fixed.

People depend on software like CIPE and it can cost them dearly if
situations like this aren't fixed. It's not always about business
either, sometimes lives are at stake. Those people might not stand up
and demand something be done, but someone should.

Let us make sure that this gets fix. Let us also make sure that this
situation is handled well and discussed openly. If it's ignored, we can
know that the relation of CIPE to snake oil is inversely proportional to
the amount of work spent fixing it by it's project leads.

[1] http://www.mit.edu:8008/bloom-picayune/crypto/14238
[3] http://slashdot.org/article.pl?sid=03/09/22/2127236
[3] http://sites.inka.de/bigred/archive/cipe-l/2003-09/threads.html
[4]
http://slashdot.org/comments.pl?sid=79554&cid=7029635&pid=7029635&startat=&threshold=1&mode=nested&commentsort=0&op=Change
[5] http://sites.inka.de/sites/bigred/devel/cipe-faq.html
[6] http://sites.inka.de/sites/bigred/devel/CIPE-Protocol.txt
[7] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00200.html
[8] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00211.html
[9] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00193.html
[10] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00194.html
[11] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00197.html
[12] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00227.html
[13] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00228.html
[14] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00192.html
[15] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00203.html
[16] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00209.html
[17] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00225.html
[18] http://www.mit.edu:8008/bloom-picayune/crypto/14258
-- 
Jake Appelbaum <jacob at appelbaum.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: This is a digitally signed message part
Url : http://nblug.org/pipermail/talk/attachments/20030924/2431c355/attachment.pgp