[noise] Revision 32 draft (march 30)

[Trevor Perrin]

Thanks Rhys and Alexey.

I added a security requirement for the DH function:

"For security, the Gap-DH problem based on this function must be
unsolvable by any practical cryptanalytic adversary".

I'd like to add a few more Rationales.  Other than that I hope to
merge this in 1 week or so, if no objections.


On Sat, Apr 1, 2017 at 9:43 PM, Rhys Weatherley >
>
> REKEY() looks good.


Yeah, I'm happy with rekey.  It updates the key but leaves the nonce
unchanged (option B from
https://moderncrypto.org/mail-archive/noise/2017/000944.html ).

Letting the nonce run isn't required, but it's easy; imposes a limit
on how much you can use a chain of keys; and might help if the cipher
turns out to be weak and has short cycles or is subject to a
time-memory tradeoff.

(XOR'ing the nonce - option C - seemed like trying too hard for
unclear benefit, and nonce encoding would be annoying because we have
both big-endian and little-endian ciphers).


>  The only nitpick I have is with "returns a new 32-byte
> cipher key".  I think in the next revision we should consider adding KEYLEN
> and MACLEN constants to the Noise specification.  Right now it is hard-wired
> for 256-bit keys and 128-bit MAC's, but that assumption may not hold
> forever.  Consider:
>
> Noise_XX_448_Threefish512EAX_BLAKE2b
>
> That is, 512-bit Threefish in EAX mode.  KEYLEN = MACLEN = 64 (MACLEN may be
> truncated, but not necessarily only to 16).
>
> Eventually we'll have to think about larger key and MAC sizes.  Then REKEY()
> becomes "returns a new KEYLEN-byte cipher key".

Not sold on that.  256 bits is a pretty great keylength: plenty of
margin against cryptanalysis, and also puts quantum and TMTO attacks
out of reach.  There's not a really good need for bigger values, and
smaller ones aren't as comfortably secure.  (ThreeFish was designed to
be part of a hash function, thus the unusual "key" sizes, I think).

It's not true that we'll eventually need larger values, as 256 bits is
astronomically-sized for a key, and 128 bits is comfortably out of
reach for on-line guessing.

Allowing shorter auth tags is potentially reasonable, but I think the
security analysis for truncating GCM/Poly1305-style MACs is
nontrivial, so that would have to be looked at carefully.

Of course, if someone is determined to replace these constants they
can do that on their own and do their own analysis.

Trevor