On Tue, Jun 8, 2021 at 1:00 PM ben edmunds 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
The issue here for pfSense is that the private key will be viewable just
like it is within native wireguard clients in the peer config options
and needs to be viewable here for admin and debug purposes.
With regards to clamping and hiding this from users its tricky as it
leads to red heroin
On 6/7/21, Christian McDonald wrote:
> 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'd
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
On 6/6/21, Christian McDonald 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
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
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
Hi Jason,
I've got an interesting case here. I've got what appears to be a few
private keys provided by Mullvad that are being mangled by wg(8) on
FreeBSD12.2 (pfSense 2.5.1+).
Private key ```Lm0BA4UyPilHH5qnXCfr6Lw8ynecOPor88tljLy3ALk=``` ...
becomes
