[noise] Rekey
Rhys Weatherley
rhys.weatherley at gmail.com
Thu Mar 16 00:34:43 PDT 2017
On Thu, Mar 16, 2017 at 8:18 AM, Matthias-Christian Ott <ott at mirix.org>
wrote:
> On 2017-03-15 00:24, Trevor Perrin wrote:
> > C is the sort of trick I've seen people do to protect against short
> > cycles. I've never been super-clear what analysis this is based on,
> > or whether it's just superstition?
>
> It makes little sense to me. Can you explain what you mean by "short
> cycles"?
>
I'm not cryptographer either, but here's my layman's understanding: what if
there is a sequence where:
K1 = F(K0)
K2 = F(K1)
...
Ki = F(Ki-1)
K0 = F(Ki)
That's a cycle where you've returned to the original key. If n is reset to
0 for each rekeying, then this would be fatal to security because the
packet-specific keystreams are reused.
If n keeps incrementing, then even if there is a cycle in the key
generator, the counter nonce will be different when K0 returns and the
keystreams will be different.
The "XOR n" step turns up a lot in key schedule generation for modern block
ciphers: each key schedule round XOR's in the subkey number. There is a
crypto reason for it with some real math behind it. The Threefish/Skein
specification says this:
"Subkey counter. The subkey counter prevents slide attacks [17, 18] and any
other attacks based on identical subkeys. It also provides a defense
against rotational cryptanalysis."
So "slide attacks" and "rotational cryptanalysis" may be a starting point
for further research. In our case, XOR n won't cost anything so we might
as well just do it.
Cheers,
Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170316/f3fab548/attachment.html>
More information about the Noise
mailing list