━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• To: "Klaus Helbig"
• Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt
• From: "David A. Mcgrew"
• Date: Fri, 26 Jul 2002 07:04:03 -0700
• Cc:
• Importance: Normal
• In-reply-to: <>
• Sender: owner-ipsec@xxxxxxxxxxxxxxxxx
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Klaus,
thanks for your comments, more inline:
> -----Original Message-----
> From: Klaus Helbig [mailto:kfh@xxxxxxxxx]
> Sent: Thursday, July 25, 2002 2:46 PM
> To: 'mcgrew@xxxxxxxxx'
> Cc: 'ipsec@xxxxxxxxxxxxxxxxx'
> Subject: re: draft-ietf-ipsec-ciph-aes-ctr-00.txt
>
>
>
> David,
>
> yes, I agree with you, I can not see any reason to use an external IV for
> AES CTR if algorithms easy can be defined for internal building
> of IV's with
> ESP sequence number and SPI. The only cryptographic requirement for the
> sequence of IV's is, that all the counter values, derived from
> all the IV's
> over all the ESP packets, transformed by AES, are different as long as one
> fixed key is used.
that's right. Additionally, some additional strength against attacks which
rely on precomputation of a database to use during the attack stage can be
gained by having the part of the counter be secret.
>
> Or more mathematical:
>
> Assume IV(i) with i=1,2,... is the sequence of IV's being used for the
> sequence of ESP packets ESP(i) with i=1,2,... and M is the maximal number
> of blocks of block size 128 bit allowed in an ESP packet. Assume CV(i,j)
> with j=1,2,...,M is the sequence of counter values for the ESP packet
> ESP(i), derived from IV(i) for i=1,2,.... The requirement then is for each
> fixed key
>
> CV( i, j ) != CV( k, l )
>
> for all ( i, j ) != ( k, l ) with (i,k > 0), (0 < j,l <= M).
>
>
> Might I'm wrong but I think no reason exists to state "that no more than
> 2^64 blocks of block size 128 bits should be encrypted with any fixed key"
> as long as the requirement above is fulfilled.
The limitation is necessary in order to ensure that the keystream generated
by counter mode is indistinguishable from random. This is important because
indistinguishability is the only practical definition of confidentiality.
(Other definitions would require assumptions about the plaintext source
and/or the attacker.)
The best analysis of the security of counter mode, from which this
limitation can be derived, is the paper of Bellare et. al., "A Concrete
Security Treatment of Symmetric Encryption" (online at
http://www.cs.ucsd.edu/users/mihir/papers/sym-enc.html). In this work,
counter mode is described in the XOR and CTR ciphers. The limitation can be
derived by using Theorems 11 and 13, setting parameters so that the
advantage is about one, then solving for the number of known plaintexts.
(Please note that those theorems assume that the encryption function is a
pseudorandom function (PRF), not a pseudorandom permutation (PRP) like AES.
To apply that analysis to a PRP, it's necessary to apply Proposition 8 from
that paper.)
> What means
> birthday attack in
> connection to the counter mode? I guess it means following. When more than
> 2^64 blocks have been encrypted with any fixed key then with higher
> probability exist equal block keys
>
> AES(Key, CV(i,j)) = AES(Key, CV(k,l)) for any (i,j) != (k,l)
>
> to encrypt the different plaintext blocks P(i,j) and P(k,l).
>
> How this property can be used?
> You must build all the xor sums (here + is used) of ciphertext blocks
>
> C(i,j)+C(k,l) = P(i,j)+AES(Key,CV(i,j))+P(k,l)+AES(Key,CV(k,l))
>
> and test all this sums by statistical criteria's whether is
>
> C(i,j)+C(k,l) = P(i,j)+P(k,l)
>
> because of
>
> AES(Key, CV(i,j)) = AES(Key, CV(k,l)) for any (i,j) != (k,l).
>
> When you find such a pair of ciphertext blocks you get
> information about the
> plaintexts P(i,j) and P(k,l).
Yes, it's hard to describe a simple practical attack against counter mode
which applies when the block-limit is not respected. I've thought of one,
but Scott Fluhrer tells me that it seems contrived :-)
>
> I presume this attack is not applicable, in difference to the birthday
> attack by CBC where you can easy recognize identical ciphertext blocks and
> use this for the attack.
That's right. Both counter mode and CBC are distinguishable after about
2^64 blocks. But if that limit is not respected, the attacks against CBC
appear to be far more feasible and damaging than those against counter mode.
David
>
>
> Best regards
>
> Klaus F. Helbig
> VP Engineering
> Zyfer, Inc.
> (714) 780 7134
> [mailto: kfh@xxxxxxxxx]
>
>
>
>
>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• Follow-Ups:
□ RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt
☆ From: Housley, Russ
□ Draft on providing Authentication/Confidentiality to OSPFv3
☆ From: Mukesh Gupta
• References:
□ re: draft-ietf-ipsec-ciph-aes-ctr-00.txt
☆ From: Klaus Helbig
• Prev by Date: re: draft-ietf-ipsec-ciph-aes-ctr-00.txt
• Next by Date: Draft on providing Authentication/Confidentiality to OSPFv3
• Previous by thread: re: draft-ietf-ipsec-ciph-aes-ctr-00.txt
• Next by thread: Draft on providing Authentication/Confidentiality to OSPFv3
• Index(es):
□ Date
□ Thread