Re: [TLS] Safe ECC usage

[Adam Langley <[e-mail]>]

On Sun, Sep 29, 2013 at 3:33 AM, Kyle Hamilton <[e-mail]> wrote:
> Or perhaps apply your (admittedly much better than mine) intellect to figure
> out how to create a single public key from a single private key which can be
> used for both signing and key derivation, thus permitting consolidation of
> both into a single X.509 Certificate structure?  The lack of this is in fact
> a major impediment to using self-signed certificates as containers for
> curve25519 public keys.

Current ECDSA deployments involve an ECDSA key in an X.509 certificate
and ephemeral, ECDHE keys being generated by the server as needed.
These ephemeral keys are signed by the ECDSA key.

A similar design would have an Ed25519 key in the X.509 certificate
and curve25519 used for ECDHE. I don't believe there's anything needed
to get that working save for switching out the algorithms.

(It is the case that some ECDSA certificates have both the signature
and key derivation bits set in the key usage. This means that OpenSSL,
at least, will allow it to be used for both ECDSA and fixed-ECDH. I'm
not aware of anyone who actually wants that however. As far as I've
seen, it's just the result of copying an RSA certificate template and
forgetting to update the KeyUsage.)

> Granted, I've been severely out of touch for quite a while, and it's
> possible that (e.g.) Ed25519 permits the use of the same public key in this
> manner (even though Ed25519 has a peculiar recordkeeping requirement which
> makes it less than ideal).

Ed25519 and curve25519 are the same curve so it is technically
possible to use an Ed25519 public key, with a bit of thought, as a
curve25519 key. However, I wouldn't recommend it. TLS certainly
doesn't need that.

> (Also, while I've hopefully got your attention, have you any plan to create
> an x64 ABI for Curve25519?  I'm currently having to use it via a COM wrapper
> I hacked up in C#, 64-bit processes calling via COM to a 32-bit process
> which exports only one function that COM doesn't mandate: curve25519(). This
> is insecure to COM-debug capable processes at the very least, as it requires
> that the caller provide the caller's private key over a public data bus.)

There are several implementations of curve25519 in SUPERCOP, including
amd64, asm versions (amd64-51); 64-bit, C code (donna_c64) and
portable C code (ref10). It would be pretty simple to convert the
ref10 code to C# if you wished.


Cheers

AGL