Re: [TLS] Comments on nonce construction and cipher text size restriction.

No, a smaller computation (say 2^{64}) and then collecting 2^{40}
connections all of which encipher the same plaintext (e.g., "GET /...")

-Ekr

On Tue, May 24, 2016 at 1:13 PM, Quynh Dang <quynh97@gmail.com> wrote:

> Are you worried about 2^96 precomputation and the risk of 1/2^32 of
> cracking your key?
>
> Quynh.
> On May 24, 2016 3:05 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:
>
>>
>>
>> On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed) <quynh.dang@nist.gov>
>> wrote:
>>
>>>
>>>
>>> On 5/24/16, 2:42 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>>>
>>> >On 24 May 2016 at 10:46, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
>>> >>>We discussed this at quite some length.  I originally took your
>>> >>>position, but the IVs add an extra layer of safety at very little
>>> >>>cost.
>>> >>
>>> >> I don¹t see any extra layer here.
>>> >
>>> >
>>> >The argument here is that there are only 2^128 keys and some protocols
>>> >have predictable plaintext.  A predictable nonce would allow an
>>> >attacker to do some pre-calculation with a large number of keys to get
>>> >a chance of a collision (and a break).  It's a long bow, but not
>>> >entirely implausible.
>>>
>>> Ciphers use nonces are designed/proved to be secure when nonces are
>>> predictable: nonces are not random values.
>>>
>>
>> I think you may be misunderstanding. There is a time/space tradeoff here
>> when the
>> nonces are predictable that does not exist when they are random. This is
>> not a
>> vulnerability in the cipher and applies even if the keystream generator
>> at the core
>> of the cipher is PRF_k(nonce).
>>
>> -Ekr
>>
>>
>>> >
>>>
>>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>