[Cfrg] Alternatives to rigidity?

Tony Arcieri <bascule@gmail.com> Thu, 01 January 2015 01:13 UTC

Return-Path: <bascule@gmail.com>
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 D41DD1A1B1A for <cfrg@ietfa.amsl.com>; Wed, 31 Dec 2014 17:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 1v23qxSXEivj for <cfrg@ietfa.amsl.com>; Wed, 31 Dec 2014 17:13:01 -0800 (PST)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C861A1AF9 for <cfrg@irtf.org>; Wed, 31 Dec 2014 17:13:01 -0800 (PST)
Received: by mail-oi0-f52.google.com with SMTP id a3so6581750oib.11 for <cfrg@irtf.org>; Wed, 31 Dec 2014 17:13:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=yeKz6xA46D3AtxIAvyaOjTZpiSTenZ+zfnSTeUnvnfw=; b=z8XPWa5mWrQIRfytwAtb5A92xXlWiqPIPloSlbX9ih/kLIaC4IihMQLsm5wYwFiQhx SUZ1nbyyiYMvdpgLNnEeoL4DU3pyXYpiqk3jZbwKlydckE+ZifoYw8hM2bpYOvl2520v 8eE+wsf0WHfpU6hg+mwqws0UI/d2YVTyE2kRpgkyrjRdSa26zLtktzs8hgN2DGfv9oTb 7HeA924dhe8+HbIKaUH9EI0vhxqJIAzzKN7kHomRNjohJy7p2WHkqba5jS2kqp9nV++M 6ZvMPR+8vb8RmNjZg4gFDLMzkvaLVM2+GC2VPk6lrlHhDs0HnnKRwe/E2AFQsnaBGWRv e5Cg==
X-Received: by 10.182.211.70 with SMTP id na6mr40879652obc.13.1420074780283; Wed, 31 Dec 2014 17:13:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.227.225 with HTTP; Wed, 31 Dec 2014 17:12:40 -0800 (PST)
From: Tony Arcieri <bascule@gmail.com>
Date: Wed, 31 Dec 2014 17:12:40 -0800
Message-ID: <CAHOTMVLrThLThuHP_U6idVCJCGEJSSOkS-71HOPo3mSLQUGcUw@mail.gmail.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary=e89a8f838df7d55a3e050b8cec61
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/VMxmlQQWCBOu5NTem_pn2tFjAaA
Subject: [Cfrg] Alternatives to rigidity?
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, 01 Jan 2015 01:13:04 -0000

It seems the purpose of proposed "rigid" curve generation guidelines is to
produce so-called "nothing up my sleeve" curves, i.e. curves we are
confident haven't been tampered with to reduce security because we assume
we can create an algorithm to pick good curves.

However it seems there are differing opinions on what constitutes rigidity,
e.g. the Ben Black draft vs:

http://safecurves.cr.yp.to/rigid.html

Instead of trying to come up with constraints to generate curves de novo,
why not judge curves on the merits of how they were generated and what
known properties they hold? The SafeCurves web site lays out a rubric for
doing this:

http://safecurves.cr.yp.to/

Surely people would want to bikeshed this rubric, but isn't it a good start?

It also seems like the most important thing is producing a performant safe
curve. Some promising ones seem to be:

- Curve25519
- Ed448-Goldilocks
- Ilari's 2^389-21 curve

There are certainly others, but the above seem to perform well.

My take is that the CFRG is otherwise deadlocked, and the central issue
seems to be the trustworthiness of curves. However, at least as far as I
can gather from the crypto community, Curve25519 is widely accepted and
nobody (except Microsoft?) is questioning that.

There are certainly other questions like a signature algorithm, but even
there I think EdDSA is widely accepted, and performs well too.

I guess my main question is: does anyone else care about rigidity (as
defined by Ben Black) except Microsoft and if not, should the CFRG just
punt on it and pick some curves everyone else considers non-controversial?

-- 
Tony Arcieri