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

To: "Allan Latham" <alatham,AT,flexsys-group,DOT,com>
Subject: Re: Simple steps to improve CIPE security
From: "Hans Steegers" <hsx,AT,dds,DOT,nl>
Date: Wed, 1 Oct 2003 09:13:52 +0200
Cc: "CIPE-list" <cipe-l,AT,inka,DOT,de>
Reply-to: "Hans Steegers" <steegers,AT,steegers,DOT,nl>

Hi Allan,

>1. Choice of checksum (via options). There is an open source version of MD5
>which is old enough to be accepted. Some may complain about MD5, or about
not
>having a signed checksum. In the light of the possible attack we are trying
>to defend against MD5 is prefectly adequate, requires low computational
>effort and no extra key material.
MD5 is the obvious choice and twice as fast as SHA-1.
Provide the choice between 64 and 128 bits. 64 bits is sufficient for normal
use.
The code is available in the new kernel and will be maintained well.
Implementation in CIPE is not very difficult.

hash127 is (claimed to be) twice as fast as MD5 and a possible candidate for
the future? It would be nice to have it available in the kernel, so CIPE can
use it.

>2. Disable static key for data exchange (via options).
Probably not difficult to implement.

>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.
Looks like more difficult to implement. Trial and error decryption is
costly.
I have to investigate, but at the moment I haven't got the time for it.

>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.
>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.
Postpone it, if the consequences are not clear. It is not trivial to
implement.

I think 1+2 are sufficient. I would also like to include an option to
shorten the life time of the dynamic key.

Best regards

Hans Steegers


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