Re: Long message - thoughts on Gutmann response

["Eric M. Hopper" <hopper,AT,omnifarious,DOT,org>]

On Wed, 2003-09-24 at 13:59, R. Steve McKown wrote:
> Concerns with CIPE
> -----------------
> 1. CRC-32 is a valid weakness in CIPE.  Real exposure level?  unknown

These two things can be fixed fairly easily.  Chopping off the last 48
bits of HMAC-SHA-1 would be pretty secure and only add 2 bytes to the
packet length.  HMAC-SHA-1 takes a lot longer to compute, and would
require the exchange of more key material, but I think the extra
security you'd get would be worth it.  Especially since CIPE isn't
typically used for tunnels over networks of a bandwidth greater than 10
megabits/sec.

> 2. Packet padding is a valid weakness in CIPE.  Real exposure level?  
> unknown

My temptation would be to switch to CTR mode and eliminate padding all
together, but that would require a careful redesign of CIPE as CTR mode
has some serious vulnerabilities if not implemented carefully.  In
particular, HMAC would be an absolute requirement.  As a benefit, the
better ways of implementing CTR mode for unordered block systems provide
automatic replay protection.

Knowing the length of the plaintext is annoying, but I don't think it's
a really serious vulnerability.

I agree that the replay vulnerability isn't one for most of CIPE, but it
should be fixed for the key exchange packets.  It makes me very nervous
that an attacker can get away with anything at all (even if it doesn't
seem exploitable) in those packets.

I should've noticed the CRC-32 myself.  I'm going to have to subject the
protocols I use to more careful analysis.  It's good practice.  I'm not
going to stop using CIPE, but I am going to be more careful to use ssh
over CIPE for remote login and things.  The CRC-32 thing is a
vulnerability that should be fixed, even if no current exploits exist.

CIPE should also have some way of detecting an attempt by an attacker to
force the use of an old protocol.

Yes, CIPE doesn't need to be a bank vault.  But, once an exploit is
found for a protocol on the Internet, even the stupidest thief quickly
has the tools needed to exploit it.  The problems this poses forces the
requirement for a higher level of security inr protocols that are widely
used.

Have fun (if at all possible),
--
There's an excellent C/C++/Python/Unix/Linux programmer with a wide
range of other experience and system admin skills who needs work.
Namely, me. http://www.omnifarious.org/~hopper/resume.html
-- Eric Hopper <hopper,AT,omnifarious,DOT,org>

Attachment: signature.asc
Description: This is a digitally signed message part