[curves] Ed25519 "clamping" and its effect on hierarchical key derivation
Taylor R Campbell
campbell+moderncrypto-curves at mumble.net
Wed Mar 29 15:32:59 PDT 2017
> Date: Wed, 29 Mar 2017 14:30:55 -0700
> From: Henry de Valence <hdevalence at 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
(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 &= 0xf8; k &= 0x7f; k |= 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
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:
All that said, perhaps these premises matter less than I'm guessing.
More information about the Curves