Re: [Cfrg] EC signature: next steps

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

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. :-)
-- 
Regards,
Uri Blumenthal





On 9/4/15, 16:18 , "Cfrg on behalf of Stephen Farrell"
<[e-mail] on behalf of [e-mail]> wrote:

>
>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