> On 29 Mar 2017, at 15:32, Taylor R Campbell > <campbell+moderncrypto-cur...@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.
_______________________________________________ Curves mailing list Curves@moderncrypto.org https://moderncrypto.org/mailman/listinfo/curves
