On 29/11/06, Alex Pankratov <[EMAIL PROTECTED]> wrote:

Using CTR instead of any other chaining mode (excluding ECB) has exactly one
benefit - the counter field can be reused for replay protection. Otherwise
it would require a separate packet sequence number field. But if I remember
correctly from the discussion on a cryptography maillist, CTR chaining
introduces some undesired/unresearched crypto properties and therefore the
consensus was that 4 byte savings over traditional CBC mode were simply not
worth taking a risk of using CTR.

Could you please provide some references? I can understand that this
was on an email list and it might not be trivial to dig up those
emails, but this is the first time I've ever heard that CTR mode has
been described as having undesirable properties.

In CTR mode the encryption algorithm is used to encrypt a random
counter value. The produced output is used as a key stream and XORed
with the plain text. Once the key stream runs out the counter value is
incremented by one and the new counter value is encrypted producing
another block of key stream. And so on.

Assuming that the encryption algorithm is a pseudo-random function
family, the resulting key stream is indistinguishable from random. And
therefore, theoretically, the resulting cipher text produced by XORing
the plain text with the key stream would also be indistinguishable
from random.

Now whether AES or any other block cipher is a PRF is anyone's guess
(so far AES seems to tick most of the boxes), but it is irrelevant
with respect to the security of the CTR mode. With the assumption of a
PRF in place CTR mode should be secure.

Thus far I've always heard comments regarding CTR mode that point out
how simple it is and therefore lends itself to rigorous mathematical
analysis unlike most of the other chaining modes. I'd be very
interested to hear comments to the contrary for once.

--
 ! Lauri
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers

Reply via email to