Re: [Cfrg] Consensus and a way forward

"Paterson, Kenny" <> Thu, 27 November 2014 10:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BF8F81A871D for <>; Thu, 27 Nov 2014 02:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZHbfgPxogsuC for <>; Thu, 27 Nov 2014 02:01:49 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe00::698]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FE2A1A7008 for <>; Thu, 27 Nov 2014 02:01:47 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 27 Nov 2014 10:01:23 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 27 Nov 2014 10:01:22 +0000
Received: from ([]) by ([]) with mapi id 15.01.0026.003; Thu, 27 Nov 2014 10:01:22 +0000
From: "Paterson, Kenny" <>
To: Joppe Bos <>, Benjamin Black <>, "" <>
Thread-Topic: [Cfrg] Consensus and a way forward
Thread-Index: AQHQCfpEJvmjPqb6m0eCglKXiG8J75xz/7MAgAA+gYA=
Date: Thu, 27 Nov 2014 10:01:22 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB382;UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB382;
x-forefront-prvs: 040866B734
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(189002)(377454003)(479174003)(51444003)(51704005)(199003)(4396001)(101416001)(40100003)(36756003)(105586002)(21056001)(19580405001)(106116001)(99396003)(122556002)(19580395003)(106356001)(74482002)(77156002)(62966003)(2656002)(46102003)(120916001)(15975445006)(2501002)(54356999)(50986999)(15202345003)(97736003)(76176999)(31966008)(20776003)(66066001)(561944003)(95666004)(92566001)(92726001)(575784001)(86362001)(83506001)(107046002)(64706001)(87936001)(107886001)(7059030)(781001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB382;; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB0685;
Subject: Re: [Cfrg] Consensus and a way forward
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Nov 2014 10:01:53 -0000

Dear Joppe,

Your point is well-noted.

Recently, I closely read all the messages on the list about random primes
versus special primes. It's clear that we did not reach a consensus on
this issue (and indeed there was no prospect of reaching one).

However, I think that we should focus in the immediate future on selecting
curves for special primes for recommendation to the TLS WG.

I would be delighted if, after that process is complete, we would return
to the question of coming up with a set of curves for random primes. I
think CFRG should sponsor such an effort in due course. Naturally, whereas
there is a limited set of sensible choices for special primes, this is not
the case for random primes. So we would also need to agree on a procedure
or ceremony for generating the primes themselves. I would like to defer
further discussion of that until the current workflow for special primes
and curves is completed. Of course, you and others can be thinking about
how to do it in the background.

I realise that there is a big decision implied by my e-mail: special
primes rather than random primes.

Given this, let me also state I do not want to re-open the debate about
the pros and cons of this choice now, as I believe they were already
well-ventilated on the list over the last few months.

Of course, I cannot stop anyone posting on this topic! However, I'd remind
everyone who thinks about doing so that we already had a lot of discussion
about it, that we did not reach consensus, and that in such a situation it
becomes necessary for (and indeed the responsibility of) the chairs to
make a decision to enable things to move forward.



On 27/11/2014 06:17, "Joppe Bos" <> wrote:

>This draft presents algorithms to “generate domain parameters at any
>security level for modern (twisted) Edwards curves” given as input prime.
>In the Test Vectors
> section curves defined over primes of a special shape are given. Please
>note that one can also use this draft to select curves which are defined
>over primes which do not have a special shape: something which has been
>requested by different people on this list.
> I hope that we will use this draft to (also) select curves over primes
>which do not have a special shape to accommodate all the needs in the
>cryptographic (and wider security) community.
>Best regards,
>From: Cfrg []
>On Behalf Of Benjamin Black
>Sent: Thursday, November 27, 2014 5:25 AM
>Subject: [Cfrg] Consensus and a way forward
>Over the past couple of weeks we have been working with Adam Langley to
>see if we could find a compromise with which we could all live. I'm
>pleased to say we have been successful in accommodating our respective
>performance and trustworthy
> generation concerns, and I hope the resulting proposal will be
>attractive to others, as well. The generation procedure is document in a
>draft I've just posted that can be found at
> .
>The simplest summary is that we have combined the prime preferred by Adam
>and others at the 128-bit security level with the rigid parameter
>generation we view as essential for producing the most trustworthy
>curves. We have used the generation
> procedure to produce a new twisted Edwards curve based on 2^255 - 19 and
>a new Edwards curve based on 2^384 - 317. These new curves are given as
>test vectors in the draft, and are also given below.
>These 2 curves are sufficient for meeting the request from TLS. However,
>if there is strong interest in a 3rd curve for the 256-bit security
>level, the generation procedure​​ gives the same curve with p =2^521 - 1
>as several teams produced.
>2^255 - 19
>   d = 0x15E93
>   r = 0x2000000000000000000000000000000016241E6093B2CE59B6B9
>         8FD8849FAF35
>x(P) = 0x3B7C1D83A0EF56F1355A0B5471E42537C26115EDE4C948391714
>         C0F582AA22E2
>y(P) = 0x775BE0DEC362A16E78EFFE0FF4E35DA7E17B31DC1611475CB4BE
>         1DA9A3E5A819
>   h = 0x4
>2^384 - 317
>           CB46BE1CF61E4555AAB35C87920B9DCC4E6A3897D
>  x(P) = 0x61B111FB45A9266CC0B6A2129AE55DB5B30BF446E5BE4C005763FFA
>           8F33163406FF292B16545941350D540E46C206BDE
>  y(P) = 0x82983E67B9A6EEB08738B1A423B10DD716AD8274F1425F56830F98F
>           7F645964B0072B0F946EC48DC9D8D03E1F0729392
>     h = 0x4