Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Christian McDonald <rcmcdonald91@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Certain private keys being mangled by wg on FreeBSD
Date: Mon, 7 Jun 2021 07:05:43 -0400	[thread overview]
Message-ID: <CADTMz0Jo+oOhhK60ug=agXyWL3SRA1oOyXJh49bor5-EG2ibqg@mail.gmail.com> (raw)
In-Reply-To: <CAHmME9qK7xwQgcxvj4PquxUxk0jh_cejsrGMtnn70o1FDof2ig@mail.gmail.com>

Ah that makes sense. I spent some quality time playing with the bit
arithmetic and I see what you mean now. Thanks for that snippet and
direction. One byproduct of this exercise was some code that I whipped
up that can at least detect a clamped vs unclamped key. This might
prove useful for informing a user of what is going on and thus
eliminating this class of erroneous bug report entirely. I'm really
not sure hiding the private keys entirely in the UI is the right thing
to do, especially if it seems that key generators should really be
pre-clamping keys (thanks for reaching out to Mullvad btw) and not
dishing out unclamped keys to begin with.


On Sun, Jun 6, 2021 at 12:21 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On 6/6/21, Christian McDonald <rcmcdonald91@gmail.com> wrote:
> > Would it not be better for wg to just fail outright instead of
> > transforming a poorly generated key entered by a user, regardless of
> > where the key came from? Especially if that problematic key passes the
> > regex validation that was provided in another thread in this email
> > list?
>
> No, it would not be better. There is nothing wrong with using those
> keys. They're not "poorly generated" or "problematic" or dangerous in
> the least. This is only a concern with your UI.
>
> The kernel is doing the correct thing -- clamping keys -- and
> displaying an unambiguous identifier to the user: the key that it will
> actually be using.
>
> I suspect the best thing to do for your UI would be to hide private
> (and preshared) keys, and only show public keys, unless explicitly
> exported into a config file. This not only reduces potential confusion
> with this issue, but mitigates another potential footgun down the
> line. It's also what wg(8)'s show command does by default (while
> showconf will export all).



-- 
R. Christian McDonald
M: (616) 856-9291
E: rcmcdonald91@gmail.com

  reply	other threads:[~2021-06-07 11:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-06 14:27 Christian McDonald
2021-06-06 15:09 ` Jason A. Donenfeld
2021-06-06 15:59   ` Christian McDonald
2021-06-06 16:21     ` Jason A. Donenfeld
2021-06-07 11:05       ` Christian McDonald [this message]
2021-06-07 12:52         ` Jason A. Donenfeld
2021-06-07 19:17           ` ben edmunds
2021-06-08 13:20             ` Jason A. Donenfeld

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='CADTMz0Jo+oOhhK60ug=agXyWL3SRA1oOyXJh49bor5-EG2ibqg@mail.gmail.com' \
    --to=rcmcdonald91@gmail.com \
    --cc=Jason@zx2c4.com \
    --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).