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. 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. 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<mailto: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<mailto:c...@irtf.org> > https://www.irtf.org/mailman/listinfo/cfrg >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
