[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WG last call for IPv4 AH and ESP



>I have no new issues about AH and ESP, but I do have some input on
>authentication-only mode.  There's been a lot of discussion about whether
>or not keyed MD5 or SHA are too expensive.  I was discussing the question
>with Jim Reeds, a cryptographic mathematician here.  He suggests that
>an approach of that sort is overkill.  A better idea, in his opinion,
>is to use a comparatively weak but fast encryption algorithm (though
>not an XOR-based stream cipher such as RC4 or OFB-mode DES) in conjunction
>with a fast checksum algorithm.  The authentication value would be the
>checksum of the ciphertext -- but you'd never send the ciphertext, only
>the plaintext.  To deal with potential export issues for the source
>code, modify the cipher so that was a (possibly weak) one-way function.
>For example, a permuation could be replaced by a table look-up that lost
>information.  The result wouldn't be decryptable short of (possibly
>easy) cryptanalysis, and hence would not be readily usable as a cipher.

I agree and made the same comments to Ran Atkinson several months ago
although I have not come up with such an algorithm. I think this idea is a
good one.

I would also add that the tables for the encryption could be calculated at
key exchange time and kept so that the per packet time would be reduced.

This would also be used to create a greater than or equal to 128 bit hash.
Maybe 160 bits or more... Anyway, the inability to get the key -and-
inability to find a collision would be enough.

I would suggest that for signing contracts or key exchanges, keyed MD5
would be required, but, as an option, individual packets could be signed by
something less computationally intensive.

>I should note, by the way, that in my opinion Jim Reeds' hunches on
>cryptography are generally better than my careful analysis...

Lastly, given the short fuse to the AH document, and the time necessary for
public review of such algorithms, I would suggest that we leave the
documents go through as they are now and expect to add other AH algorithms
later.

I for one would like to help design such an algorithm.

>                --Steve Bellovin


Jim

----------------------
James P Hughes <hughes@hughes.network.com>
Key fingerprint =  68 E7 D5 75 3C 88 86 71  D4 34 36 C3 8E DD 48 17