[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention
Security Transform to Proposed Standard
Cc: ipsec@tis.com
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk
>From: "James Hughes" <hughes@nsco.network.com>
>Message-Id: <AEEEC8A9-13374F5@129.191.63.3>
>
>>> > 1. (Optional step) Decrypt the first bock of data using the
>>> > appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san-
>>> > ity check" of the count.
>
...
>
>Since the count is encrypted (and assuming the attacker does not have the
>DES key and therefore can not create known non-duplicate counts), detecting
>someone trying to clog can be performed by decrypting the first block and
>seeing -if- the decrypted count is reasonably valid (since the attacker can
>not control what the data looks like after the decryption step).
>
-This may not always hold:
Note that in DES-CBC the first block of the ciphertext is computed as
C = DES(M + IV)
where + denotes XOR and M is the first block of the message.
(Here M includes the replay prevention counter.)
Therefore, when the IV is specified in the header it is easy
to "spoof" the quick-check that decrypts only the first block and verifies
that the replay counter value is "reasonable":
In order to generate a packet that looks like it has a counter value close
to the current one, keep the ciphertext the same, but slightly modify
the appropriate bits of the IV.
(Ofcourse, when the entire packet is derypted and the HMAC is verified the
spoofing will be revealed...)
Ran Canetti
BTW, if the replay counter were always in the second (or subsequent)
64-bit block then the above attack would be impossible.