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

To: 'CIPE-list' <cipe-l,AT,inka,DOT,de>
Subject: RE: Simple steps to improve CIPE security
From: Тарасов Андрей Андреевич <admin,AT,perm,DOT,vtb,DOT,ru>
Date: Tue, 30 Sep 2003 19:21:38 +0600

Hi Allan!

> In my opinion the following can be implemented with little 
> change to CIPE.
> 
> The changes involved should be clearly auditable and should 
> carry little risk of introducing bugs.
> 
> 1. Choice of checksum (via options). There is an open source 
> version of MD5 
> 2. Disable static key for data exchange (via options).
> 
> 3. Do not identify static key use in the IV (via options). 
> This will involve 
> an extra decrytion step is the dynamic key decrypt fails.
> 
All sounds ok to me.

> 4. Choice of padding (via options). The following should be allowed:
> 4.0 As now.
> 4.1 Fixed maximum packet size (i.e. mtu)
> 4.2 Fixed minimum packet size (i.e. all packets shorter than 
> this are padded 
> to this length)
> 4.3 In combination with above - modulo 8 or 16 bytes.
> 
I think 4.1 is unusable - it can be used only on fast connections due to
overhead, and there just might not be enough random bytes to feed the
connection.
4.2 looks useful, but in rare occasions - KX has this already, for example.
4.3 - Padding with more bytes - look perfect to me. And padding must occur
(i.e. no zero padding length should be), and maybe minimum padding length
should be more than 1.

> As a side note I have not looked into what effect (4) will 
> have as regards the 
> demands it places on the random number generator used in 
> CIPE. It will 
> certainly require a whole lot more random bytes. On this 
> basis we may want to 
> postpone it.
> 
> Any comments?
> 
See above.

Let me put another suggestion:

I think that most danger arises from using static key, and from replaying
dynamic keys even within small time frame. 
There is another danger: if dynamic key is compromised (randomly weak
maybe), all subsequent chain of communication is compromised. So static key
must be used sometimes to prevent further leakage.

The simple solution might be to force other side to use static key in
configurable period of time, and to remember and disallow of usage of last N
dynamic keys.

Cheers,
  Andy Tarasov.


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