1. I am considering alternatives to MD5.
2. Almost all packets are encrypted with the dynamic key. Those that fail CRC
are subject to an extra decryption with the static key. In normal
circumstances this is no great problem. The risk is that it increases the
effectiveness of a DOS attack. (Sending garbage to CIPE would make it consume
twice as much CPU).
I did not make it clear. The intention is to use the static key only for KX
and the dynamic key only for data. This means that if an attacker breaks a
dynamic key he cannot then use this to decrypt the KX and get the next
dynamic key. Avoiding using the static key for data minimises its use and
avoids a DOS attack which forces its use. This implies that the effectiveness
of that DOS attack is increased as it would result in no data being
On Wednesday 01 October 2003 09:13, Hans Steegers wrote:
> 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
> >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
> >an extra decrytion step is the dynamic key decrypt fails.
> Looks like more difficult to implement. Trial and error decryption is
> 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
> >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
> >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
> >postpone it.
> Postpone it, if the consequences are not clear. It is not trivial to
> 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