[pacman-dev] pacman-key: change signing key to ed25519

Message ID 20201104205318.GA180556@vera.ghen.be
State Rejected, archived
Headers show
Series [pacman-dev] pacman-key: change signing key to ed25519 | expand

Commit Message

Geert Hendrickx via pacman-dev Nov. 4, 2020, 8:53 p.m. UTC
Larger RSA keys are not the way forward, switch to ed25519 instead.
This will also become the default in the next version of GnuPG.

Signed-off-by: Geert Hendrickx <geert@hendrickx.be>
---
 scripts/pacman-key.sh.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Eli Schwartz Nov. 4, 2020, 9:30 p.m. UTC | #1
On 11/4/20 3:53 PM, Geert Hendrickx via pacman-dev wrote:
> Larger RSA keys are not the way forward, switch to ed25519 instead.

Currently pacman assumes gpgme from >= the year 2010, is that sufficient
to read ed25519? (idk, it's shelling out to gpg and thus likely doesn't
care?) Maybe we should bump this anyway in the expectation that
requiring a ~2015 version of gpgme will naturally lead to gpg versions
that support generating such keys.

> This will also become the default in the next version of GnuPG.

I see such a commit on GnuPG's master branch but not on the stable
branch. When do you expect this to be released...

> Signed-off-by: Geert Hendrickx <geert@hendrickx.be>
> ---
>  scripts/pacman-key.sh.in | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
> index ccfd1b96..fd9d3793 100644
> --- a/scripts/pacman-key.sh.in
> +++ b/scripts/pacman-key.sh.in
> @@ -147,8 +147,8 @@ generate_master_key() {
>  	# Generate the master key, which will be in both pubring and secring
>  	"${GPG_PACMAN[@]}" --gen-key --batch <<EOF
>  %echo Generating pacman keyring master key...
> -Key-Type: RSA
> -Key-Length: 4096
> +Key-Type: EDDSA
> +Key-Curve: ed25519
>  Key-Usage: sign
>  Name-Real: Pacman Keyring Master Key
>  Name-Email: pacman@localhost
>
Geert Hendrickx via pacman-dev Nov. 4, 2020, 10:47 p.m. UTC | #2
On Wed, Nov 04, 2020 at 16:30:19 -0500, Eli Schwartz wrote:
> Currently pacman assumes gpgme from >= the year 2010, is that sufficient
> to read ed25519? (idk, it's shelling out to gpg and thus likely doesn't
> care?) Maybe we should bump this anyway in the expectation that requiring
> a ~2015 version of gpgme will naturally lead to gpg versions that support
> generating such keys.


This change only affects new installations, existing ones will continue
using their rsa2048 (or recently rsa4096) master keys, until they re-run
pacman-key --init.


> > This will also become the default in the next version of GnuPG.
> 
> I see such a commit on GnuPG's master branch but not on the stable
> branch. When do you expect this to be released...


Good question, I don't know.  The point is that the trend is clearly
towards EdDSA rather than larger RSA.  And GnuPG (as well as openssh
etc) need to be conservative, as they must be interoperable with other
or older implementations, pacman doesn't even have that limitation.


	Geert
Jonas Witschel Nov. 4, 2020, 11:23 p.m. UTC | #3
On 2020-11-04 21:53, Geert Hendrickx via pacman-dev wrote:
> Larger RSA keys are not the way forward, switch to ed25519 instead.
> This will also become the default in the next version of GnuPG.
> [...] 
> -Key-Type: RSA
> -Key-Length: 4096
> +Key-Type: EDDSA
> +Key-Curve: ed25519

I will note that the strength of Ed25519 is estimated to be roughly comparable
to RSA 3027 [1], so the currently chosen RSA 4096 is actually a slightly
stronger algorithm. I am not saying that this is an argument against using
Ed25519, which I believe offers ample security for the foreseeable future, but
to be honest, I do not see a pressing need to switch either:

One main benefit of elliptic curves is the much smaller key size, but that is
not important for a locally-generated signing key that by design will never be
shared with anyone else.

On the other hand, Ed25519 is still not formally included in the OpenPGP
specification [2]. (Again, this is not necessarily an argument against its
internal use in pacman, since it only needs to be processable by GnuPG.)

However, given the above facts, personally I would feel more comfortable
holding back this change for now, at least until GnuPG has actually made the
switch to Ed25519 as its default algorithm.

Best,
Jonas

[1] https://ed25519.cr.yp.to/
[2] https://tools.ietf.org/html/rfc4880
Eli Schwartz Nov. 5, 2020, 12:40 a.m. UTC | #4
On 11/4/20 5:47 PM, Geert Hendrickx via pacman-dev wrote:
> On Wed, Nov 04, 2020 at 16:30:19 -0500, Eli Schwartz wrote:
>> Currently pacman assumes gpgme from >= the year 2010, is that sufficient
>> to read ed25519? (idk, it's shelling out to gpg and thus likely doesn't
>> care?) Maybe we should bump this anyway in the expectation that requiring
>> a ~2015 version of gpgme will naturally lead to gpg versions that support
>> generating such keys.
> 
> 
> This change only affects new installations, existing ones will continue
> using their rsa2048 (or recently rsa4096) master keys, until they re-run
> pacman-key --init.

That's really not my point at all. My point is that rerunning --init
does something the project dependencies don't describe as a requirement
to support.

>>> This will also become the default in the next version of GnuPG.
>>
>> I see such a commit on GnuPG's master branch but not on the stable
>> branch. When do you expect this to be released...
> 
> 
> Good question, I don't know.  The point is that the trend is clearly
> towards EdDSA rather than larger RSA.  And GnuPG (as well as openssh
> etc) need to be conservative, as they must be interoperable with other
> or older implementations, pacman doesn't even have that limitation.

Why doesn't pacman have this limitation? Because it is only used in Arch
Linux?

Untrue, there is an active MSYS2 community using it, and we support
running on macOS/BSD and occasionally get people posting compilation
fixes on those platforms. Who knows what version of GnuPG various minor
users might have?

It's not ridiculous to consider *if* we can declare a dependency on the
proposed, updated runtime workflow requirement.

Likewise, I think "GnuPG did not actually change this default and won't
for some time" is a meaningful point of discussion; Jonas pointed out
the key strength actually decreases, while the smaller key size is not
obviously beneficial as it is only used for web of trust signing.

TBH, I'm -1 on any change that is being done without any rationale other
than "because it's the modern way of the future". Changes should be done
because they are better, or safer, or some other practical application.

This may or may not be the case here, I haven't pondered it much yet.
But... it's not being highlighted in the current discussion.
Allan McRae Nov. 5, 2020, 1:03 a.m. UTC | #5
On 5/11/20 9:23 am, Jonas Witschel wrote:
> On 2020-11-04 21:53, Geert Hendrickx via pacman-dev wrote:
>> Larger RSA keys are not the way forward, switch to ed25519 instead.
>> This will also become the default in the next version of GnuPG.
>> [...] 
>> -Key-Type: RSA
>> -Key-Length: 4096
>> +Key-Type: EDDSA
>> +Key-Curve: ed25519
> 
> I will note that the strength of Ed25519 is estimated to be roughly comparable
> to RSA 3027 [1], so the currently chosen RSA 4096 is actually a slightly
> stronger algorithm. I am not saying that this is an argument against using
> Ed25519, which I believe offers ample security for the foreseeable future, but
> to be honest, I do not see a pressing need to switch either:
> 
> One main benefit of elliptic curves is the much smaller key size, but that is
> not important for a locally-generated signing key that by design will never be
> shared with anyone else.
> 
> On the other hand, Ed25519 is still not formally included in the OpenPGP
> specification [2]. (Again, this is not necessarily an argument against its
> internal use in pacman, since it only needs to be processable by GnuPG.)
> 
> However, given the above facts, personally I would feel more comfortable
> holding back this change for now, at least until GnuPG has actually made the
> switch to Ed25519 as its default algorithm.
> 

These are strong arguments to keep the current default.   Particularly
given there is nothing wrong with the current default at the moment, and
you can initialize your pacman keyring "by hand" if you really are
concerned.

Allan
Geert Hendrickx via pacman-dev Nov. 5, 2020, 4:34 p.m. UTC | #6
On Thu, Nov 05, 2020 at 11:03:06 +1000, Allan McRae wrote:
> These are strong arguments to keep the current default.   Particularly
> given there is nothing wrong with the current default at the moment, and
> you can initialize your pacman keyring "by hand" if you really are
> concerned.


How about making it configurable?


	Geert

Patch

diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
index ccfd1b96..fd9d3793 100644
--- a/scripts/pacman-key.sh.in
+++ b/scripts/pacman-key.sh.in
@@ -147,8 +147,8 @@  generate_master_key() {
 	# Generate the master key, which will be in both pubring and secring
 	"${GPG_PACMAN[@]}" --gen-key --batch <<EOF
 %echo Generating pacman keyring master key...
-Key-Type: RSA
-Key-Length: 4096
+Key-Type: EDDSA
+Key-Curve: ed25519
 Key-Usage: sign
 Name-Real: Pacman Keyring Master Key
 Name-Email: pacman@localhost