Re: [Cfrg] ECC reboot (Was: When's the decision?)

Alyssa Rowan <> Wed, 22 October 2014 12:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2B9781A90F9 for <>; Wed, 22 Oct 2014 05:59:46 -0700 (PDT)
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 bHfLWK8YSgCR for <>; Wed, 22 Oct 2014 05:59:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC6461A90F8 for <>; Wed, 22 Oct 2014 05:59:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Alyssa Rowan <>
Date: Wed, 22 Oct 2014 13:59:36 +0100
To: "Lochter, Manfred" <>,
Message-ID: <>
Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?)
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: Wed, 22 Oct 2014 12:59:46 -0000

Hash: SHA512

On 22 October 2014 13:04:36 BST, "Lochter, Manfred" <> wrote:
>And for me the reasoning from the BADA55 paper does not appear to be plausible.

I understand your defending your position, but there does appear to be professional disagreement on that point. (I think myself they are indeed plausible but not too likely, as the approach taken by Brainpool would have likely been the most obvious one at the time. However, I have not investigated this in detail.)

Like I've said, if you want new pseudorandom curves, nothing stopped you before and nothing's stopping you now - but: I don't think that's what the TLS WG asked us for; I don't think that's what anyone other than the Brainpool participants want; I don't think Brainpool needs our help to get the things it wants because it's already got them; I don't agree at all it's the best approach to take even in hardware, and; I don't think any further discussion on this point will bring our diametrically-opposed requirements into unison, it'll just delay matters and we don't want that.

I propose therefore, simply, that no changes need to be made to the curve criteria to accommodate the request of the Brainpool group. Let's move on from this.

>> …mandatory-to-implement anything is way out-of-scope here.
>Where did I suggest to make anything mandatory? I searched all my postings for "mandatory" without finding that source.

Um. It's… right there in the conclusions of the position paper you co-authored and linked here, Manfred.

"Requirements for Standard Elliptic Curves: Position of the ECC Brainpool", Cryptology ePrint Archive: Report 2014/832 <>:
>A potential compromise is the construction of new curves with similar properties as the Brainpool Curves, i.e., with verifiably pseudo-random primes, and make this set mandatory to implement.

I hope that clears that up for you. And as before, any mandatory agreement is not really within our gift to give, so that's not a compromise we can really make.

>To make it perfectly clear: If the group is going to only propose curves for two security-levels I'm opting for 128 and 192.

If 192 is strong enough, surely bigger ones would be stronger and also fine?

If 192 is not a good efficiency::security inflexion point, we'd probably rather choose another. If stronger ones are more efficient (and they are: Curve41417, Ed448-Goldilocks) we'd probably rather choose those, unless we can very clearly justify why 192, and not, say 256.

Why would you pick 192, in particular, given there are really no very good special primes in that area and, for example, AES-192 is seldom used? (secp384r1 and SHA-384 is only used anywhere because NSA Suite B picked it; even they couldn't get anyone who actually used AES-192.) This is, after all, the kind of thing meant by "rigidity": clear, justifiable, obvious reasoning, without arbitrary unexplained choices.

- --
Version: APG v1.1.1