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

[Oleg Andreev]

> On 7 Apr 2017, at 14:17, Oleg Andreev <oleganza at gmail.com> wrote:
> 
>> 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.

Tony Arcieri just showed me this summary (https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/) 
of existing Ed25519 implementations where all (but NaCl) accept 32-byte privkey that 
is hashed and then clamped as described in EdDSA. 

This means that for all of these implementations, the smallest change 
would be to factor out signing code using expanded 64-bit key, and let the outer scheme
manage creation of that key. NaCl library has that code factored out already, so no change necessary.

Here's an example of such refactoring for Go ed25519 library: 
https://github.com/chain/chain/commit/88af34b0f40193d06c7f23576360f8fe7c101f0d

My conjecture is: if there is no implementation that accepts 64-byte expanded key 
and sets bits in its left half, then arguments that bit-twiddling is good 
for compatibility become irrelevant -- because no one except NaCl can possibly be compatible with any HKD scheme.