[pacman-dev] [PATCH] pacman-key: change signing key to ed25519
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(-) 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 -- 2.29.2
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
-- Eli Schwartz Bug Wrangler and Trusted User
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
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. -- Eli Schwartz Bug Wrangler and Trusted User
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
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
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
participants (4)
-
Allan McRae
-
Eli Schwartz
-
Geert Hendrickx
-
Jonas Witschel