Re: [Cfrg] EC signature: next steps
Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 04 September 2015 20:18 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 057D11A8A06 for <cfrg@ietfa.amsl.com>; Fri, 4 Sep 2015 13:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.311
X-Spam-Level:
X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0-Vaxtm6nEMn for <cfrg@ietfa.amsl.com>; Fri, 4 Sep 2015 13:18:06 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D361A897B for <cfrg@irtf.org>; Fri, 4 Sep 2015 13:18:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 678FFBDF9; Fri, 4 Sep 2015 21:18:04 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnh0BMmHLnd4; Fri, 4 Sep 2015 21:18:02 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.42.21.56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0B948BDCF; Fri, 4 Sep 2015 21:18:02 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441397882; bh=K6pEYFjJXXYmi9b8TxHlhcnDbAj00Kt+j2RmslwsnGU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=q2KKzjoWMaPbAnChTFqjAd3nrisQBhzbLe6g2RLm39A+Zu5RWs6l30qxxhQIh9Uut brGcuLrq9+XmBKQx3ju/eZNNPrd7GMD12wz8QV4p1vBmDz8cgFXDxKsKyNWbbv8bjk ei0EG1Rwpc85semq/aWosenGKU7vW3T6C7mc18dY=
To: William Whyte <wwhyte@securityinnovation.com>, Rene Struik <rstruik.ext@gmail.com>, Alexey Melnikov <alexey.melnikov@isode.com>, 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> <55E99B7C.6020509@gmail.com> <1822507ba15947761d52dadf31b88f52@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <55E9FC79.50302@cs.tcd.ie>
Date: Fri, 04 Sep 2015 21:18:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <1822507ba15947761d52dadf31b88f52@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/HOnKJqCXZs_YyTijPYyJWjY8E70>
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 20:18:09 -0000
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:cfrg-bounces@mail.ietf.org] On Behalf Of Rene Struik > Sent: Friday, September 04, 2015 8:24 AM > To: Alexey Melnikov; cfrg@irtf.org > 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 >> Cfrg@mail.ietf.org >> https://mail.ietf.org/mailman/listinfo/cfrg > >
- [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