triple DH

Werner Koch wk at
Wed May 20 12:41:54 CEST 2015

On Tue, 19 May 2015 13:56, christian at said:

> Why is this? In ecc.c:158, we see that
>  if (E->dialect == ECC_DIALECT_ED25519)
>     point_set (&sk->Q, &Q);
>   else
>     {
>     // ... lots of code
>     }
> the key generation logic diverges here.  The reason is that for NIST
> curves (and other non-Curve25519)

The comment a few lines above explains it:

  /* We want the Q=(x,y) be a "compliant key" in terms of the
   *, which simply
   * means that we choose either Q=(x,y) or -Q=(x,p-y) such that we

Thus this is about generating keys in a way to allow point compression
in a non-patent encumbered way.  Meanwhile the point compression patent
expired and thus this does not make much sense anymore.  I'll ask Andrey
Jivsov on how we can proceed here.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gcrypt-devel mailing list