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

[Oleg Andreev]

> On 29 Mar 2017, at 15:32, Taylor R Campbell <campbell+moderncrypto-curves at mumble.net> wrote:
> 
> (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;

Doesn't bit-twiddling only happen immediately after expanding 32-byte random string into a 64-byte "expanded secret key" where first half is a scalar where clamping is applied, and the second half is the "prefix" that later is hashed with the message to generate a nonce?

For instance, NaCl API accepts 64-byte secret and does not modify its bits - that's assumed to be done in the separate "generate keypair" function. EdDSA does not even have a name or interface for 64-byte secret key, and a Go lib for ed25519 also assumes privkey is a raw 32-byte buffer to be hashed.

I mean, is there really a piece of software accepts a 64-byte (already expanded) secret key and tweaks its bits? Because if there isn't, then bit-twiddling that happens in the interfaces accepting 32-byte strings is irrelevant to HKD schemes - they won't be able to derive a child pubkey from a parent pubkey if there's non-linear hashing involved.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20170407/958f2ff6/attachment.html>