> On 7 Apr 2017, at 14:17, Oleg Andreev <olega...@gmail.com> wrote: > >> 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.
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. _______________________________________________ Curves mailing list Curves@moderncrypto.org https://moderncrypto.org/mailman/listinfo/curves
