Re: [Cfrg] Elliptic Curves - signature scheme: randomised or not (ends on May 13th)

3.  Implementations SHOULD use whatever specific deterministic construction CFRG decides on.  But using a randomized construction for technical reasons (side channel protection, threshold signatures, low-latency coupons or whatever) should not be forbidden by the spec, especially since the other party can’t tell how you signed it.

PS Sorry Alexey, I accidentally replied only to you before.

> On May 3, 2015, at 4:14 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
> 
> CFRG chairs are starting discussion of the next topic.
> 
> The consensus view of the mailing list was that NIST compliance of our selected
> signature scheme is not necessary, opening up the opportunity for us to
> consider a rich class of signature schemes beyond ECDSA.
> 
> Most if not all signature schemes defined over elliptic curves can be
> de-randomised by generating the "random" value used during signing in a
> pseudorandom manner from the message to be signed. This ameliorates some
> catastrophic failure modes for these schemes. The generation could involve
> using a PRF such as HMAC with a key designed solely for this purpose
> (resulting in an augmented private (signing) key). An alternative could be
> to hash a string consisting of a concatenation of the private (signing)
> key with the message to be signed. There are other possibilities too.
> Several methods are described in detail in RFC 6979
> (http://tools.ietf.org/html/rfc6979 <http://tools.ietf.org/html/rfc6979>).
> 
> To determine the way forward, we are going to conduct a poll to determine
> how we should tackle the question of de-randomisation. Please pick one of the
> options specified below:
> 
> 1. CFRG should stick to randomised signature schemes only.
> 
> 2. CFRG should adopt deterministic signature scheme only.
> 
> 3. De-randomisation should be an optional feature for implementers to
> decide upon (i.e. both choices 1 and 2 allowed).
> 
> Please address only this specific topic of de-randomisation at this time.
> Further topics will follow.
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg