Re: [Cfrg] EC signature: next steps
Rene Struik <rstruik.ext@gmail.com> Fri, 04 September 2015 13:24 UTC
Return-Path: <rstruik.ext@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17351B3B0D for <cfrg@ietfa.amsl.com>; Fri, 4 Sep 2015 06:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sZl3eZ6v0LV for <cfrg@ietfa.amsl.com>; Fri, 4 Sep 2015 06:24:21 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0C21B3B01 for <cfrg@irtf.org>; Fri, 4 Sep 2015 06:24:21 -0700 (PDT)
Received: by igcpb10 with SMTP id pb10so16316996igc.1 for <cfrg@irtf.org>; Fri, 04 Sep 2015 06:24:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=phJ9qHApFy/4nF8LVwxnNfoFDyjvGNmt4rfjXJQpeW4=; b=TJ7j8QnYA7W6SAYqfzrX16kfuNZJQj4kBCVZifEPknczIGxsZSSculkDkdmMmB6Qfm gaF3v95ohGLQBuClQs/53nJ9wz6z7VhZiMuHCv9OvbHZivRJzKEw7I9lWX187hMkd9OR MIBUk9+IyPZq7Rp3CWLL+NtoeZcwDfJobiQQ9MsAuZIk63afSa/jBM3yiacm+wW8IfKK LcVSb4+6R8jgHQSlOBlmKUsuARREOUqdqlzAxf7yiTd/u10pGg4ideWdn8jnhg7Np98j xlk3yBkJddrsViMXR8u3vcOqnGdtJ2v/Nr/y5ajlPxoWdZAIS4WA5P0koe8SgZPwwTVw 319A==
X-Received: by 10.50.143.11 with SMTP id sa11mr6807196igb.61.1441373060643; Fri, 04 Sep 2015 06:24:20 -0700 (PDT)
Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by smtp.gmail.com with ESMTPSA id g78sm1388906ioe.43.2015.09.04.06.24.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Sep 2015 06:24:20 -0700 (PDT)
To: Alexey Melnikov <alexey.melnikov@isode.com>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <55DD906F.3050607@isode.com> <D2035132.531EE%kenny.paterson@rhul.ac.uk> <55DDA21D.9060302@isode.com> <55DF3E3C.7020206@isode.com> <55E42414.3020805@isode.com>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <55E99B7C.6020509@gmail.com>
Date: Fri, 04 Sep 2015 09:24:12 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55E42414.3020805@isode.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/TOWH1DSzB-PfDGK8qEXtF3iC6Vc>
Subject: Re: [Cfrg] EC signature: next steps
X-BeenThere: cfrg@mail.ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.mail.ietf.org>
List-Unsubscribe: <https://mail.ietf.org/mailman/options/cfrg>, <mailto:cfrg-request@mail.ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@mail.ietf.org>
List-Help: <mailto:cfrg-request@mail.ietf.org?subject=help>
List-Subscribe: <https://mail.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@mail.ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2015 13:24:23 -0000
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 > Cfrg@mail.ietf.org > https://mail.ietf.org/mailman/listinfo/cfrg -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
- [Cfrg] EC signature: next steps Alexey Melnikov
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] EC signature: next steps Watson Ladd
- [Cfrg] EC signature: next steps Dan Brown
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Dan Brown
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- [Cfrg] Side inputs to signature systems D. J. Bernstein
- Re: [Cfrg] Side inputs to signature systems Natanael
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] Side inputs to signature systems Michael Hamburg
- Re: [Cfrg] EC signature: next steps Rene Struik
- Re: [Cfrg] EC signature: next steps David Jacobson
- Re: [Cfrg] EC signature: next steps Mike Hamburg
- Re: [Cfrg] EC signature: next steps William Whyte
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] key as message prefix => multi-key sec… Dan Brown
- [Cfrg] key as message prefix => multi-key security D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Paterson, Kenny
- Re: [Cfrg] key as message prefix => multi-key sec… Sven Schäge
- Re: [Cfrg] key as message prefix => multi-key sec… Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] key as message prefix => multi-key sec… William Whyte
- Re: [Cfrg] key as message prefix => multi-key sec… Bill Cox
- Re: [Cfrg] key as message prefix => multi-key sec… Andrey Jivsov
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Eike Kiltz
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Simon Josefsson