Curve25519 vs. Ristretto255. Have you seen schnorrkel?

[WildCryptoFox]

Are you tied to curve25519 for an RFC or could you switch to use the prime-order group based on curve25519, also implemented in curve25519-dalek, Ristretto255?

If yes: you may want to use schnorrkel.

If not, you may still want to take that as a reference. Schnorrkel uses merlin for domain separation and to bind the full transcript to the proof to avoid unintended misuse of proofs; without relying on a secure source of entropy (at runtime; assuming keys were generated with a secure source of entropy). Oh and it supports batching.

[Silur]

I am not tied to the cofactor-8 setting in any way, maybe a future version can have feature flags for different groups. The initial reason to use this library from dalek-crypto is that it has undergone more review than the ristretto one, the usual cryptographer's excuse :D

[WildCryptoFox]

Perhaps more review for vanilla curve25519 than the 4 additional abstractions built on top of it, known as ristretto255. But the prime order group is more suitable for many more protocols without you having to worry about obscure details. For one, curve25519 is malleable. Ristretto255 is not.

[Silur]

"curve25519 is malleable" is an overreacted and misleading statement by the ristretto community. curve25519 implementors played the good old game of "I know how to crypto, let's make this a little faster" and now we are in the cofactor pitfall :) This doesn't mean that you can use a proper non-vulnerable version in the industry out there because every implementor adopted this stupid idea.

• As a package maintainer I said that I support the idea to use feature flags and support ristretto too, and will be done in future versions
• As a cryptologist I say that curve25519 is not malleable, this is just the result of people doing cryptography who should not

[WildCryptoFox]

Feature flags are good, sure. Can you elaborate on how curve25519 is not malleable? I thought the cofactor was part of the spec.

[..] this is just the result of people doing cryptography who should not

Yet, you're using their implementation of Curve25519 :+1:

[Silur]

Yet, you're using their implementation of Curve25519. :+1:

Your accusation is correct, this is why I added ristretto support in https://github.com/Silur/ECVRF/commit/21212645bb8154d8a289695507a69bdc22367ed6 :) Note that this is a breaking API change and you need to additionally select the submodule you want to use from now. Thanks for the contribution!

[WildCryptoFox]

For what it is worth. I'll be using Schnorrkel for my VRF-needs at least because it uses Merlin transcripts and if I find the need: ECQV (implicit certificates), HDKD (derived subkeys), normal Schnorr signatures, and MuSig.

You're welcome. Good luck!