curve25519 and encryption capabilities

[Daniel Kahn Gillmor]

Hi Werner--

Thanks for the detailed explanations!
On 09/19/2014 03:54 PM, Werner Koch wrote:
> On Fri, 19 Sep 2014 20:49, dkg at fifthhorseman.net said:
>> 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.

Thanks, this is the explanation i was missing :)

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

fwiw, djb seems to be proposing (on the CFRG mailing list) that the
curve itself should be referred to as Curve25519; the signature
mechanism should be Ed25519; and the DH key exchange should be X25519.

This is pretty confusing, though, since the widespread implementation
called "curve25519" actually implemented what djb now wants to call
X25519. :/

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

Ah, right.  signing-capable keys are indeed ID 19.

> The keys are technically exchangeable.

That's a little weird.  it seems in some sense like we're heading back
to ID 2 and 3 (RSA encrypt-only and RSA sign-only), which i thought the
community had moved away from in favor of generic ID 1 (RSA).  but in
practice, since we want to discourage reuse of keys in different
algorithms, it's probably not a bad thing.

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

sounds good!

	--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/972d617d/attachment.sig>