Decaf makes the specification of the protocol more difficult, because it isnât used in any RFCs yet. But Iâd be happy to help out with that. Also, you have to specify a point encoding anyway, and it should probably be either Decaf or the one used in the EdDSA spec (RFC 8032).
Decaf requires slightly more code size than multiplying the cofactor, which could be a problem for deeply embedded devices but isnât a problem for eg phones.
Decaf simplifies your analysis. So if itâs a new protocol, or one analyzed for prime-order curves, itâs probably worth it.
Decaf gives you a pretty decent implementation in C/C++, which hopefully will save you time and effort. Use the one in the curve25519-work branch of ed448-goldilocks on SourceForge; I really need to make that branch master at some point.
At the end of the day, if youâre just doing standard-ish DH key exchange and Schnorr signatures, you might want to just use X448 (RFC 7748) and EdDSA-448 (RFC 8032), since those are already specified. If youâre doing MQV or VRFs or PAKE or something, probably itâs worth it to get rid of the cofactor.
Post by Rosalie Tolentino
I am currently helping with the design of a draft for OTRv4, and we are
considering using Decaf point compression with Ed448 for Schnorr signatures and
a deniable, authenticated key exchange.
I like Decaf because it allows us to omit information about the cofactor in the
protocol and thus in the implementation as well.
We have received feedback that multiplying by the cofactor is trivial in
comparison to incorporating Decaf.
I wanted to ask, when is using Decaf a better choice? And alternatively, when is
using the cofactor preferred?
Fingerprint: 55A0 392B C270 DEBD 6842 A1A7 682A BA98 875D 87B9
Curves mailing list