Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as a RG document

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 05 January 2015 21:18 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 014C41A8A92 for <cfrg@ietfa.amsl.com>; Mon, 5 Jan 2015 13:18:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 hr2rPGHue24H for <cfrg@ietfa.amsl.com>; Mon, 5 Jan 2015 13:18:21 -0800 (PST)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AF61A8A70 for <cfrg@irtf.org>; Mon, 5 Jan 2015 13:18:20 -0800 (PST)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 727EF1887A2; Mon, 5 Jan 2015 23:18:18 +0200 (EET)
Date: Mon, 5 Jan 2015 23:18:18 +0200
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Adam Langley <agl@imperialviolet.org>
Message-ID: <20150105211817.GA24029@LK-Perkele-VII>
References: <54AAE2CA.1080701@isode.com> <CAMfhd9Vk8X55jbddsh_Dz9gc=qC3NqM5-EiUi7LakjdrziX0Sg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAMfhd9Vk8X55jbddsh_Dz9gc=qC3NqM5-EiUi7LakjdrziX0Sg@mail.gmail.com>
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/i5dxVJ3hKV58Ag1dfjztoa68tpQ
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as a RG document
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: Mon, 05 Jan 2015 21:18:24 -0000

On Mon, Jan 05, 2015 at 11:49:47AM -0800, Adam Langley wrote:
> On Mon, Jan 5, 2015 at 11:15 AM, Alexey Melnikov
> <alexey.melnikov@isode.com> wrote:
> > whether you want a particular change be made to the
> > document before adoption.
> 
> The structure of the current draft anticipates an additional curve and
> also signature work so I'd like to point out a couple of changes to
> save others having to do so:
> 
> 1) If no other curves end up being recommended, then the current
> generation process is overly complicated and could well be replaced
> with a description that mirrors how curve25519 was actually chosen:
> i.e. that the minimal sensible A value in Montgomery form be chosen.
> It really depends on how important a generic procedure is seen to be.

I think curve generation procedure should be there.
 
> 2) The procedure for generating base points is currently unused and,
> if change (1) is done, it could be tweaked to reflect how the
> curve25519 base point was generated.

Also, the past precent on base point generation on Edwards curves seems
to be the least y, least x with big prime order.

But the procedure here looks acceptable as well.

> 3) If we don't end up saying anything about signatures, all mention of
> Edwards curves could conceivably be dropped.

Also, depending on exact signature scheme, having full isogeny/isomorphism
chains to Weierstrass (these are easy enough to either find or derive, but
still) and back (the dual isogeny for Edwards and Montgomery is more
difficult to find) would be useful.

Specifically, the place where that dual isogneny would be useful is
if using ECDSA (yes, I know) with Weierstrass public keys. That would
avoid implementing Weierstrass (which is somewhat annoying, even if
doing public-only computations and having the field routines).


-Ilari