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: Sun, 6 Jun 2021 11:59:21 -0400	[thread overview]
Message-ID: <CADTMz0KSq7Kj6SzTptTt=Uy5EEGkCRhbZXzZfPeeJ6Vu8134uQ@mail.gmail.com> (raw)
In-Reply-To: <CAHmME9poc+xPG_WfX1vYTSc9JPrSkMpWGR=rTGspOVsKyYfCpA@mail.gmail.com>

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? If not, what would be an appropriate solution to catch
situations like this and in turn alert users? This seems like it could
be a larger discussion on interoperability, especially when dealing
with keys that are being generated by VPN providers.

Granted, this certainly isn’t my area of expertise. Though, the
behavior is just unexpected (and confusing) from an end user
perspective.

On Sun, Jun 6, 2021 at 11:09 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> It looks like whatever is generating those private keys is not
> clamping them. Specifically, all private keys should undergo this
> transformation:
>
>         key[0] &= 248;
>         key[31] = (key[31] & 127) | 64;
>
> In your case, your `Lm` prefix (first byte: 0x2c) is being anded with
> 248, and thus turns into KG (first byte: 0x28).
>
> The kernel properly clamps the keys on input, though, in case
> generators forget to clamp them. So what you're seeing is correct
> behavior.



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

  reply	other threads:[~2021-06-06 15:59 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 [this message]
2021-06-06 16:21     ` Jason A. Donenfeld
2021-06-07 11:05       ` Christian McDonald
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='CADTMz0KSq7Kj6SzTptTt=Uy5EEGkCRhbZXzZfPeeJ6Vu8134uQ@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).