curve25519 and encryption capabilities [Re: Why 2.1 is delayed for so long]

Daniel Kahn Gillmor dkg at
Fri Sep 19 20:49:13 CEST 2014

On 09/19/2014 11:15 AM, Werner Koch wrote:
> All modulo bugs in the the EdDSA code or protocol.

I just tried making some EdDSA keys with 2.1 beta 834.

I had to use the --expert option just to get any ECC options at all for

after using --expert, i'm given these options:

Please select what kind of key you want:
 [... non-ECC stripped ...]
   (9) ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)

If i choose (9) i only get NIST and brainpool curves.

If i choose (10) then i get Curve25519 as an option.

The key created this way is not encryption-capable, and it has no
encryption-capable subkey.

If i go back to add a subkey, i can't add an ECC subkey without using
--expert again.

So i do that, and i get these options from "addkey":

  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (12) ECC (encrypt only)

If i choose 12 (ECC (encrypt only)), i get the full slate of ECC
algorithms, including Curve25519.

I chose Curve25519, and it let me enter a passphrase for this new key,
but then failed with:

gpg: agent_genkey failed: Unknown elliptic curve
gpg: Key generation failed: Unknown elliptic curve

So i suspect what's happening here is that Curve25519 is defined for
signatures and certification and authentication only, but not for
encryption, and the menus need to be a bit more constrained in what they
offer.  Or should we be able to encrypt to Curve25519 keys?

fwiw, the generated Curve25519 keys are marked with asymmetric algorithm
ID 22, and the generated ECDSA (NIST and brainpool both) are asym algo
18, as expected.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140919/d6caaac1/attachment.sig>

More information about the Gnupg-devel mailing list