[curves] Ed25519 "clamping" and its effect on hierarchical key derivation

[Taylor R Campbell]

> 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
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.