IETF Logo Mail Archive

Re: [Cfrg] Summary of the poll: Elliptic Curves - signature scheme: friendliness to low memory implementations (ends on June 3rd)

"D. J. Bernstein" <djb@cr.yp.to> Sat, 13 June 2015 00:31 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
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 EBCA41A8867 for <cfrg@ietfa.amsl.com>; Fri, 12 Jun 2015 17:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.095
X-Spam-Level: **
X-Spam-Status: No, score=2.095 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, UNPARSEABLE_RELAY=0.001] 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 iwoVgMIEGTgQ for <cfrg@ietfa.amsl.com>; Fri, 12 Jun 2015 17:31:54 -0700 (PDT)
Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id 599F21A916E for <cfrg@irtf.org>; Fri, 12 Jun 2015 17:31:53 -0700 (PDT)
Received: (qmail 32377 invoked by uid 1017); 13 Jun 2015 00:32:12 -0000
Received: from unknown (unknown) by unknown with QMTP; 13 Jun 2015 00:32:12 -0000
Received: (qmail 29125 invoked by uid 1000); 13 Jun 2015 00:31:36 -0000
Date: Sat, 13 Jun 2015 00:31:36 -0000
Message-ID: <20150613003136.29124.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@irtf.org
Mail-Followup-To: cfrg@irtf.org
In-Reply-To: <5576F66F.8020902@isode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/o4GaMRUAsv7iQAYHhrnbm2hAPkg>
Subject: Re: [Cfrg] Summary of the poll: Elliptic Curves - signature scheme: friendliness to low memory implementations (ends on June 3rd)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jun 2015 00:31:56 -0000

Alexey Melnikov writes:
> After discussing answers to this poll chairs concluded that despite
> security limitations of Initiliase-Update-Finalise (IUF) APIs on
> verifier's end, there is rough consensus that any recommended CFRG
> signature scheme should support such APIs.

I can't figure out what this statement means. Can you please clarify
what you're saying the rough consensus is?

Taking, e.g., Ed25519 as an example: Would recommending

   * Ed25519(m) as the higher-security default and
   * Ed25519(SHA-3-512(m)), with an IUF API, for protocols that want
     small devices to be able to handle large messages in one pass

meet the requirement to "support" an IUF API?

Or are you saying that the recommendation would have to be just
Ed25519(SHA-3-512(m)), and that there's rough consensus against
splitting out the Ed25519(m) layer for protocols that want the higher
security?

---Dan

v2.23.0 | Report a Bug | By Email