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

[Daniel Kahn Gillmor]

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
--gen-key.

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.

	--dkg



-------------- 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>