Yutaka Niibe

Curve25519

Yutaka Niibe at

Probably, I was the worst implementer of Curve25519 ECDH (see CVE-2017-0379).

Given the situation of libgcrypt structure, I had to use general purpose MPI routines, which was far from "constant-time".
I had known that it killed the important point of Curve25519, which is designed to be "constant-time".

I thought that "Still, it's better than nothing". Perhaps, this kind of attitude would not be good.

Well, along with quick fix of the vulnerability, I also do real improvement: https://dev.gnupg.org/T3358; While this becomes better implementation, it has not yet had field specific representation. The representation is still MPI. (Original implementation of Curve25519 uses limb of 2^51 to avoid carry between limbs.)

And... during this CVE handling, I realized that libgcrypt from Fedora/RedHat doesn't support Curve25519, because of ECC patent fear. It only enabled in the development version recently.

George Standish, Christopher Allan Webber likes this.

clacke@libranet.de ❌, clacke@libranet.de ❌, clacke@libranet.de ❌, clacke@libranet.de ❌ shared this.

I didn't know you worked on libgcrypt... thank you for the work! What an important project!

Christopher Allan Webber at 2017-09-07T00:03:06Z

George Standish, Yutaka Niibe likes this.

The bonus for the library developer is that I can learn its usage; I learn git-crypt and pidgin-openpgp can use Curve25519 encryption (along with gpg+enigmail) by the paper of the attack:
https://eprint.iacr.org/2017/806

Yutaka Niibe at 2017-09-07T02:17:28Z

... in the development version recently.

I wrote this based on this comment:

https://bugzilla.redhat.com/show_bug.cgi?id=1413618#c3

But it seems that Curve25519 is already available in F26, with libgcrypt-1.7. If so, security fix by libgcrypt-1.7.9 should be used.

Yutaka Niibe at 2017-09-07T11:26:42Z