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

Alyssa Rowan <akr@akr.io> Thu, 16 October 2014 17:38 UTC

Return-Path: <akr@akr.io>
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 00C7E1A19EE for <cfrg@ietfa.amsl.com>; Thu, 16 Oct 2014 10:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx5HQVDtEWfH for <cfrg@ietfa.amsl.com>; Thu, 16 Oct 2014 10:38:55 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102C41A0636 for <cfrg@irtf.org>; Thu, 16 Oct 2014 10:38:55 -0700 (PDT)
Message-ID: <544002AF.1020107@akr.io>
Date: Thu, 16 Oct 2014 18:38:55 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
References: <D065A817.30406%kenny.paterson@rhul.ac.uk> <543FF1A7.8030908@secunet.com>
In-Reply-To: <543FF1A7.8030908@secunet.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/a3bVmrsfU6GVxunHvwUrhAU05qA
Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?)
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, 16 Oct 2014 17:38:57 -0000

-----BEGIN PGP SIGNED MESSAGE-----
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. http://eprint.iacr.org/2014/832 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?

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUQAKuAAoJEOyEjtkWi2t62L4P+gLx6CZ0GJ5+6KYdeK3eA9Dd
keqBpZjlR25r74sdtqufUZaPH8AgB2q0QGX2evQKXWZj5cDblpwq1dVFk1o17wtZ
k+3C8wdtavENvCHPaFsRoQYferk33HLRhj1jw7M69BJo5HTEerImySANDAosNOpD
0dj+axICdfZ2GH0NvKScBN/gFZvUOj197SxDH+eVdy3g5HL52gUd4HAN17ZWSysG
kwG9MRHtTkKndO4JTLxiFCTX3DWFRXVIrUBCucJnvPDC0Rlsrgk0lLBiGHKLYhJR
bwdnBxuyijnzGmOjrRanZOCCIFoq05BtmwxbGGkA5BmCbTPwcLTltd9+doCihCYb
UDPfTZ5GvDaGhq6sUmUbPZnay1gvGIO18nyzxZXINkBanENQnE/Ofa2cdr0Ps9DN
40N0bcobbuaila6v/497a0krAp9D7aQ5JFN4swI5DYicpuYVDl0nOK63bRPTY+e+
gk4AKRB4gpVodU/O0a3tACvGwD7E/vf3qNbgrkqHHwXzhzhWebCRB9xtUpikbeEv
/R5yhCSFFXJ4DJB9oMi+kJjG+VmgdC3vOzN0Tra19Pq+znLYe4lFOTqZ/EX+S3Ql
Ua/hWfvmJyvXRe9mZt/dRjwj8GeHgRGlEnvcEjXvdmevuw5TAtZrJrBLjMfWFPNO
wKHWHyo/P4Rj3NQ3NfOl
=i8MQ
-----END PGP SIGNATURE-----