potential preshared-key changes
Jason A. Donenfeld
Jason at zx2c4.com
Sun Apr 23 00:22:22 CEST 2017
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
More information about the WireGuard
mailing list