[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