Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: WireGuard mailing list <wireguard@lists.zx2c4.com>
Cc: "Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Roman Mamedov" <rm@romanrm.net>,
	"Reid Rankin" <reidrankin@gmail.com>,
	ch@ntrv.dk, "Arti Zirk" <arti.zirk@gmail.com>
Subject: Re: Standardized IPv6 ULA from PublicKey
Date: Mon, 29 Jun 2020 12:01:03 -0600	[thread overview]
Message-ID: <CAHmME9rsiejKsNw9Wq6noNPf46m=2eYu9o4e0EHj_=ek5phZig@mail.gmail.com> (raw)
In-Reply-To: <910f09eb8b67bef5cc55114fe1b0bd6297ea2ec4.camel@gmail.com>

Hi folks,

We're probably not going to do this, for two reasons:

1. The security model of hashing keys down to tiny hash lengths is
dubious, and opens us up to all manner of interesting collision
attacks. Cryptkey routing implies a strong binding between IP and
pubkey. A hash with collisions means a weak binding.

2. There is very little practical utility. In WireGuard, both sides
must _already_ preshare their public keys, and there's no way around
this. So, at the same time that they preshare their public keys, they
can also exchange randomly generated LL or ULA addresses. (Notably,
this is how wg-dynamic works.) In other words, both sides are already
required to know 32 bytes about each other in order to communicate;
tagging on an additional 16 to whatever mechanism exchanges those 32
should not be a problem anywhere.

Trying to shave off 16 bytes of an initial communications setup by
adding complicated hashing schemes and collision issues seems like not
good decision making.

Jason

  reply	other threads:[~2020-06-29 18:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 16:52 Lonnie Abelbeck
2017-12-04 17:14 ` Aaron Jones
2017-12-05  2:53 ` Luis Ressel
2017-12-05  3:31   ` Jason A. Donenfeld
2020-06-24 15:37     ` Florian Klink
2020-06-24 17:08       ` Chriztoffer Hansen
2020-06-24 17:30         ` JuniorJPDJ
2020-06-27 21:43         ` Reid Rankin
2020-06-28 10:15           ` Arti Zirk
2020-06-28 15:19             ` Derrick Lyndon Pallas
2020-06-29 10:22           ` Toke Høiland-Jørgensen
2020-06-29 10:31             ` Roman Mamedov
2020-06-29 10:52               ` Justin Kilpatrick
2020-06-29 11:03               ` Toke Høiland-Jørgensen
2020-06-29 11:38                 ` Roman Mamedov
2020-06-29 12:15                   ` Toke Høiland-Jørgensen
2020-06-29 17:01                     ` Arti Zirk
2020-06-29 18:01                       ` Jason A. Donenfeld [this message]
2020-06-29 19:58                         ` Reid Rankin
2020-06-30  1:24                           ` Jason A. Donenfeld
2020-06-30  8:01                             ` Reid Rankin
2020-06-29 18:49                     ` Luiz Angelo Daros de Luca

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='CAHmME9rsiejKsNw9Wq6noNPf46m=2eYu9o4e0EHj_=ek5phZig@mail.gmail.com' \
    --to=jason@zx2c4.com \
    --cc=arti.zirk@gmail.com \
    --cc=ch@ntrv.dk \
    --cc=reidrankin@gmail.com \
    --cc=rm@romanrm.net \
    --cc=toke@toke.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).