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

To: "Mark Tinberg" <mtinberg,AT,securepipe,DOT,com>
Subject: Re: Discussion of Cipe on /.
From: "Hans Steegers" <hsx,AT,dds,DOT,nl>
Date: Wed, 24 Sep 2003 11:26:50 +0200
Cc: <cipe-l,AT,inka,DOT,de>
Reply-to: "Hans Steegers" <steegers,AT,steegers,DOT,nl>


Some replies:

>> 2. CIPE's protocol description states clearly: "The protocol gives only
>> limited protection against replay attacks." (Section 4 security
>> considerations).
>This is a problem that should be fixed, even though it's possible that the
>encapsulated traffic implements some of its own replay protection (TCP
>sequence numbers for example).
Maybe. My point was that CIPE doesn't claim to be unbreakable.

>> 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.
>32 bit CRC is silly, IANACE but wouldn't SHA1 (or even MD5) be a much
>better check than CRC.  CRC is easy to fake and Gutmann was right to point
>out that this was one of the important weaknesses in SSHv1 that made it
>unsuitable and caused it to be replaced with SSHv2.
CIPE is not SSH (which I had to patch twice in a single week, because of
vulnerabilities) and I am not sure the CRC-checksumming has exactly the same
function. It is used in CIPE to validate the packet after decryption. And
yes it is relative easy to fake. CRC-32 checksumming is easy to replace by a
better alternative. It should become an option, to stay compatible with
previous versions.
** But let us wait until Olaf has got the time to respond to this matter.

>> 5. No protection against message insertion/deletion: I am not sure if
>> is really relevant: TCP packets include sequence/acknowledge numbers and
>> is a connectionless "best effort" protocol and relies on higher levels
>> reliability and flow control. However, a sequence option could easily be
>> implemented, if required, at the expense of 8 more bytes overhead.
>This answer is bogus.  This is a problem.  It should be fixed.  Full stop.
Is it bogus? If so you should explain. Just stating it isn't very helpful.
I am just wondering: CIPE uses UDP for transport so aren't packets lost or
duplicated all the time? Before you can manipulate messages, don't you need
to retrieve the encryption key first? What security provides a
sequence/acknowledge option if the key is known? I am not sure if CIPE's has
to provide this protection.
Stating that you are an idiot, makes me an idiot. The opposite could also be

>Eh, whatever.  Message, not messenger.
Gutmann is not the messenger: he is the author of the message, which is an
essential difference.
What pissed me off was his 'quick look' approach (including the inevitable
errors), the terminology used (such as "penis shaped"), the derogatory way
he talks about the developers, and the suggestive title he used ("Linux's
answer to MS-PPTP").
Be also aware of M$ sponsored FUD campaigns; this could be one of them.

>> * Some of his remarks are valid and some suggestions could improve CIPE's
>> level of security.
>And I hope this comes to fruition.  It would have been nicer to have this
>audited by pro cryptographers in a less confrontational setting though.
So do I and your contributions are welcome if you have any.

>> * If implemented as options, the user can decide the level of security he
>> needs at the expense of (some) speed.
>Unless there's a major speed hit, I wouldn't even make this an option.
CIPE must IMHO be able to run on 386/16 processors and be backwards
compatible. So new features must be optional.

>> * 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
>> security enhancements as options?
>I don't think there was any criticism of the CIPE encryption code, there
>rarely is in these cases, it's all of the other parts of the protocol (key
>exchange, tamper control, MITM protection, etc.) that are in question.
>Switching to in-kernel cypher and compression modules isn't going to make
>a difference here.
Since CIPE is implemented as a kernel module on Linux, it would be silly not
to use the crypto and compression services provided by the 2.4.22+/2.6
kernels. Criticism on the CIPE encryption code has nothing to do with my
CIPE does need a lot of changes to fit in the coming 2.6 kernels, so why not
remove from the module all what is already provided by the kernel and
enhance the protocol at the same time, IF required?
Another reason is: Now the cryptogtaphic algoritme is decided at configure /
compile time. When using the cryptographic facilities provided by the
kernel, you can decide which crypto algoritme to use at load time, and you
will have more to choose from.

>CIPE's relation to commercial products is mostly irrelevant.  Just because
>you can point out something crappier, doesn't mean that CIPE can't be
It was compared with at least 1 closed source commercial product in
Gutmann's posting. And CIPE isn't a crappy product. But as I mentioned
before, it can be improved.
So, if you can contribute, please do so and don't just wait until people
like Olaf does all the work for you.

>Also your comments about data compression are a red herring,
>IMHO, compression does not make the traffic significantly more difficult
>to decrypt, or to inject data into.  For example if I gzip the text "Hello
>World" I'll get the same value every time, making it equivalent to the
>plaintext, from a crypto perspective.
The example is bullshit! I can try to recover an encryption key because I
know the payload are IP packets transporting mostly TCP or UDP packets with
guessable information at fixed locations and (except for the size field) NOT
related to the data in the payload: If I have enough data and the key is not
changed, it can be retrieved.
If an ip-packet is LZO-compressed, the data (to be encrypted) is changed and
becomes RELATED to the (variable) payload and the fixed positions are lost:
only if you can decompress the packet, you can restore the guessability of
that information. For decompression however, the packet needs to be
decrypted first, and for that you need the key, which is more difficult to
retrieve because there is no guessable info at fixed locations anymore. Tell
me how to de-compress encrypted compressed data without decrypting it first?


Hans Steegers

Now O.S. software becomes mature, usable and complete, it's success starts
to attract the profiteers. Be aware!

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