[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compression, privacy, and authenticity transforms
Hugo,
>Author: hugo@watson.ibm.com@INTERNET
>Date: 5/15/95 12:51 PM
>In any case, to the main issue of key-less ICV's, the paper by Jueneman et
>al. that I referenced in my previous note shows weaknesses of these schemes
>in general. These attacks may appear as not the most realistic ones in the
>world but when you get to multi-user scenarios as described by Steve Bellovin
>they may become a real concern.
I agree that they are not very realistic.
>
>A simple illustrative attack on appended key-less checksums (not described
>in that paper) is that I can produce a
>message M of the form M= M1|CS1|M2, where CS1 is the (keyless) checksum
>of M1. When M is transmitted then a CS2 checksum is appended to the whole
>message M and all of it encrypted. However, I can selectively choose to
>cut the message after CS1 and still be authenticated (CS1 needs to fall
>in the boundary of a CBC block). This attack is more useful against off-line
>authenticated information like files, rather that IP packets (which
>solve this attack by having the total length of the authenticated
>information PREpended).
Yes, these threats can be countered by including the length of the data!
>Still these weaknesses show that these mechanisms
>are not secure enough. (BTW, they are trivially breakable under
>stream cipher modes of encryption.)
Yes, key-less checksums under a stream cipher can be manipulated (not secure).
No, one example of an attack does not imply that all use of key-less checksums
is insecure.
>
>In some constrained situations one may think of using less secure mechanisms
>to gain in performance. I doubt this is critical here.
Performance is very important!
>As for key management, the cost of deriving an *additional* key is negligible,
>just an additional application of a pseudorandom function (based on DES,
>MD5, etc). Computation time of cryptographic checksums is more significant
>here since they usually take more time than a non-cryptographic checksum.
Yes, but ...
>In the current combination of DES and key-ed MD5 it is the time of DES
>which largely dominates the performance penalty while the effect of MD5 is
>secondary. Therefore, I see no justification to go to an insecure cehcksum.
This is not correct for "high speed" implementations. When DES is implemented
in hardware the software processing for the integrity processing has the
greatest performance impact.
This is a good reason to have a efficient integrity mechanism
I am not proposing a particular new integrity mechanism at this time, but I do
object to key-less ICV's being thrown out in total as a viable mechanism.
>
>Hugo
Paul
PS - I might be able to read mail again May 26.