curve25519 and encryption capabilities

[Werner Koch]

On Fri, 19 Sep 2014 20:49, dkg at fifthhorseman.net said:

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

That is our usual strategy for introducing new algorithms.  First we
want to have the new version, with the support for new algorithms,
running on many machines ("read-only mode").  Then, with a future
version, we enable the new algorithm in "write-mode", i.e. for general
use without --expert.  In a last step we may make it the default.

If we don't do that, people start to generate new keys and would be
surprised that most people can't encrypt for them or verify their
signature.

Given the importance of moving to ECC and use modern curves created by
trustworthy people, I am all in favor of shorten the above process.

>    (9) ECC
>   (10) ECC (sign only)
>   (11) ECC (set your own capabilities)
>
> If i choose (9) i only get NIST and brainpool curves.

Right, 9 creates a primary and a subkey.  We can't offer Curve25519
becuase we have currently no implementation for encryption.  Thus
Curve255519 does not show up.

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

10 creates a signing key (cf. "sign only").  You may later add an
encrytion key (probably RSA because there is no Curve25519 encryption
key yet).

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

See explanation at top.

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

Right, but if won't work.  I need to add code to disable it.  I have not
yet done that in the hope that we could add Curve25519 encryption
support soon.

> 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

Correct.  It is a litte bit more complicated right now.  I decided to
use the term Curve25519 for both, the signing and the encryption
algorithm.  However, in practise we are using a variant of Curve25519
for signinig, a curve named Ed25519 (Twisted Edwards form of the
Cruve25519 which is defined as Montgomery curve).  The algorthm used
with Ed25519 is also quite different and thus used the new algorithm id
22; while for encryption we will use ECDH (18) as defined in rfc-6637
(although we will probably extend it with by using point compression).

> offer.  Or should we be able to encrypt to Curve25519 keys?

We will have Ed25519 using EdDSA for signing.
We will have Curve25519 using ECDH for encryption.
They are not exchangeable similar to DSA and Elgamal.

> ID 22, and the generated ECDSA (NIST and brainpool both) are asym algo
> 18, as expected.

ECDH (encryption) is 18
ECDSA (signing) should be 19
The keys are technically exchangeable.



Salam-Shalom,

   Werner


ps.
Thanks for testing it and giving me the opportunity to explain this new
stuff.  We should extend the FAQ soon after a release.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.