[curves] When is removing the cofactor (Decaf) a better choice?

[Mike Hamburg]

Hi Rosalie,

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.

Cheers,
— Mike

> On Mar 22, 2017, at 11:31 AM, Rosalie Tolentino <rtolenti at thoughtworks.com> wrote:
> 
> Hi,
> 
> 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?
> 
> Much appreciated,
> Rosalie
> 
> --
> Rosalie Tolentino
> Pure Energy
> She/Her They/Them
> 
> Fingerprint: 55A0 392B C270 DEBD 6842  A1A7 682A BA98 875D 87B9
> _______________________________________________
> Curves mailing list
> Curves at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/curves

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3571 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20170322/26362b7f/attachment.bin>