Re: [Cfrg] On the use of Montgomery form curves for key agreement

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 02 September 2014 15:33 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 E97B41A0ACE for <cfrg@ietfa.amsl.com>; Tue, 2 Sep 2014 08:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 2EnUyDpNJQVb for <cfrg@ietfa.amsl.com>; Tue, 2 Sep 2014 08:33:27 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B96DF1A005C for <cfrg@ietf.org>; Tue, 2 Sep 2014 08:33:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 87AF8BE88; Tue, 2 Sep 2014 16:33:26 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc9vY5lxarQB; Tue, 2 Sep 2014 16:33:24 +0100 (IST)
Received: from [10.87.48.9] (unknown [86.42.23.36]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9BC15BE83; Tue, 2 Sep 2014 16:33:24 +0100 (IST)
Message-ID: <5405E343.7010302@cs.tcd.ie>
Date: Tue, 02 Sep 2014 16:33:23 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>
References: <e16ac4926a934565a65456058e50b68e@BL2PR03MB242.namprd03.prod.outlook.com> <CALCETrUby2o5O3=tMkv20JTVkahSo5Wan4oSCPOspRnXhFCg+g@mail.gmail.com> <b53e2c5417d247199f4496e0c0d5c29c@BL2PR03MB242.namprd03.prod.outlook.com> <CACsn0cktxTyPpeaqKU-oL+DiP4Fu0risHB1Wx8-by+94s30h=g@mail.gmail.com> <CA+Vbu7yMvyPzRAGrtVH38mzaYy3XQ1wswEUQisqbwpT10JfQVg@mail.gmail.com> <54058021.9040801@cs.tcd.ie> <CACsn0c=XV4bQSa7Oh3=s+JvFpJdT3Lm16wQHRG2ACEjxuU-dvg@mail.gmail.com>
In-Reply-To: <CACsn0c=XV4bQSa7Oh3=s+JvFpJdT3Lm16wQHRG2ACEjxuU-dvg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/NkMK0nGCQFdCKp-O9_w9jKv8SBg
Cc: "cfrg@ietf.org" <cfrg@ietf.org>
Subject: Re: [Cfrg] On the use of Montgomery form curves for key agreement
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: Tue, 02 Sep 2014 15:33:30 -0000


On 02/09/14 16:19, Watson Ladd wrote:
> On Tue, Sep 2, 2014 at 1:30 AM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie>; wrote:
>>
>> Just on this point...
>>
>> On 02/09/14 02:50, Benjamin Black wrote:
>>> The various working groups and standards bodies have already answered the
>>> question of what goes on the wire.
>>
>> That's not correct. When CFRG finish doing a great job here, then
>> the TLS WG will have to assign new codepoints for ciphersuites and
>> there is nothing stopping them defining new encodings at that point
>> if that's needed. That'd just not be a big deal. And the same is
>> true of other IETF activities. So what goes on the wire should be
>> a non-issue for this discussion really.
> 
> Aren't we replacing SEC1? And doesn't SEC1 specify encodings, which
> other WGs use?

CFRG is not replacing anything, but rather picking new additional
curves.

If those new curves turn out to be way more popular then maybe
over time they'll displace use of others, but only time will
tell that, not CFRG.

> If we end up saying "pairs of integers" then we get a mess, where
> software implementing the curves has to implement a large number of
> encodings. If we specify things as strings of bytes, that's easy to
> deal with. I've heard some people say this was a mistake, but I am
> unconvinced by those arguments. 

The point is that afaik none of those arguments help to pick
new curves. If CFRG want to suggest something for on-the-wire
formats after having picked some curves that's fine and it may
or may not be adopted by various IETF protocols, depending on
how well it fits their needs I guess.

Main point is: I don't believe wire-format issues make any
difference when picking new curves.

S.

> 
> Sincerely,
> Watson Ladd
> 
>