On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh <quynh.d...@nist.gov> wrote: > I did not talk under indistinguishability framework. My discussion was about > confidentiality protection and authentication.
What is the definition of "confidentiality protection" being used here? > > Quynh. > ________________________________________ > From: Watson Ladd <watsonbl...@gmail.com> > Sent: Wednesday, November 4, 2015 3:17:00 PM > To: Dang, Quynh > Cc: Eric Rescorla; tls@ietf.org > Subject: Re: [TLS] Data limit for GCM under a given key. > > 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. -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
