From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 21 16:42:37 2022 Received: (at 55055) by debbugs.gnu.org; 21 Apr 2022 20:42:37 +0000 Received: from localhost ([127.0.0.1]:50985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhddM-0004xw-RW for submit@debbugs.gnu.org; Thu, 21 Apr 2022 16:42:37 -0400 Received: from mail-yw1-f182.google.com ([209.85.128.182]:42100) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhddL-0004xg-9L for 55055@debbugs.gnu.org; Thu, 21 Apr 2022 16:42:36 -0400 Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-2ef5380669cso65046587b3.9 for <55055@debbugs.gnu.org>; Thu, 21 Apr 2022 13:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unnservice-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WZB5pPjayI492GcOdxbP3s2Gdn3oC8w1Xkc7LcL/J18=; b=4GC55rRXG3Y7bYcTtI+sO2aQWOClDY1tj24ZG2decYYiu3P0TbBvBR5pAAvuux1ZLf s5uW75JlXb/R5M79nC14n1fuT72xHalpCSb16WpwmebcoIyUZ7SHkHpAJGtravrvLq0Z FDyuUBc8pE1VzI1GVsnhEmHi0hxdYuPIcMqsjsOLVwO9adHmCIA+H21Krckv2EXbuRHf OlW7A2cQavdDRcqiv4a4eUSOyS5epibok6UtL/cwBD7oEJeiRFgDU71wz0qIFKx7Ep2i WruoK5SFEYLbDw0HhK41UTynkzlJ3qoFTGOnqQhimz2NLUWogQ4IUDA6nhvqex0cCRin BZJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WZB5pPjayI492GcOdxbP3s2Gdn3oC8w1Xkc7LcL/J18=; b=lMAgPQOlcKUGVyRDWxx1o/f/b1TQiwK9H3JbxvtokF6LuUnEIBq1PByoQ5ZZMtroFL Mvt3mNl/l4V6s+3O69ggsPpWzTRUio5RauFEJX4bZU4foM3FTrM+iJAx8vqVOh/jFPSp lMPGQCdHz7biQUwmGygdRsZJf5DAKE8x1VfkP5JiPllTjslx1KuPHu79fWJSJwNK2jrB ichPBYBAprYJBqDope6iDvC3Nm7DwuHpu9CAbFkfu5yLDHYd9EDtYrX+Cvnlk5NG9+Hm WZcChQhAhKIAi0+bU67sPvJuHmuc8M78c9Q3ECSOriuP+ElYB523eABfViovyfw1oprb fK0g== X-Gm-Message-State: AOAM533Owr+J6wkrfHy7h6iigrX5Ou6d1CECiF1i9SATyqOus8rpyUE5 dLQlVmidJ0vU4irkTZAbjK9kwr+bg5ZVNM7eZ9pAzDq4FAX+ X-Google-Smtp-Source: ABdhPJzcCi10WwLb/+u+MK9DMdklUSEJDplsCUax309VOw7SQtgWzhcLVrWSHFcuQleijmHrzCARWIp8NoQo7aBn7FI= X-Received: by 2002:a81:4f14:0:b0:2ec:496b:cb29 with SMTP id d20-20020a814f14000000b002ec496bcb29mr1726633ywb.159.1650573749422; Thu, 21 Apr 2022 13:42:29 -0700 (PDT) MIME-Version: 1.0 References: <274c06a235949ebbdd3f90e31afea1189f207ea0.camel@telenet.be> In-Reply-To: From: Paul Alesius Date: Thu, 21 Apr 2022 22:41:53 +0200 Message-ID: Subject: Fwd: [bug#55055] [PATCH] gnu: wireguard: Add support for PresharedKey To: 55055@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000029f2a05dd30262a" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55055 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000029f2a05dd30262a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Also, #f is not a string, did you mean =E2=80=98;#f|string=E2=80=99? The idea behind #f is that the field is optional, so that if it isn't specified in the configuration then it isn't written to the configuration file at all, hence #f is for a conditional when writing the actual configuration file and has no default value. > * Could the security limitation be documented? > * Does wireguard has some inclusion mechanism, such that the wireguard configuration can =E2=80=98include=E2=80=99 some file outside the store? I'll fix it properly to allow for loading of a key file, WireGuard does not have an inclusion mechanism. How does it work with regards to documentation and i18n versions, do you use online translation for the other languages? I can really only fill in the english version. > * What security impact does a leaked secret key have? Minimal to none, one should worry about the cloud peers over the wire guard pre-shared key. It's just an additional layer of security in case the public key algorithms are broken (for instance with quantum decryption), then the pre-shared key functions as a one-time pad. If none is specified, wireguard will use a default one of an all-zero string. Since countries log all traffic, you never know what they have, hence my patch submission. > * WDYT of verifying that the preshared key looks =E2=80=98reasonable=E2= =80=99 (I guess only a-z0-9 characters, no spaces or newlines, not a bytevector ...) I could develop a subsystem for validating the fields of the wireguard but isn't it better to provide validations from the guix framework more broadly? With my level of Guile scripting right now, I doubt that it would be accepted. With regards, - Paul On Thu, 21 Apr 2022 at 16:26, Maxime Devos wrote: > Paul Alesius schreef op do 21-04-2022 om 15:26 [+0200]: > > + (preshared-key wireguard-peer-preshared-key > > + (default #f)) ;string > > This should be documented in the documentation, otherwise it will be > difficult to discover. Also, #f is not a string, did you mean > =E2=80=98;#f|string=E2=80=99? > > Also, a limitation: the preshared key will end up in the store, and > hence be world-readable. So other users on the same system (other > people or compromised system daemons) could now determine the preshared > key. > > Questions: > > * Could the security limitation be documented? > > * What security impact does a leaked secret key have? > > * Does wireguard has some inclusion mechanism, such that the > wireguard configuration can =E2=80=98include=E2=80=99 some file outsi= de the store? > > * WDYT of verifying that the preshared key looks =E2=80=98reasonable=E2= =80=99 > (I guess only a-z0-9 characters, no spaces or newlines, not a > bytevector ...) > > As-is, if I do (preshared-keys (string->utf8 "oops I thought this > needs to be bytevector)) then "guix system reconfigure" doesn't > give a nice error message, it will just silently produce a broken > configuration file. > > Greetings, > Maxime. > --000000000000029f2a05dd30262a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Also, #f is not a string, did you mean =E2=80=98;#f|= string=E2=80=99?

=
The idea behind #f is that the field is optional, so that if it isn= 9;t specified in the configuration then it isn't written to the configu= ration file at all, hence #f is for a conditional when writing the actual c= onfiguration file and has no default value.

&g= t;=C2=A0 * Could the security limitation be documented?
> * D= oes wireguard has some inclusion mechanism, such that the wireguard configu= ration can =E2=80=98include=E2=80=99 some file outside the store?

I'll fix it properly to allow for loading of a key file= , WireGuard does not have an inclusion mechanism. How does it work with reg= ards to documentation and i18n versions, do you use online translation for = the other languages? I can really only fill in the english version.

>=20 =C2=A0 * What security impact does a leaked secret key have?

=
Minimal to none, one should worry about the cloud peers over the= wire guard pre-shared key. It's just an additional layer of security i= n case the public key algorithms are broken (for instance with quantum decr= yption), then the pre-shared key functions as a one-time pad. If none is sp= ecified, wireguard will use a default one of an all-zero string.
=
Since countries log all traffic, you never know what they ha= ve, hence my patch submission.

> * WDYT of = verifying that the preshared key looks =E2=80=98reasonable=E2=80=99 (I gues= s only a-z0-9 characters, no spaces or newlines, not a bytevector ...)

I could develop a subsystem for validating the fields = of the wireguard but isn't it better to provide validations from the gu= ix framework more broadly? With my level of Guile scripting right now, I do= ubt that it would be accepted.

With regards,
- Paul

On Thu, 21 Apr 2022 at 16:26, Maxime Devos <maximedevos@telene= t.be> wrote:
Paul Alesius schreef op do 21-04-2022 om 15:26 [+0200]:
> +=C2=A0 (preshared-key=C2=A0 =C2=A0 =C2=A0wireguard-peer-preshared-key=
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0(default #f))=C2=A0 =C2=A0;string

This should be documented in the documentation, otherwise it will be
difficult to discover.=C2=A0 Also, #f is not a string, did you mean
=E2=80=98;#f|string=E2=80=99?

Also, a limitation: the preshared key will end up in the store, and
hence be world-readable.=C2=A0 So other users on the same system (other
people or compromised system daemons) could now determine the preshared
key.

Questions:

=C2=A0 * Could the security limitation be documented?

=C2=A0 * What security impact does a leaked secret key have?

=C2=A0 * Does wireguard has some inclusion mechanism, such that the
=C2=A0 =C2=A0 wireguard configuration can =E2=80=98include=E2=80=99 some fi= le outside the store?

=C2=A0 * WDYT of verifying that the preshared key looks =E2=80=98reasonable= =E2=80=99
=C2=A0 =C2=A0 (I guess only a-z0-9 characters, no spaces or newlines, not a=
=C2=A0 =C2=A0 bytevector ...)

=C2=A0 =C2=A0 As-is, if I do (preshared-keys (string->utf8 "oops I = thought this
=C2=A0 =C2=A0 needs to be bytevector)) then "guix system reconfigure&q= uot; doesn't
=C2=A0 =C2=A0 give a nice error message, it will just silently produce a br= oken
=C2=A0 =C2=A0 configuration file.

Greetings,
Maxime.
--000000000000029f2a05dd30262a--