[noise] Revision 13: rename "S" to "K"

[Trevor Perrin]

On Mon, Oct 19, 2015 at 10:53 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> How normative is the handshake name section? Do you want to mandate precisely:
> Noise_[HANDSHAKE INITIALS]_[CURVE NUMBER]_[CIPHERNAME]_[HASHNAME]
> Or is it more free form? At the moment I'm using something a bit more
> freeform that's exactly 64 bytes, but I could standardize on this if
> you think that would be a good thing: "Noise_IK-v0 WireGuard zx2c4
> Curve25519 ChaCha20 Poly1305 Blake2b". I guess using your scheme, what
> would fit me would be "Noise_IK_25519_ChaChaPoly_BLAKE2b

Right - For communicating about what you're doing, and interop, it's
probably best to follow the standard naming convention.


", which is 33
> characters. Some folks might wind up using
> "Noise_IK_25519_ChaChaPoly_BLAKE2s", in which case, it might be nice
> to permit calling this "NoiseIK_25519_ChaChaPoly_BLAKE2b" so that it's
> nicely tucked away in 32 bytes.

Yeah, spilling over 32 bytes is a little annoying, but we probably
just have to live with this, truncating 1 separator ("NoiseIK") is
uglier and only helps this case, not others..


> Also on the topic of naming -- what would you think of renaming `h` to
> "session hash" and `ck` to "key derivation hash", to emphasize that
> these values are the inputs and outputs of hash functions, not cipher
> functions, which take "key"s.

ck is a secret value, so I think it's appropriate to call it a key,
and the name "chaining key" is consistent with a similar value in
TextSecure / Axolotl.  Also I like the short names, so I'm inclined to
leave them.


> Regarding Curve448 -- who would need to use a curve like this?
> Curve25519 is 126bits, which I thought was considered unfeasible to
> bruteforce, and DJB wrote back in 2006, "Breaking the Curve25519
> function—for example, computing the shared secret from the two public
> keys—is conjectured to be extremely difficult. Every known attack is
> more expensive than performing a brute-force search on a typical
> 128-bit secret-key cipher." I don't know whether or not this claim
> still holds in 2015, though. Do folks have doubts about 25519?

No, but you never know what the future holds for cryptanalysis, so the
"extra-strength" curve might have more security margin against some
future, hypothetical, attack.

Trevor