Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: ben edmunds <tigger2014g@gmail.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Certain private keys being mangled by wg on FreeBSD
Date: Tue, 8 Jun 2021 15:20:32 +0200	[thread overview]
Message-ID: <CAHmME9qcQBojyk6HaWTG38WLdtA-nh9D80FTYTy3yHCKdkoWOQ@mail.gmail.com> (raw)
In-Reply-To: <e8baa2e1-78e4-1b02-940a-b8058f86a6cc@gmail.com>

On Tue, Jun 8, 2021 at 1:00 PM ben edmunds <tigger2014g@gmail.com> wrote:
> By not showing this to the user to avoid confusion we actually would
> create confusion in this scenario as the kernel module is performing the
> clamping but the user would have no knowledge of this and leads to
> issues being opened that are a non issue. The aim is not to show the
> users anything about clamping unless the key needs to be clamped as it
> was not clamped already.

I think you are making a mistake, and introducing users to the concept
of clamping will just breed confusion.

> I belive it is key to remember that pfSense is not an end user
> application/tool and designed to be used by admins & network engineers

You made that same point on some Github bug report; it's not news to
me, and it still doesn't change my point of view. Introducing
excessive complexity and superfluous technical information results in
problematic decisions, configurations, and decision calculuses, even
for the most powerful of power users. In particular, here, I think
it's only going to sow confusion and bad information to expose users
to contingent details about "valid private keys" and "less valid
private keys" with weird nerdy language like "unclamped". Because the
fact is, any 256-bit bitstring generated from a csprng is a fine
private key.

      reply	other threads:[~2021-06-08 13:20 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
2021-06-07 12:52         ` Jason A. Donenfeld
2021-06-07 19:17           ` ben edmunds
2021-06-08 13:20             ` Jason A. Donenfeld [this message]

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=CAHmME9qcQBojyk6HaWTG38WLdtA-nh9D80FTYTy3yHCKdkoWOQ@mail.gmail.com \
    --to=jason@zx2c4.com \
    --cc=tigger2014g@gmail.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).