[curves] Ed448-Goldilocks SHAKE

[David Leon Gil]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20140715/673906fc/attachment.html>