[Cfrg] Curves as groups

Douglas Stebila <stebila@qut.edu.au> Fri, 08 August 2014 22:36 UTC

Return-Path: <stebila@qut.edu.au>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E69F61A0107 for <cfrg@ietfa.amsl.com>; Fri, 8 Aug 2014 15:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XGqucUahkHtb for <cfrg@ietfa.amsl.com>; Fri, 8 Aug 2014 15:36:32 -0700 (PDT)
Received: from ex10ed04.qut.edu.au (ex10ed04.qut.edu.au []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1941A00F2 for <cfrg@ietf.org>; Fri, 8 Aug 2014 15:36:30 -0700 (PDT)
Received: from EX10HT04.qut.edu.au ( by ex10ed04.qut.edu.au ( with Microsoft SMTP Server (TLS) id; Sat, 9 Aug 2014 08:36:26 +1000
Received: from EX10MB4.qut.edu.au ([]) by EX10HT04.qut.edu.au ([]) with mapi id 14.03.0158.001; Sat, 9 Aug 2014 08:36:26 +1000
From: Douglas Stebila <stebila@qut.edu.au>
To: "cfrg@ietf.org" <cfrg@ietf.org>
Thread-Topic: Curves as groups
Thread-Index: AQHPs1kvhy7XhGBvZEi1zyqXq6aFeA==
Date: Fri, 8 Aug 2014 22:36:25 +0000
Message-ID: <0C413841-D0E9-4D74-B390-8996C7EE77D2@qut.edu.au>
Accept-Language: en-CA, en-AU, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9F97B71E92B93D46944FF71EC2CAA2D3@exchange.qut.edu.au>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/WSGVmmMSEW2J9jyamMgoXevl_k4
Subject: [Cfrg] Curves as groups
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: Fri, 08 Aug 2014 22:36:34 -0000

Do members of CFRG think it important that the curve(s) we recommend be usable as arbitrary groups?  By this I mean that the implementations readily expose both a scalar point multiplication operation and a point addition operation.  

Utility as arbitrary groups would I think imply criteria R3 (Desired: re-use components between signatures and key exchange algorithms) but the reverse is not necessarily true.  

Curve25519+Ed25519 together give key exchange and signatures, but are high-level cryptographic functions, not groups.  The Curve25519 private API has scalar point multiplication functions but not point addition; the Ed25519 private API has both.  The NUMS library has public interfaces for scalar point multiplication and kP+lQ, but arbitrary point addition is only in the private API with a disclaimer on context of use.  To what extent are these a choice by implementers to only implement the functions needed to achieve their desired cryptographic scheme versus inherent to the mathematical design?

While criteria R3 will ensure we have something that we can use for key exchange and signatures immediately, I think it would be good for cryptographers to also have good, plain old groups from elliptic curves, for whatever new schemes we may invent or try to implement over the next 10 years.  Prior IETF initiatives (RFC 3526, RFC 5114) seem to have focused on groups rather than key exchange / signature functions.