Curve25519

Yutaka Niibe at 2017-09-06T23:39:52Z

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.

Claes Wallin (韋嘉誠), Claes Wallin (韋嘉誠), Claes Wallin (韋嘉誠), Claes Wallin (韋嘉誠) 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