[Cfrg] Elliptic Curves - curve form and coordinate systems (ends on March 12th)

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 05 March 2015 23:31 UTC

Return-Path: <alexey.melnikov@isode.com>
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 51F511A9073 for <cfrg@ietfa.amsl.com>; Thu, 5 Mar 2015 15:31:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZI-W7JCk-aHe for <cfrg@ietfa.amsl.com>; Thu, 5 Mar 2015 15:31:02 -0800 (PST)
Received: from waldorf.isode.com (ext-bt.isode.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9BF011A908E for <cfrg@irtf.org>; Thu, 5 Mar 2015 15:31:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1425598260; d=isode.com; s=selector; i=@isode.com; bh=23qq3kUXaUHiOZD7ED0oHlc608AKNtFfiaFCfsu24Hw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=N6ex1XO/H6LFnEnmc78BNBZpb5GkvGzIEGEeTwboa2dLzZWKIutxtYWy5NAxPQrzrdouBr SwK39BJISduxG0qTdKSkYGUaYt6lsVLPjnds3S+B4qKbNWlBbrQZqfXzh5g0rCa3CJO9iC NU8aXHSzu0DOwUvp1uv7zAI5iHcHeA4=;
Received: from [] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net []) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VPjnNABB7VZj@waldorf.isode.com>; Thu, 5 Mar 2015 23:31:00 +0000
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <54F8E735.2010202@isode.com>
Date: Thu, 05 Mar 2015 23:31:01 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
To: "cfrg@irtf.org" <cfrg@irtf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/bBRdLtC3gJtd5hQIqYpl7EQ5IoY>
Subject: [Cfrg] Elliptic Curves - curve form and coordinate systems (ends on March 12th)
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: Thu, 05 Mar 2015 23:31:03 -0000

CFRG chairs are starting discussion of the next topic:

Q4: draft-irtf-cfrg-curves-01 currently contains curves in both 
Montgomery form and Edwards form. The scalar multiplication routine is 
specified using Montgomery form (and is specific to Curve25519, which 
will need to be changed given our decision to include a higher security 
level curve). Its input is a scalar and the u-coordinate of a point on a 
Montgomery-form curve; its output is the u-coordinate of a point on a 
Montgomery-form curve. The DH function builds on this routine. Do we 
want to stay with specifying the inputs and outputs in Montgomery form 
for these routines? Or do we want to switch to an alternative curve form 
and coordinate system for defining the routines? If so, which form and 
coordinate system?

[Chairs are aware that it is possible to switch back and forward between 
different curve forms and coordinate systems, with associated costs, no 
matter which form is specified for the inputs and outputs of the 
routines. But we now have to decide *which* form we want to use for 
inputs and outputs, so as to ensure interoperability between Alice and 
Bob. Chairs did not want to implicitly force the choice of Montgomery 
form/coordinates without polling the group first.]

Once this issues is settled, we will be discussing (in no particular 
order. Chairs reserve the right to add additional questions) wire 
format, byte order and signature schemes. Please don't discuss any of 
these future topics at this time.