potential preshared-key changes

["Jason A. Donenfeld" <Jason@zx2c4.com>]

Hi folks,

Trevor and I have been discussing for some time changing the semantics of
preshared keys. I thought about this 18 months ago, but erred on the side
of keeping things as is. After a recent conversation in SF, I'm beginning
to reconsider. I wanted to open this up for discussion, as there are
several pros and cons.

Summary: Currently the handshake mixes in the preshared-key *first*. This
means that the initiator's identity is not revealed until after the
receiver has decrypted using the preshared-key. This in turn means that
preshared-keys must be _per-interface_ instead of _per-peer_. This has
some advantages and some disadvantages. The proposal is to change the
crypto so that the preshared-key is mixed in *last*, so that
preshared-keys become shared _per-peer_.

Pros of per-interface preshared-keys (current method):

  * Simplicity.
  * That's how things work now.
  * The preshared-key protects the identity hiding in a post-quantum
    setting.
  * The preshared-key contributes to the DoS MACs and the cookie
    encryption.

Cons of per-interface preshared-keys (current method):

  * When using WireGuard with multiple peers, the peers must all share the
    same key, which increases the potential for compromise of the
    preshared-key (though the session is of course stil protected with the
    ordinary public key crypto).

Pros of per-peer preshared-keys (proposed method):

  * Compromise of the preshared-key is less likely, since it does not need
    to be shared by all peers.

Cons of per-peer preshared-keys (proposed method):

  * The identity hiding is no longer protected in a post-quantum setting.
  * The DoS MACs and cookie encryption no longer benefit from using the
    preshared-key.
  * It requires changing things.
  * Kevin and I have slightly more Tamarin work to do.

Thoughts? Opinions?

Regards,
Jason