[Cfrg] Criteria for the selection of new ECC mechanisms

David McGrew <mcgrew@cisco.com> Tue, 29 April 2014 14:37 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C131D1A04AC for <cfrg@ietfa.amsl.com>; Tue, 29 Apr 2014 07:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.152
X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9ku16cUT8x12 for <cfrg@ietfa.amsl.com>; Tue, 29 Apr 2014 07:37:33 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 44E021A0908 for <cfrg@irtf.org>; Tue, 29 Apr 2014 07:37:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3311; q=dns/txt; s=iport; t=1398782249; x=1399991849; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=BYKVd4dFGZqObJafvK3mGfTgIiREgKQudxajXGrCeL0=; b=eEcBZFHb8YohKFgWjzKIftJ7HOVLlpGl0iFsekTKr8apvuODd2KwFXVC eNcqebh4t6u3dDdH/d1fcgLCFGiUKhg70+fzf35W5lac4ETtA+Vj/N++F B0ZZ4xCCMgRbBfevv+GtzZupqZ4+62jH1Oeb19HqKCp+26/xGtVmoWd17 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.97,951,1389744000"; d="scan'208";a="39690279"
Received: from rcdn-core-5.cisco.com ([]) by alln-iport-8.cisco.com with ESMTP; 29 Apr 2014 14:37:28 +0000
Received: from [] (rtp-mcgrew-8913.cisco.com []) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3TEbRHv016076 for <cfrg@irtf.org>; Tue, 29 Apr 2014 14:37:27 GMT
Message-ID: <535FB927.8080909@cisco.com>
Date: Tue, 29 Apr 2014 10:37:27 -0400
From: David McGrew <mcgrew@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/5HqjPeqU0pFoU7P8QWiIC6X4LEc
Subject: [Cfrg] Criteria for the selection of new ECC mechanisms
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: Tue, 29 Apr 2014 14:37:34 -0000


in order to frame the discussion in today's meeting, I wrote up criteria 
for new ECC mechanisms.  I will go over this briefly in today's 
meeting.   Hopefully, this will foster good understanding about what the 
important goals are, and a good discussion about how to meet our common 
goals.  Comments are welcome, especially when they come with suggested 
text and a reference, where appropriate.



Criteria for the selection of new ECC mechanisms
David McGrew
April 28, 2014

This short note summaries the criteria that have been put forward for
new ECC mechanisms, using the requirements language typical of
standards processes.  Each criterion is identified as either required
(strictly necessary) or desired (not strictly necessary, but strongly
appealing).  Some criteria apply only to key exchange methods (and not
to signatures) or Password Authenticated Key Exchange (PAKE), and are
labeled as such.  The Safecurves web page is an outstanding resource
for security criteria, though it does not distinguish between
properties that are essential for key exchange and those for
signatures.  Sources are described in footnotes; this note aims to be
objective, but the author's opinion is reflected in some choices.

The following criteria have been identified:


    R1.  Desired: easy to understand and implement [1]


    R2.  Required: amenable to compact implementations and fast
    implementations, across both small and large processors [1]

    R3.  Desired: re-use components between signatures and key exchange
    algorithms [3]

Intellectual Property

    R4.  Required: available worldwide under reasonable and well
    understood licensing terms [1]

    R5.  Desired: available worldwide under royalty-free licensing
    terms [1]


    R6.  Desired: can be used with current software implementations
    (using different curve parameters) of TLS, PKIX, SSH, and IKE [4]

    R7.  Desired: can be used within current ECC standards of TLS,
    PKIX, SSH, and IKE [4]


    R8.  Required: amenable to constant-time implementations, to avoid
    side channel attacks [2]

    R9.  Required: resist twist attacks [2]

    R10.  Required: curve parameters should have good provenance;
    random curves should be provably pseudorandom [5]

    R11.  Desired for key exchange: resist invalid curve attacks [2];
    note that complete addition laws help and are thus desirable [2].
    (Note that the use of ephemeral keys also resist such attacks.)

    R12.  Required for PAKE: indistinguishability of curve points from
    random strings [2]


    [1] Original criteria set out for the Advanced Encryption Standard,
        which is equally applicable to ECC.  National Institute of
        Standards and Technology (NIST) of the United States, 1998.

    [2] Daniel J. Bernstein and Tanja Lange. SafeCurves: choosing safe
        curves for elliptic-curve cryptography.
        http://safecurves.cr.yp.to, accessed April 2014.

    [3] Criteria identified by David McGrew, 2014.

    [4] Criteria identified by Russ Housley, TLS WG meeting at IETF89.

    [5] Criteria widely acknowledged on CFRG email list during 2014.