Long message - thoughts on Gutmann response|
"R. Steve McKown" <rsmckown,AT,yahoo,DOT,com>|
Wed, 24 Sep 2003 12:59:44 -0600|
As a fan and user of CIPE, and as owner of a small company that helps
customers use CIPE to secure traffic between physical locations, I'm pretty
concerned over the ramification of Gutmann's response. I've now had two
customers query me about this message. The general response after the first
read seems to be: "this guy is an expert, CIPE has problems, it's better to
be safe than sorry, so maybe we should look for something else".
However, after reading carefully and listening to others on this list, I feel
that are a number of problems with this analysis, and that it leads to
inaccurate conclusions by the reader. I present these thoughts to the list
in hopes that they might be useful in helping craft an "official" CIPE
Please note that I am definitely *not* a crypto expert, and so my comments
present wrong facts or make wrong assessments. If this info is more pain
then help, please hit delete in your e-mail as fast as you can!
Gutmann claims his analysis is "evolving" (his word). Here's the link on his
"A friend of mine recently pointed me at CIPE, a Linux VPN tool that he
claimed was widely used but that no-one else I know seems to have heard of."
Why is this comment so important as to be the first statement and
for his analysis? I am also concerned that he only took a "quick look"
while at a friend's place. Gutmann is apparently a strong crypto guy, so his
quick look probably beats most's comprehensive analysis. But there is other
evidence in his document to suggest his look may have been perhaps too
cursory or performed from a predisposed viewpoint that undermines an unbiased
CIPE uses a compromisable CRC-32 checksum
CIPE is using the checksum to validate proper delivery of an encrypted
i.e. identify packets corrupted during transit. While Gutmann's references
are correct, he muddies the water a bit. Yes, the CRC-32 has a known attack
and its use in CIPE is apparently a weakness. But this weakness alone does
not provide an exploit make. Gutmann then goes on to highlight how such a
weakness played a *part* in an SSHv1 exploit. Comparing a weakness in one
product to an actual exploit in another is circumstantial and sensational.
CIPE uses a too-short padding length
This is a valid weakness. This issue in and of itself does not provide an
exploit, but in conjunction with others it might. Nothing in Gutmann's
analysis shows valid evidence of an imminent threat.
CIPE has no replay protection
CIPE is stateless and doesn't provide replay protection; it relies on upper
layers in the protocol stack to do so. TCP, for example, provides the
necessary mechanics to impart pretty decent (in my opinion) replay
protection. Non-TCP apps almost always implement message reliability in
their internal protocols, which also impart replay protection. By being
stateless, CIPE is less complex and doesn't incur the overhead of replay
protection when it is usually provided elsewhere. It is unclear to me
whether my understanding is wrong, Gutmann didn't understand this decision,
or if he discounted the approach so dramatically it wasn't even worth
Assuming I'm accurate thus far, the glaring error in Gutmann's analysis is
example which infers that one could replay a database transaction through a
CIPE tunnel. Database systems invariably provide message reliability
mechanisms *and* are usually implemented on top of TCP. Gutmann's claim
seems disingenuous, since there appears no way for it to be valid.
CIPE keys can be modified in transit
Gutmann uses the example of 3DES and how a bit-flipping technique used in
conjunction with CRC-32 checksums might be used to alter key values. He then
indicates that IDEA has weak keys like 3DES and infers that it would also be
vulnerable. This inference is not compelling evidence, but perhaps with
Gutmann's knowledge base the inference is clear. But this whole section is
moot, because every implementation of CIPE I've seen uses the far superior
Blowfish algorithm, which he doesn't address at all. The source document
Gutmann uses to analyze CIPE is clear in the use of this algorithm, so I'm
unsure of the rationalization of not addressing it at all.
Because Gutmann does not show the above key attack is effective in CIPE, the
rest of his points in Section 3 are not supported. However, I'm compelled to
point out his analysis of keyex management packets. He implies that the
CRC-32 attack (in conjunction with others) can be used on these packets.
This is true, because applying an attack does not imply success (although a
reader may infer such). By his own analysis, it doesn't appear one will have
the minimum of 16 bytes of known plaintext, as the flag in question appears
to be part of a 4-byte bit field (perhaps encapsulated IP header info?).
Further, he did not address the exposure of the Blowfish cipher to the key
bit-flip attack. Using his data, he hasn't convinced me this attack is
possible. At Gutmann's apparent level of crypto experience, I have to either
conclude that he isn't good at presenting all the facts, I'm missing some
obvious information unsaid in the article, or he misleads the reader in his
analysis of keyex packet vulnerability.
Thoughts - insecure security products
"At least Microsoft eventually tries to fix their stuff, given sufficient
public embarrassment and the odd hundred thousand or so computers being taken
out by attackers."
How is this comparison valid? CIPE has no reported systems or data
compromises. The Microsoft product in question has had several. Gutmann is
comparing the unrealized *possibility* of an exploit with the *reality* of
multiple exploits. Rather than support his message that many open source
developers don't have the skill or interest to maintain the security level of
their products, his comparison does a better job of supporting the converse.
Summary of Analysis
This quote from the analysis summarizes what I feel to be Gutmann's personal
perspective before, during, and after writing this analysis:
"Whenever someone thinks that they can replace SSL/SSH with something much
better that they designed this morning over coffee, their computer speakers
should generate some sort of penis-shaped sound wave and plunge it repeatedly
into their skulls until they achieve enlightenment."
I come to the conclusion that this analysis is more a rant. One by a gifted
and talented individual and one that does make some valid points, but a rant
nonetheless. Effective analyses don't typically rely on circumstantial
evidence, unsupported inference, disingenuous facts, omission of relevant
data, and faulty conclusions. After initial research and review, I find this
analysis to be much thinner on substantive claims that I originally
Benefits of CIPE
Most professional analyses I read tend to state both strengths and
then provide insight into which contextual uses of the analyzed product may
pose problems or issues. Gutmann doesn't do this, so let me try.
1. CIPE is small and therefore easily audited and maintained. CIPE has ~
7.954 lines of code. FreeS/WAN has ~ 96.265 and openssh/openssl combine for
~ 281,431. Complexity and defect count are proportional. Defects often can
be used to subvert security. All else being equal, CIPE will be far more
2. CIPE has had no reported exploits, yet has been around and in use for
years. Compare that to the track record of those products Gutmann feels more
comfortable with, like ssh and ssl.
3. Gutmann used 3DES and IDEA in his analysis, but don't most of us use the
Blowfish cipher? Anyway, it appears that key weakness in IDEA (and
apparently to a lesser extent Blowfish) is exploitable only under very
limited and typically unlikely situations:
4. CIPE uses preshared keys. As long as the key transfer is done over a
secure medium, CIPE avoids all the complexity of PKI (and the inherent
defects in that much code) without incurring a decrease in security. (We
don't use pkcipe).
5. CIPE rekeys regularly. Gutmann doesn't address this, probably because it
seems to be a given feature. But doesn't this limit a "crack" to the
duration a given key is in play?
6. CIPE is not as heavily used as other protocols. This makes it a less
enticing target. While this is not a sound reasoning for selecting a
security technology, it has a valid impact on the exposure and risk
Concerns with CIPE
1. CRC-32 is a valid weakness in CIPE. Real exposure level? unknown
2. Packet padding is a valid weakness in CIPE. Real exposure level? unknown
3. CIPE uses the Blowfish cipher (does anyone still use IDEA?). If Blowfish
is ever compromised, it will take more time to modify CIPE to switch to a
different, presumably more secure cipher.
4. CIPE is not as heavily used as other protocols. This makes it a less
enticing target, but also means it may not be subjected to the same scrutiny
by the white and black hat communities as the other products. This is a
corollary to "security by obscurity", which has been proven invalid in the
The Future of CIPE
I understand CIPE's next major release will use the linux in-kernel cryptoapi
system, which will allow runtime selection between multiple high-end ciphers,
like Blowfish, 3DES, and AES. Perhaps other valid issues Gutmann has raised
will also be addressed?
I like the architecture of CIPE. A simple encrypting tunnel based on sound
security underpinnings is much more valuable to me and those I support than a
feature-laden, complex technology that is more likely to contain errors and
All the best,
Titanium Mirror, Inc.