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

On 05/03/2015 10:39 AM, Michael Hamburg wrote:
> 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.

+1 to the above #3.

If I see it correctly, the value of #2 is viewed in the following context:

* we trust the system to correctly generate a long-term secret, and 
possibly a dedicated long-term seed

* the signature standard will specify a DRBG and how to seed it to 
generate bytes, e.g. for the r in ECDSA

* we rely on audit or a vendor assurance that the implementation indeed 
uses the standard-mandated DRBG and the seed(s) correctly; note that 
using random bytes instead of said DRBG is undetectable by verifiers

I second the problem with #2 that it's not cryptographically enforceable 
and it limits some performance optimizations. Therefore, SHOULD is fine, 
but prohibiting random bytes instead of specific DRBG is overkill. 
TLS1.2 currently requires access to plenty of random/pseudorandom bytes, 
for example.

>
> PS Sorry Alexey, I accidentally replied only to you before.
>
>> On May 3, 2015, at 4:14 AM, Alexey Melnikov <alexey.melnikov@isode.com
>> <mailto: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).
>>
>> 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 <mailto:Cfrg@irtf.org>
>> http://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>