Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Mathias <mathias@hall-andersen.dk>
To: wireguard@lists.zx2c4.com
Subject: Re: potential preshared-key changes
Date: Fri, 28 Apr 2017 11:24:35 +0200	[thread overview]
Message-ID: <24fd775a-38aa-d6fa-476f-95cc734d990d@hall-andersen.dk> (raw)
In-Reply-To: <CAHmME9pXHZXfY+ebGQ2KrYPxZwqW7WxNWsi=iMDjsSQcZD3cJw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

We should definitely change to per peer PSKs.
Following Storömberg's observations, the following points may also be
worth considering:

1. Partial deployment

Per peer PSK allows organization to deploy PSK to a subset of peers and
have a smooth transition should they wish to implement it later.

2. Compromise of endpoints

All it takes is one compromised endpoint and PQ secrecy fails completely.
If an employee ever leaves his laptop unencrypted and unattended, the PQ
secrecy of all the corporations VPN connections could be lost.

Furthermore, if an administrator suspects this may be the case,
he has to deploy new keys to all endpoints in a PQ secure manner (e.g
sending them over HTTPS is meaningless);
he most likely has to physically install the new PSK on every client!

In case of compromise, the peers public key must be updated regardless
and updating the per peer PSK along with it seems a manageable task.

3. Disclosure of data under a warrant

Suppose the organization deploying Wireguard is forced to decrypt the
data to/from a single peer.
Currently this is not possible, because of forward secrecy, however in a
post-quantum setting it would be.
Limiting the disclosure to a single peer is substantially harder with a
globally shared PSK.
*
*Periodically rotating the PSKs and completely avoiding the case above
is much easier if the PSK is per peer.
*
*4. Public VPN*

*If Wireguard is deployed as a public VPN, there is no hope of PQ
security with a global PSK.
In the case of a per peer PSK, this may be achieved by meeting in person
or exchanging the PSK with PQ crypto, e.g
the overhead of McEliece may be acceptable, since the PSK is only
transfered once.

5. Users and secrets*
*
Since the key is shared, you can count on Alice asking Bob for his VPN
configuration,
you can also count on Bob sending said configuration over email.
Again the PQ security for the entire organization is lost.

As the organization grows, the probability of such an event goes to 1.

Regards,
Mathias

[-- Attachment #2: Type: text/html, Size: 2816 bytes --]

  parent reply	other threads:[~2017-04-28  9:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-22 22:22 Jason A. Donenfeld
2017-04-23  7:05 ` crasm
2017-04-23 11:13   ` Fredrik Strömberg
2017-04-23 19:05     ` crasm
2017-04-23 10:49 ` Fredrik Strömberg
2017-04-28  9:24 ` Mathias [this message]
2017-04-28 10:15   ` Kalin KOZHUHAROV

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24fd775a-38aa-d6fa-476f-95cc734d990d@hall-andersen.dk \
    --to=mathias@hall-andersen.dk \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).