[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] EcDSA signature scheme

From: Bernd Fix
Subject: [GNUnet-developers] EcDSA signature scheme
Date: Thu, 12 Jul 2018 22:33:44 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

The ECC crypto schemes (in ./src/util) have three different "mechanisms"
(two for signatures and one for ECDHE key exchange): EdDSA, ECDSA and ECDHE.

I am fine with EdDSA (except for minor irritations), but would like to
comment on the other two:

Good, but it is used with curve Ed25519. The problem is that ECDHE
requires scalar multiplication of a point on the curve (that is not the
base point!) - and that functionality is not available in many Ed25519
implementations - they often only provide sign/verify operations.

A more natural choice for me would be ECDHE with Curve25519.
Interestingly in ./src/include/gnunet_crypto_lib.h (line 248) I read:

> /**
>  * Public ECC key (always for Curve25519) encoded in a format suitable
>  * for network transmission and encryption (ECDH),
>  * See
>  */
> struct GNUNET_CRYPTO_EcdhePublicKey

So it looks like that was the initial intention here too: Using ECDHE
with Curve25519. Unfortunately this is not what is implemented (see
./src/util/crypto_ecc.c (line 563):

>  if (0 != (rc = gcry_sexp_build (&s_keyparam, NULL,
>                                  "(genkey(ecc(curve \"" CURVE "\")"
>                                  "(flags eddsa no-keytest)))")))

Does libgcrypt support Curve25519? If it does, a change here would be
rather straight-forward. As only ephemeral keys are involved, no side
effects on persistent information is to be expected.

One last question: Is it correct that an ephemeral key for ECDHE has a
lifetime of ~12h? Will all sessions between two peers use the same
shared secret for the time the two 12h periods overlap (between 6h and 12h)?

I also have some problems with this one - and it is used everywhere in
GNUnet for (user) identities (although not by the crypto used for secure
message exchange in sessions).

AFAIK is the choice of curve for ECDSA limited (NIST curves basically).
I think that is one of the reason we have EdDSA in the first place. But
maybe I am wrong here...

In ./src/include/gnunet_crypto_lib.h (line 248) I read:

> /**
>  * Public ECC key (always for Curve25519) encoded in a format suitable
>  * for network transmission and ECDSA signatures.
>  */
> struct GNUNET_CRYPTO_EcdsaPublicKey

Maybe this is just a copy&paste effect, but it seems that the original
intention was to use Curve25519 - as for ECDHE. Because ECDSA would
require not only scalar multiplication of a curve point but also point
addition, implementors will run into the same problems as with ECDHE

Changing the code to really use Curve25519 would ease the pain
significantly. But if someone asks me, I would replace ECDSA with EdDSA

reply via email to

[Prev in Thread] Current Thread [Next in Thread]