> Date: Wed, 29 Mar 2017 14:30:55 -0700 > From: Henry de Valence <hdevale...@hdevalence.ca> > > So the advantage is that you can view scalars as elements of Z/lZ, and > then just choose a safe representative whenever you want to use one. > > This seems simpler than multiplying by the cofactor, which has to be > done in Z, not Z/lZ, and therefore requires thinking about which > operations are done modulo l and which aren't.
For a new design, that sounds mathematically nicer. But given the premises (a) that it would be nice to reuse existing code for EdDSA that already does bit-twiddling clamping for the private-key-to-public-key map, especially now that it has been formalized in an RFC; (b) that various protocols may share key material between Montgomery DH and EdDSA (e.g., XEdDSA); and (c) that the Montgomery DH protocol was designed to use the concicest approach to turning a uniform random secret byte string into a scalar -- k[0] &= 0xf8; k[31] &= 0x7f; k[31] |= 0x40; -- that admits a fast constant-time Montgomery ladder and that attacker-chosen inputs won't reveal bits of, it may be prudent to generally preserve the bit-twiddling clamp for the private-to-public-key map, even if from the perspective of Edwards signatures it is a little wacky and contributes nothing to security. (How does that joke go about the historical trajectory by which the width of a horse's rear end determined the fuel capacity of the space shuttle?) At the very least, I don't think EdDSA's bit-twiddling clamp poses any obstacles to a hierarchical key derivation scheme. I commented a little more on these practical concerns over at the CFRG: https://www.ietf.org/mail-archive/web/cfrg/current/msg09093.html All that said, perhaps these premises matter less than I'm guessing. _______________________________________________ Curves mailing list Curves@moderncrypto.org https://moderncrypto.org/mailman/listinfo/curves