About pre-shared keys

[mimoo]

Heyo!

I find that there are inconsistancies in the handshakeState for psk:

• handshakeState.Initialize() doesn't take a psk as argument
• MixKeyAndHash() that is only relevant to psk is defined
• WriteMessage() and ReadMessage() are not defined for psk tokens (in their own descriptions)

Wouldn't it make more sense to move everything psk into the psk section? Or to add all the psk-relevant stuff (not just MixKeyAndHash) in the handshakeState section?

2. section 9.3:

A party may not send any encrypted data after it processes a "psk" token unless it has previously sent an ephemeral public key (an "e" token), either before or after the "psk" token.

I think this should be rephrased as "right after the psk token"

3. section 7:

The handling of these tokens within WriteMessage() and ReadMessage() has been described previously, except for the "psk" token, which will be described in Section 9.

The link to section 9 doesn't work

[centromere]

Handshake patterns can have more than one PSK instruction. Moreover, you may want to delay choosing a specific PSK until you receive certain information, such as the static public key of the remote peer.

[mimoo]

I've seen that, but I'm not sure I understand the point of having several psk token in one handshake.

Re-reading your comment I can see that you could use the first PSK to obfuscate the connection, and the second PSK to use a per-user PSK. I don't really see the point of that though if you're already using a known public key.

[trevp]

Even with a single PSK, Alex made the point that you might not know the PSK until later in the handhake (Wireguard uses IKpsk2 for this reason), so the PSK can't necessarily be passed in HandshakeState.Initialize().

By putting MixKeyAndHash() earlier we clarify what's expected from the SymmetricState layer, but we don't complicate the earlier text too much with PSK logic and explanations.

I think you mentioned this earlier and so we added the clarifying note to MixKeyAndHash() that "This function is used for handling pre-shared symmetric keys".

There's different ways we could organize this text, but I don't they'd make a big difference or obviously improve things.

[mimoo]

Care to explain what IKpsk2 brings to IK which is already authenticating both sides?

I think I can see the following scenario which tl;dr is that the I is authenticated via the psk and not via a signature:

• user has a password and a VPN client that knows the server's public key (K)
• the user generates a long-term static public key and sends it in an IKpsk2
• the psk is derived from the password (using something like Argon2)
• if the psk works, the long-term static key of the user is saved and further handshakes will not need the psk

I think you mentioned this earlier and so we added the clarifying note to MixKeyAndHash() that "This function is used for handling pre-shared symmetric keys".

I found these in my notes a while after taking them, and forgot if I had sent something about it or not already :)

[trevp]

Take a look at WireGuard, which uses IKpsk2. For example section 5.2 here:

https://www.wireguard.com/papers/wireguard.pdf

[mimoo]

OK so:

• psk is used to provide post-quantum resistance before post-quantum computers are around
• I is still used in case psk is compromised.

so defense-in-depth. I can see why you want to keep that a possibility in Noise.

Any usecase for several psks? I was wondering about it when I saw that the cacophony test vectors always had an array of psks but never filled with more than one psk.

PS: there are also the two other issues I mentionned in the first post here.