Re: [Cfrg] Signatures: curves, algorithms, etc

Some brief notes:

1. Hash functions. I'd really like to see a better hash function for any
options besides Ed25519. Two options for Ed25519:

1. Same point format. Keep the hash the same. Don't break compatibility.

2. New point format. Replace SHA2 with Blake2 or Prefix-MAC(SHAKE128).

For higher security strength curves, the EC-Schnorr security proofs suggest
2s hashing. Only SHAKE256 seems to work for that.

I mildly prefer EC-Schnorr to ECDSA, Franken- or not.

--

2. Signature schemes with coupons and tight reductions to CDH. Hashing to
an EC group is really easy with a variable-output-length keyed PRF. (Does
this have to be done in constant time?)

Pointcheval(?) has an interesting scheme involving 'coupons', in which all
scalar muls can be done *before* signing a message. The scheme has a tight
reduction to CDH.

This strikes me as potentially much more efficient than even Schnorr-EC for
signers: The scalarmuls are no longer in the critical path. So you get
asymmetric signatures for (very slightly more than) the latency of
computing a MAC[*]

[*] Note that this means you can compute coupons at periods of low
computational demand, which may be a substantial cost savings.

David Leon Gil
Senior Paranoid
Yahoo!

PS. Sending via Gmail because the CFRG mailing list software attempts to
forge @yahoo-inc.com FROM addresses. And Yahoo sets a DMARC p=reject. Could
a list admin please configure the IRTF listserv to not blatantly violate
the IETF DMARC standard?
On Thu, Jan 29, 2015 at 9:27 PM Damien Miller <djm@mindrot.org> wrote:

> On Tue, 27 Jan 2015, Tony Arcieri wrote:
>
> > I would like to hear the opinions of the chairs and other CFRG
> participants
> > on the following:
> > - Ed25519 and EdDSA
> > - FrankenECDSA (ECDSA in Edwards)
> > - ECDSA with Edwards keys on the wire (converted to Weierstrass to do
> ECDSA)
> > - Other interesting thoughts on digital signatures
>
> As you probably already know OpenSSH is already using Ed25519 for
> user and host authentication. We chose it because:
>
> 1) It's secure; well-reviewed and based on good "bones" (e.g. Schnorr sigs)
> 1a) It avoids the terrible failure modes of DSA/ECDSA
> 1b) It's hard for implementors to get wrong
> 2) It's fast
> 3) There are excellent reference implementations available
>
> We're not interested in adding more DSA/ECDSA variants unless there is some
> compelling reason (and I don't see any). EdDSA just seems a better
> algorithm.
>
> We're not super-interested in WF >2^128 EdDSA either, but would possibly
> consider EdDSA at ~WF 2^256 if our users start asking for it.
>
> We aren't likely to benefit from batch signing/verification.
>
> -d
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>