Re: [Cfrg] EC signature: next steps
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 01 September 2015 15:41 UTC
Return-Path: <ilari.liusvaara@elisanet.fi>
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 BF4651B4CE1 for <cfrg@ietfa.amsl.com>; Tue, 1 Sep 2015 08:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.779
X-Spam-Level:
X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no
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 FD7A42ahTvY8 for <cfrg@ietfa.amsl.com>; Tue, 1 Sep 2015 08:41:52 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0151D1B471A for <cfrg@irtf.org>; Tue, 1 Sep 2015 08:41:11 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 7DD681A2C78; Tue, 1 Sep 2015 18:41:09 +0300 (EEST)
Date: Tue, 01 Sep 2015 18:41:09 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20150901154109.GA1874@LK-Perkele-VII>
References: <55DD906F.3050607@isode.com> <D2035132.531EE%kenny.paterson@rhul.ac.uk> <55DDA21D.9060302@isode.com> <55DF3E3C.7020206@isode.com> <55E42414.3020805@isode.com> <8737yz4nfg.fsf@latte.josefsson.org> <20150831162832.GA16764@LK-Perkele-VII> <87vbbu39jd.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <87vbbu39jd.fsf@latte.josefsson.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/jj0c48xmASmP-IvUfSfbJNw0ZDI>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
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: Tue, 01 Sep 2015 15:41:53 -0000
On Tue, Sep 01, 2015 at 09:04:22AM +0200, Simon Josefsson wrote: > Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes: > > > On Mon, Aug 31, 2015 at 03:06:43PM +0200, Simon Josefsson wrote: > >> Alexey Melnikov <alexey.melnikov@isode.com> writes: > >> > >> > - are there errors of fact or omission that need to be corrected? > >> > >> 1) I don't understand by this part of Ilari's writeup: 'dictated by > >> ???'. > > > > I earlier tought that the prehash comes from the key, but then > > read comment by DJB stating that this is not the case. > > Do you have a reference? I believe the > http://ed25519.cr.yp.to/eddsa-20150704.pdf paper is clear on this. > Simply explained, the prehash is a parameter of the signature system. So it is denoted in the key (since signature system parameters need to be fixed by the key) after all? > > As for personalization, the problem is that protocols A and B (or > > even just different versions of the same protocol!) can interpret the > > same message in rather different ways. > > Do you have a concrete example? I would consider that a protocol flaw. The problem is that each protocol or version might be reasonable alone, but still interact badly. The worst are "challenge signing" protocols. One could argue that is a design flaw, but that kind of construct is used because it is simple. > >> 3) What is NPOT? > > > > (Order) Near Power Of Two. The difference of order and nearest power > > of two is on order of sqrt(l). > > > > Such orders produce even distributions of x mod l, where x is n bits > > long with smaller n than usual. > > > > Both Curve25519 and Curve448 are NPOT. > > How is this relevant to the chose of signature scheme? It isn't really relevant. -Ilari
- [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