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 <quyn...@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" <e...@rtfm.com> wrote: > >> >> >> On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed) <quynh.d...@nist.gov> >> wrote: >> >>> >>> >>> On 5/24/16, 2:42 PM, "Martin Thomson" <martin.thom...@gmail.com> wrote: >>> >>> >On 24 May 2016 at 10:46, Dang, Quynh (Fed) <quynh.d...@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 >> >>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
