Page MenuHome GnuPG

"gpg: key generation failed: Unknown elliptic curve" from "Key-Type: default"
Open, NormalPublic

Description

This is yet another regression reported in Debian: Creating a key using a parameter file with the key type set to "default" results in an error message "gpg: key generation failed: Unknown elliptic curve". This works for gpg22, though.

Full test script can be found at https://sources.debian.org/src/gnupg2/2.2.27-2/debian/tests/simple-tests/ (beware, URL is not stable). It boils down to:

cat > key-batch << EOF
Key-Type: default
Subkey-Type: default
Name-Real: test case
Name-Email: example@example.com
Expire-Date: 0
%no-protection
%commit
EOF

gpg --batch --generate-key key-batch

Tested on current HEAD (a660e1060 aka gnupg-2.3.1-47-ga660e1060).

Changing "Key-Type" to e.g. "RSA" make the operation pass.

Event Timeline

Ha! This would have affected Kleopatra if we followed werners suggestion to use default. But in Kleo I decided that I needed to show my users what the default is so we do not use default in this case.

Setting a curve type (which shouldn't be necessary) like "Curve-Type: ed25519" doesn't help either. While this makes the check in gpg pass, the gpg-agent process re-checks the parameter set and rejects it with the same error message.

Workaround for the test in Debian: Set key type to RSA.

werner triaged this task as Normal priority.May 25 2021, 8:37 AM
werner added a subscriber: werner.

You should anyway use --quick-gen-key.

I recently stumbled upon this as well.

An even simpler reproducer:

cat > template.txt << EOF
Key-Type: default
Name-Email: example@example.com
EOF
gpg --quiet --batch --generate-key template.txt

The value default is documented on https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html

It works on the 2.2 branch (verified on latest one, 2.2.42), but not from 2.3.0 onwards, including the current 2.4.4:

gpg: key generation failed: Unknown elliptic curve

It works in 2.4.4 if you add

Key-Curve: Ed25519
Subkey-Curve: Ed25519

But obviously you end up with a key that can only sign stuff, but not encrypt, as that is Cv25519.

I don't think it's possible to have two different subkeys in the same batch?

Interesting. So the problem is not actually the Key-Type, but that the default key-type requires a Key-Curve parameter which has no value by default