Re: What do you guys think about this?
"Hans Steegers" <[email protected]>
| Newsgroups | gmane.comp.encryption.cipe |
|---|---|
| Message-ID | <000401c381c7$70550180$d620a8c0@pcw_hans.hnsasd.priv> |
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 -- Message sent by the [email protected] mailing list. Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body Other commands available with "help" in body to the same address. CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>