Subject: Re: [Cfrg] EC signature: next steps

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 4 Sep 2015 21:10:13 +0000

I see your point. But I don't see what makes the next few weeks crucial as opposed to the weeks before and after this period.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Stephen Farrell
Sent: Friday, September 4, 2015 16:38
To: Blumenthal, Uri - 0553 - MITLL; William Whyte; Rene Struik; Alexey Melnikov; [email-masked]
Subject: Re: [Cfrg] EC signature: next steps

On 04/09/15 21:26, Blumenthal, Uri - 0553 - MITLL wrote:
> It took us all a while to get here. If it takes a bit longer to get it
> right, so be it.
> 
> There’s ECDSA and EC-KCDSA for those who can’t wait any longer. :-) Not
> to mention [F]HMQV. :-)
> 

Being any slower here IMO risks implementations for a number of
protocols shipping with Ed25519, causing confusion and possible
interop issues. The issue is simply whether or not CFRG's work
will be overtaken by events. I hope that won't happen and have
been asking folks within IETF WGs to please hold off. But they
won't forever, and a number of folks have expressed frustration
at how long this is taking. Taking longer certainly increases
the liklihood of this work being OBE.

S.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 4 Sep 2015 21:10:18 +0000

‎
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.‎

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 4 Sep 2015 22:27:20 +0000

Rene,

Could you put together a list of specific changes to one (or more) of the proposed signature candidates? 

This would both offer a chance to incorporate those improvements (at this stage of the process :), and make the process itself somewhat smoother...

Thanks!

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Stephen Farrell
Sent: Friday, September 4, 2015 16:18
To: William Whyte; Rene Struik; Alexey Melnikov; [email-masked]
Subject: Re: [Cfrg] EC signature: next steps

If the cost of supporting any of the things Rene mentions is *any*
delay, I'm against.

S.

On 04/09/15 19:00, William Whyte wrote:
> I also like the idea of being able to sign and verify without providing
> the public key as part of the hash input.
> 
> Cheers,
> 
> William
> 
> -----Original Message-----
> From: Cfrg [mailto:[email-masked]] On Behalf Of Rene Struik
> Sent: Friday, September 04, 2015 8:24 AM
> To: Alexey Melnikov; [email-masked]
> Dear colleagues:
> I think the signature scheme should facilitate the following:
> a) signature generation.
> Ideally, signing should be possible without requiring the signer to
> access its public key (obviously, it does require the private key). For
> Schnorr and ECDSA type schemes, one does not need to include the public
> key in the signing process, since security in the multi-user setting is
> roughly the same as in the single-user setting (see [1], [2]).
> b) signature verification.
> If the public key of the signer is not included with signing, it is also
> generally not required with verification (if the signature includes the
> ephemeral signing key), since then the public key of the signer can be
> reconstructed from the signature itself (with Schnorr signature (R,s)
> over message m, one has Q=(1/h)(R-sG), where h=H(R,m)). This may have
> advantages in settings with certificate chains and with single
> signatures (where one can reduce overhead to identify the public key of
> the signer).
> c) reuse of same signing key with IUF/non-IUF schemes.
> Ideally, one should be able to use the same signing key, no matter
> whether one uses the signature scheme in the so-called IUF setting or in
> the non-IUF setting. If I understand correctly, consensus is to only
> specify an IUF-scheme, but even then, the design should be so that it
> can support both flavors. This should *not* be left to applications to
> specify (and can also easily be done).
> d) same signature scheme for Weierstrass curves, (twisted) Edwards
> curves, and Montgomery curves.
> The signature scheme should work for all these three schemes and not
> just for (twisted) Edwards curves. Ideally, it should also work for Huff
> curves, Jacobian curves, etc., without requiring any changes outside the
> scalar multiplication routine.
> 
> Best regards, Rene
> 
> Ref:
> [1] A. Menezes, N.P. Smart, "Security of Signature Schemes in A
> Multi-User Setting", CACR-Corr-2001-063.
> [2] J. Malone Lee, S. Galbraith, N. P. Smart, "Public Key Signatures in
> the Multi-User Setting", Inform.Proc.Letters, 2002.
> 
> 
> 
> 
> On 8/31/2015 5:53 AM, Alexey Melnikov wrote:
>> Dear CFRG participants,
>>
>> Many thanks to Ilari for posting this updated summary of where things
>> currently stand. Kenny and I would now like to run a short discussion
>> focusing on this summary, with our intention being to flush out any last
>> issues or additional points of comparison between the different schemes
>> that everyone should be aware of.
>>
>> Once everyone has kicked the tires, so to speak, we plan to move to a
>> poll to decide which scheme CFRG should focus on writing up and formally
>> recommending. We, as chairs, are hoping these steps will get us to the
>> finishing line.
>>
>> So:
>>
>> - are there important characteristics or points of comparison that
>> Ilari's summary does not cover?
>>
>> - are there errors of fact or omission that need to be corrected?
>>
>> - anything else?
>>
>>
>> We'll let this discussion run for exactly one week, but we might extend
>> the time if the discussion is still going strong and new arguments or
>> points of comparison are brought up. After that, if no major new
>> information is brought up, we will start the Quaker poll for selecting a
>> single CFRG-recommended signature scheme.
>>
>>
>> Best Regards,
>> Kenny and Alexey
>>
>> _______________________________________________
>> Cfrg mailing list
>> [email-masked]
>> https://mail.ietf.org/mailman/listinfo/cfrg
> 
> 

_______________________________________________
Cfrg mailing list
[email-masked]
https://mail.ietf.org/mailman/listinfo/cfrg