On Wed, Nov 4, 2015 at 2:29 PM, Dang, Quynh <quynh.d...@nist.gov> wrote: > Hi Eric and all, > > > The limit of 2^48 packets under a given key for GCM you mentioned today is > the limit for SRTP > (https://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-17#section-6). > The nonce space of the IV construction is only 48 bits and that is why it > has the limit of 2^48. The limit here should be 2^48 blocks, not records as > stated in the document. > > > As I explained before, GCM is counter mode for encryption. For a given key, > the nonce never repeats globally, then confidentiality of the encrypted data > is preserved. When the nonce space is 2^n values, then 2^n message blocks > can have secure confidentiality protection.
This is completely untrue. If you actually understood the definitions, and thought about the matter for 15 minutes, you would realize that permutations are distinguishable from functions after 2^(n/2) queries with high probabilities, and this breaks IND-$. This is an elementary result found on page 134 of Boneh-Shoup. > > > Regarding to authentication, as I explained before, if the tag size is n, > then you have collision issue among the tags when the number of tags goes > around 2^(n/2) which is not a good thing, but strictly speaking, this does > not break your authentication. Carter-Wegman security results are weaker than for PRF-based MACs. > > > However, rekeying often is a good thing which could help prevent disaster to > keep go on if there is something wrong with the IV or the key. > > > Quynh. > > > > > ________________________________ > From: Dang, Quynh > Sent: Monday, November 2, 2015 3:00 PM > To: Watson Ladd > Cc: tls@ietf.org; c...@ietf.org; Eric Rescorla > Subject: Re: [Cfrg] Collision issue in ciphertexts. > > > Now, you talked about a MAC function (with AES). I previously talked about > encryption. > > > If I , the only person, uses the MAC key, when I generate more than 2^64 MAC > values (Let's say each MAC value is 96 bits), I have many collided MAC > pairs. But, I am the only one (beside the person(s) verifying my MACs) who > knows the MAC key in order to generate those verified MAC values. > > > If the MAC length is k bits, an attacker is allowed to send 2^n failed > verifications, his or her chance of success is approximately 2^n / 2^k. > Let's imagine n is 64 and k is 96, the success chance is 1/2^36 which is > practically ZERO! > > > If I am an attacker, I would choose a message that I want to be verified, > and I keep changing the MAC key to generate different MAC values with > different keys and hope one of them will get verified. Let's assume the MAC > key to be 96 bits ( 96 bits of random bits, the other 32 bits are known). In > theory, when I get close to 2^96 attempts, I would expect some chance of > success. To deal with this attacker, one would change the MAC key when the > number of failed attempts gets close to a number that you don't want. For > example, if you don't want a success chance of an attack to be above 1 / > 2^36, then you need to change your MAC key when the number of failed > verifications reaches 2^64 when your MAC length is 96 bits. > > > After you change the MAC key, I ( the attacker) will have to start > everything again because all of the failed MACs I generated before are > useless now. > > > ________________________________ > From: Watson Ladd <watsonbl...@gmail.com> > Sent: Monday, November 2, 2015 5:07 AM > To: Dang, Quynh > Cc: tls@ietf.org; c...@ietf.org; Eric Rescorla > Subject: Re: [Cfrg] Collision issue in ciphertexts. > > > > On Nov 2, 2015 2:14 AM, "Dang, Quynh" <quynh.d...@nist.gov> wrote: >> >> Hi Eric, >> >> >> As you asked the question about how many ciphertext blocks should be safe >> under a single key, I think it is safe to have 2^96 blocks under a given key >> if the IV (counter) is 96 bits. > > This is wrong for PRP, right for PRF. It's not that hard to find the right > result. > >> >> >> When there is a collision between two ciphertext blocks when two different >> counter values are used , the chance of the same plaintext was used twice is >> 1^128. Collisions start to happen a lot when the number of ciphertext >> blocks are above 2^64. However, each collision just reveals that the >> corresponding plaintext blocks are probably different ones. > > Which breaks IND-$. Let's not be clever, but stick to ensuring proven > definitions are true. > >> >> >> >> Quynh. >> >> >> _______________________________________________ >> Cfrg mailing list >> c...@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
