Following up on my comments re using Shake with Goldilocks, rather than the NSA-designed SHA2-512:<div><br></div><div>(This is, needless to say, not endorsed by Mike.)<br></div><div><br></div><div># Experimental code</div>
<div><br></div><div>An implementation based on Mike Hamburg's July 11 Goldilocks release is available at <a href="https://github.com/coruus/ed448-goldilocks">https://github.com/coruus/ed448-goldilocks</a></div><div><br>
</div><div>A compatible 'libkeccak' is available at <a href="https://github.com/coruus/keccakc">https://github.com/coruus/keccakc</a> (the 'next' branch has a simple CMake build system).</div><div><br></div>
<div>(It uses the Keccak team's C implementation of the permutation (but nothing else from KeccakCodePackage). I intend to merge Ronny van Keer's slightly faster assembler for the Keccak permutation from SUPERCOP at some point.)</div>
<div><br></div><div>It builds; tests and benchs pass.</div><div><br></div><div>## Signatures</div><div><br></div><div>Here's the strategy, w.r.t. signatures, where H is a Shake instance:</div><div><br></div>privatekey = H(proto, ds_goldi_derivepk)<br>
<div>nonceg = H(message, pk, ds_goldi_signonce)</div>challenge = H(message, nonceg, pubkey, ds_goldi_signonce)<div><br></div><div>Note the following: If verifying multiple signatures, the sponge state after absorbing the message only needs to be calculated once. (Double-hash and envelope-MAC aren't necessary for a sponge function.) This is useful for some applications, and doesn't hurt performance elsewhere.</div>
<div><br></div><div>## Questions</div><div><br></div><div>1. Would people be comfortable with Shake128[c=256] for generating nonceg and challenge? The recent security proofs indicate that this provides 256-bit security strength for 'keyed' modes of operations; all of the uses of H are 'keyed' in the correct sense. (Right now the default is Shake256.)</div>
<div><br></div><div>2. Are there any attacks that hashing the sum and product of the pubkeys prevents that just hashing pubkeys doesn't, for ECDH? (This is fairly expensive...)</div><div><div><br></div><div>(Note also that this fixes a minor bug in word.h that made Goldilocks not build. The makefile is set up with -march=native, so it should build on any Mac, at least.)</div>
</div><div><br></div><div>## Tunable parameters</div><div><br></div><div>Applications can now request a derived shared secret of arbitrary length.</div><div><br></div><div>The size of the 'protokey' can be tuned, with a few changes to assertions. I'd prefer for it to be, say, 48 bytes, but for the moment it's still 32 bytes.</div>
<div><br></div><div>## Trevor:</div><div><br></div><div>Re using the same key for signing and DH:</div><div><br></div><div>You can still, of course, with this design, do this.</div><div><br></div><div>But -- you could also derive two private keys from the protokey. This gives you security only on the CDH assumption (rather than Gap-DH); you can bootstrap from a known DH public key by (the private key holder) cross-signing PoPs once. (This may be unacceptable for your application; not sure. Are you thinking about for Axolotl, Noise, or?)<br>
</div><div><br></div><div>## Mike:</div><div><br></div><div>I think that Blake2 is faster than Shake256 (but maybe not Shake128(?)) at present. I believe that it too is designed to be safe used like this. Keccak will, eventually, be blazingly fast, but not until silicon implementations. </div>
<div><br></div><div>(One of my goals at present is to eradicate SHA1 and SHA2 as quickly as possible; this will increase the pressure on Intel and ARM provide hardware support for Keccak.)<br></div><div><br></div><div>Thoughts on naming: How about Ned448, for nonceless deterministic ECDSA? (Because this design is a little different -- though equivalent in RO -- from plain Ed's?)</div>
<div><br></div><div>-dlg</div>