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: ECDHE: ------ 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 http://cr.yp.to/ecdh.html > */ > 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)? ECDSA: ------ 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 (libraries). Changing the code to really use Curve25519 would ease the pain significantly. But if someone asks me, I would replace ECDSA with EdDSA completely... _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
