MD5 is mature and well researched. Perfect it isn't, but I think we can say
that the likelyhood is that gross errors which would limit its usefulness in
our application do not exist in it.
This is not the case of hash127. Until this has been scrutinized by those
cleverer than me I would prefer to leave it alone.
It will not be possible to use a keyed hash without new key material - using
the static or dynamic key is not safe. That in turn means modifications to
the KX mechanism which I would want to avoid at this stage.
On Tuesday 30 September 2003 15:00, Eric M. Hopper wrote:
> On Tue, 2003-09-30 at 07:27, Allan Latham wrote:
> > Hi all
> > 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 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.
> Not using a keyed hash is a departure from protocol design orthodoxy
> that bothers me. I agree that it seems like it would protect against
> message modification attacks much better than CRC does. I would prefer
> the use of the hash127 thing that someone mentioned. It looks faster
> than MD5 even, and it's keyed. It uses floating point arithmetic
> though, so it would be much slower on 386s.
> Your other suggestions sound good, though I think 4 is slight overkill,
> and that if you do it, using some sort of static padding value instead
> of random numbers is probably fine.
> Have fun (if at all possible),