Following up on my comments re using Shake with Goldilocks, rather than the NSA-designed SHA2-512:
(This is, needless to say, not endorsed by Mike.) # Experimental code An implementation based on Mike Hamburg's July 11 Goldilocks release is available at https://github.com/coruus/ed448-goldilocks A compatible 'libkeccak' is available at https://github.com/coruus/keccakc (the 'next' branch has a simple CMake build system). (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.) It builds; tests and benchs pass. ## Signatures Here's the strategy, w.r.t. signatures, where H is a Shake instance: privatekey = H(proto, ds_goldi_derivepk) nonceg = H(message, pk, ds_goldi_signonce) challenge = H(message, nonceg, pubkey, ds_goldi_signonce) 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. ## Questions 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.) 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...) (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.) ## Tunable parameters Applications can now request a derived shared secret of arbitrary length. 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. ## Trevor: Re using the same key for signing and DH: You can still, of course, with this design, do this. 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?) ## Mike: 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. (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.) 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?) -dlg
_______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
