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

Re: A hole in esp-stream-01



-----BEGIN PGP SIGNED MESSAGE-----

[ To: IPSec mailing list ## Date: 10/24/96 01:06 pm ##
  Subject: Re: A hole in esp-stream-01 ]

>Date: Thu, 24 Oct 1996 03:41:33 +0200 (MET DST)
>From: Germano Caronni <caronni@tik.ee.ethz.ch>
>Subject: Re: A hole in esp-stream-01

>Angelos D. Keromytis wrote:
>> >a) do a CRC over everything but the last 4 bytes, then XOR this CRC to the
>> >   last 4 bytes before encryption. This just hopes that something different
>> >   will do the error detection, including the last four bytes...
>> At least one of the attacks will still hold (toggling the lower order
>> bit of the TCP/UDP port in the header and the checksum).
>
>Right. But only if nobody checks the checksum over the whole packet, which I
>just introduced. And yes, I hate myself for doing it, I would much more
>prefer to have a formal MAC which ist fast enough to calculate such that
>esp-stream would fit into the cum MAC philosophy of IPSEC.

>> >b) Add preceeding plaintext byte and cypertext byte to current byte before
>> >   encryption. C(n)=C(C(n-1)+P(n-1)+P(n)). This should deny changing plain-
>> >   text unless you know the plaintext anyway.
>>
>> But the problem is that the attacker already knows the plaintext of
>> the header...unless i'm missing something ?
>
>Yes, I believe he now needs to know the *whole* plaintext. Otherwise all
>the rest after the header he changed will be garbled. Or do I have a
>gross mistake in my thinking here?

If I'm understanding your description, above, then we have something
like:

Encrypting:

C[i] = K[i] XOR (P[i] + C[i-1] + P[i-1])

Decrypting:

P[i] = (C[i] XOR K[i]) - (C[i-1]+P[i-1]).

This means that anything you do that leaves C[i-1]+P[i-1] unchanged
won't propogate.  For example, suppose that I know the high bit of
P[4] is zero, but that bit of C[4] is a one.  To change this so that
the receiver will get the high bit of P[4] as a one, all I do is
flip that bit in the ciphertext.  Now, when we're decrypting, we get
the following:  (Let T be the vector with only the high bit on.)

P[4]* = (C[4] XOR K[4] XOR T) - (C[3] + P[3]) = P[4] XOR T

P[5]* = (C[5] XOR K[5]) - (C[4]* + P[4]*)

Now, remember, we turned the high bit off in the ciphertext byte,
and on in the plaintext byte.  What this means is that we subtracted
128 from the ciphertext byte, and added it back in the plaintext
byte.  Thus, (C[4]* + P[4]*) = (C[4] + P[4]).

If we have to also deal with the CRC of this, so long as the CRC
polynomial is known, we can just flip the bits that would have
changed in the CRC, right?

>Germano

   --John Kelsey, jmkelsey@delphi.com / kelsey@counterpane.com
 PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMnG7f0Hx57Ag8goBAQG1tAP/QyCnMx33jqdL3ILuVYUozWDL/5+TN8Qe
/ytjaIZwttHySprW05gYP/OlwLJyn6qKJbE78thaBTHCDF7rZ3odvOFOVZ9JuwPN
FEdFtct0YM2KtOC0K92Se6orbqmgIHSRfA5zYXwdkuMpaBqZJ5J8P1OAYmrIsTeL
MoftDRfXYlU=
=6qPt
-----END PGP SIGNATURE-----


Follow-Ups: