[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
compression, privacy, and authenticity transforms
Ref: Your note of Mon, 15 May 95 09:12:24 (attached)
Russ,
> Hugo, please reread my original message. I did not say anything about
> compression. Aside from that nit pick, I will demonstrate an example of a
I am sorry if I misread your message. The discussion was following Paul
Labert's comments in the direction of taking advantage of compression
together with encryption in order to provide integrity. So I was probably
confused about your comments.
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.
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). Still these weaknesses show that these mechanisms
are not secure enough. (BTW, they are trivially breakable under
stream cipher modes of encryption.)
In some constrained situations one may think of using less secure mechanisms
to gain in performance. I doubt this is critical here.
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.
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.
Hugo