Certain private keys being mangled by wg on FreeBSD

Christian McDonald rcmcdonald91 at gmail.com
Mon Jun 7 11:05:43 UTC 2021


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 at zx2c4.com> wrote:
>
> On 6/6/21, Christian McDonald <rcmcdonald91 at 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 at gmail.com


More information about the WireGuard mailing list