Re: [Cfrg] big-endian short-Weierstrass please

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 28 January 2015 18:48 UTC

Return-Path: <dkg@fifthhorseman.net>
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 803F31A1AC6 for <cfrg@ietfa.amsl.com>; Wed, 28 Jan 2015 10:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 zI3IcPibdiB4 for <cfrg@ietfa.amsl.com>; Wed, 28 Jan 2015 10:48:48 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A71111A1A22 for <cfrg@irtf.org>; Wed, 28 Jan 2015 10:48:48 -0800 (PST)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 40785F984 for <cfrg@irtf.org>; Wed, 28 Jan 2015 13:48:45 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 3872A203A0; Wed, 28 Jan 2015 13:48:44 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: cfrg@irtf.org
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5D42BDA@XMB116CNC.rim.net>
References: <810C31990B57ED40B2062BA10D43FBF5D42BDA@XMB116CNC.rim.net>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Wed, 28 Jan 2015 13:48:44 -0500
Message-ID: <87386ug2r7.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/f_MdN5IG5QweCRbXqZVeQ40DcZA>
Subject: Re: [Cfrg] big-endian short-Weierstrass please
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: Wed, 28 Jan 2015 18:48:50 -0000

On Tue 2015-01-27 10:41:50 -0500, Dan Brown wrote:
> But I wonder if there are any old implementations of the standards I listed
> above, that accept generic specified short Weierstrass curves, but lock
> together the KDF and raw ECDH operations.  Users stuck with such
> implementations couldn't gain _all_ the benefits of Curve25519, side channel
> resistance or whatever, but surely there's some residual benefits for them
> to use Curve25519 with a generic representation: maybe the rigidity
> Curve25519, or interoperability with other users with the newfangled
> software, not to mention the blessing of the collective wisdom of CFRG.  
>
> If the argument is that no such implementations could exist, or that the
> implementations, or even old ECC standards, are so bad that we should try to
> discourage interoperability, then please present that case.

It sounds to me like you're presenting a choice between two options for
the CFRG:

 0) help more people move to better curves, without moving anyone to
    better algorithms or requiring anyone to move to better
    implementations.

 1) Allow people who can move to better algorithms, implementations, and
    curves to do so in one step, while leaving people with brittle
    software behind if the new system is adopted in exclusion to the
    old.

It seems like the answer to this would be governed by your perception of
(a) existing curves compared algorithms and implementations, and (b) how
you expect the rollout+deprecation process to happen, but even
considering both of these choices independently, it seems like (1) is
better.

Curves vs. Algorithms and Implementations
=========================================

If you feel that the existing curves themselves are the main source of
concern, but not the algorithms and implementations, you might lean a
little bit toward (0).  However, there seems to be a general consensus
that existing implemetations and algorithms themselves are problematic
-- for example, libraries like OpenSSL have rewritten their P-256
implementations in the last year, and deterministic signature mechanisms
are clearly better than traditional ECDSA.  So (1) is more appealing --
if we can fix more things during this transition, we should fix them.

Rollout and Deprecation
=======================

There is existing code that is never going to change.  There is existing
code that can be minorly changed by tweaked parameters.  And there is
existing code that can be easily, fully upgraded.

The first group is never going to disappear, and unfortuately, members
of that group might be too important for every tool to just ignore the
group entirely (consider systems that want to talk to home routers or
networked printers, or systems that are only willing to use NIST
curves).  So tools that require backward compatibility that covers these
systems will need to have some level of fallback interoperability to
existing practice in both curves and algorithms.

But if we're going to have the fallback to existing practice anyway, we
can also use that to cover those implementations that can only accept
minor changes.

(1) seems like the better option to me, from an overall ecological point
of view.  Let's take advantage of this transition time to include
important fixes in all areas, for those who can make them.




As for byte-ordering: higher levels of abstraction (both on the wire and
logically) all prefer fixed-length bitstrings anyway.  So that's the
interface that we should use for the primitive.  We should declare
something explicit so that libraries know what to produce to get
canonical bitstrings, and move on.  Little-endian is fine.

Regards,

       --dkg