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

Alyssa Rowan <> Thu, 16 October 2014 17:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 00C7E1A19EE for <>; Thu, 16 Oct 2014 10:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hx5HQVDtEWfH for <>; Thu, 16 Oct 2014 10:38:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 102C41A0636 for <>; Thu, 16 Oct 2014 10:38:55 -0700 (PDT)
Message-ID: <>
Date: Thu, 16 Oct 2014 18:38:55 +0100
From: Alyssa Rowan <>
MIME-Version: 1.0
To: "" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
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: Thu, 16 Oct 2014 17:38:57 -0000

Hash: SHA512

On 16/10/2014 17:26, Johannes Merkle wrote:

> with respect to the second issue, we have just published a common
> position paper of the ECC Brainpool on the requirements for new
> curves. Most, if not all, arguments
> have been expressed on this list before, but this is a consolidated
> statement.

Upon a read, and paraphrasing broadly (feel free to correct), what the
Brainpool members seem to think meets the hardware scenario best is
curves over "verifiably pseudo-random" primes, with points represented
in short-Weierstrass form - because that matches best with their
existing "high-assurance" pieces of hardware and the ways that they
attempt to address attacks within them. They (naturally) want to
minimise any changes to that general structure, to in turn minimise
the costs of those changes.

I note that none of the concrete, implemented proposals put forward so
far are VPR. Do they have such a proposal?

They have, of course, already specified a set of verifiably
pseudo-random curves, which would be the Brainpool curves. I'm not
totally clear what CFRG can positively add to that, because they are
already specified. (An xkcd about competing standards springs to mind.)

It seems that they also want a VPR curve(s?) to be
mandatory-to-implement, presumably for interoperability's sake?

I can see why they might want that, if VPR is the most convenient for
their implementations - but from what I see from the hesitant adoption
of Brainpool in the wider community, I have serious (albeit early)
doubts that will reach wide consensus either here or in any downstream
WG, due I suspect directly to the notoriously poor software
performance characteristics of pseudo-random primes and the complexity
required to correctly implement them in software. (This will of course
be quantified during evaluation of any contender they put forward.)

It seems to me at this stage that the requirements of the
existing-hardware stakeholders of the Brainpool may be not only
orthogonal, but actually (potentially) in direct opposition to the
requirements of the software stakeholders - and further their
requirements may (perhaps) already be satisfied by the Brainpool curves?

- --