RE: A hole in esp-stream-01

[Andrew Robison <arobison@timestep.com>]

>From: 	Germano Caronni[SMTP:caronni@tik.ee.ethz.ch]
>Sent: 	October 24, 1996 1:31 PM
>Subject: 	Re: A hole in esp-stream-01
>
>I agree. This problem is valid if the decrypting entity does not check for
>integrity. (I assumed this check would take place.)
>We are back to square one: Add a *fast* MAC to stream ciphers.
>
How about the following:

start with the values of:
	C1(0)=0x674502301
	C2(0)=0xefcdab89

which are the first two start values for MD5. They could of course be
random number if you wanted this to be keyed.

	C1(N+1)=C(N)+B(N)

which is easily predictable as if you know the plaintext bit you want to
change, all you need to do is flip all of the appropriate bits based
upon what it does to the count. Not good enough, so:

	C2(N+1)=ROTL(C2(N)+C1(N+1),C2(N)>>5)

which is much harder to predict unless you know all of the plaintext.
Finally, the checksum H is produced:

	H=ROTL(C2(N),C2(N)>>5)^ROTL(C2(N),C2(N)>>23)

Cost is about 6 operations/byte which means that a P90 should be able to
churn through over 15MB/sec.

Rather than XOR the checksum with the last four bytes of the packet as
was suggested, which allows for changing these four bytes' values, add
four more bytes to the packet as is done with ESP DES-MD5.

Which raises the question:

When using ESP with DES or 3DES, why do I need a cryptographically
strong hash function since the hash is encrypted? In order to be able to
successfully modify the packet and still create a valid hash would
require breaking the encryption. We are not actually talking about a
non-repudiation issue with a digital signature; a cryptographically
secure hash appears to be overkill and using a keyed hash even more so.

---

• Prev by Date: HMAC rfc draft (long)
• Next by Date: Clarification on 3DES transforms
• Prev by thread: Re: A hole in esp-stream-01
• Next by thread: Re: A hole in esp-stream-01
• Index(es):
  • Main
  • Thread