Re: [TLS] Data limit for GCM under a given key.

On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh <quynh.dang@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 <watsonbladd@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.dang@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; cfrg@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 <watsonbladd@gmail.com>
>> Sent: Monday, November 2, 2015 5:07 AM
>> To: Dang, Quynh
>> Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla
>> Subject: Re: [Cfrg] Collision issue in ciphertexts.
>>
>>
>>
>> On Nov 2, 2015 2:14 AM, "Dang, Quynh" <quynh.dang@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
>>> Cfrg@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.