Re: [Cfrg] EC signature: next steps

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

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; [e-mail]
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:[e-mail]] On Behalf Of Rene Struik
> Sent: Friday, September 04, 2015 8:24 AM
> To: Alexey Melnikov; [e-mail]
> Subject: Re: [Cfrg] EC signature: next steps
> 
> 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
>> [e-mail]
>> https://mail.ietf.org/mailman/listinfo/cfrg
> 
> 

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