On 2/2/19 6:25 PM, Gary E. Miller via devel wrote: > On Sat, 02 Feb 2019 16:15:49 -0800 > Hal Murray <[email protected]> wrote: > >> Gary said: >>> Nothing says that a single cookie could not be used by a farm of >>> clients to push the cookies per second into the thousands. >> >>> Then add that this is millions of know plaintext and known >>> ciphertext pairs That is not what the key reuse calculations >>> assume. >> >> I'm missing a step. How are you getting known plaintext/cyphertext >> pairs? > > The whole point is that the client knows the C2S and S2C. Otherwise > he can not key a session to the NTPD server. That is the plaintext. > And he has the cookie, with the algorithm use to make it. That is > the ciphertext.
You are describing a known-plaintext attack on K, which the draft recommends rotating e.g. daily keeping one previous. So your window of time here is, for example, two days. I think everyone agrees that K should be rotated. Hal's comments and the quote from Daniel are about whether it is necessary to require rotation of C2S/S2C, not K. The NTS protocol does not rotate C2S/S2C. Clients can keep their own lifetime to enforce rotation of it (by re-running NTS-KE), but when Hal asked the working group, Daniel said that is not necessary: > The recommendation for AES-SIV is to encrypt no more than 2**48 > messages under the same key. At one message per second that's almost 9 > million years. If you (unwisely) use AES-GCM instead, where the > recommended limit is 2**32 messages, that's still 136 years. The client isn't going to be sending one message per second either. minpoll has a lower limit of 16 seconds. So these numbers can be scaled up by 16. As Hal noted, if the client wants to send out messages at a faster rate, sure, they might weaken the security of their key, but why would they do such a thing? In any event, they can only transmit _new_ cookies at a rate the server will communicate with them anyway. -- Richard
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
