[Cfrg] big-endian short-Weierstrass please

Dan Brown <dbrown@certicom.com> Tue, 27 January 2015 15:43 UTC

Return-Path: <dbrown@certicom.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 7AE011A8957 for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 07:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id p0vXPoIJVhRn for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 07:43:42 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3C02B1A885A for <cfrg@irtf.org>; Tue, 27 Jan 2015 07:42:09 -0800 (PST)
Received: from xct106cnc.rim.net ([]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 Jan 2015 10:41:50 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0210.002; Tue, 27 Jan 2015 10:41:50 -0500
From: Dan Brown <dbrown@certicom.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: big-endian short-Weierstrass please
Thread-Index: AdA6QfeHnVWfJGNlTzek7rmrn4E15g==
Date: Tue, 27 Jan 2015 15:41:50 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5D42BDA@XMB116CNC.rim.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0010_01D03A1D.DB352460"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/2cMNhxWDMjvCvcHcUvtiGe8l-jU>
Subject: [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: Tue, 27 Jan 2015 15:43:45 -0000

Dear CFRG,


IEEE 1363-2000, ANSI X9, NIST 800-56A and SEC1 use 


#10) short-Weierstrass representation for EC points, which is nice because
any elliptic curve, including the latest and greatest, can be represented in
this form, and 

#01) big-endian (MSB-first) octet string representation for prime-field
elements, which is admittedly somewhat arbitrary (with no effect on
security) although somewhat consistent with various old-fashioned notations
for numbers

#11) KDFs based on hash functions SHA1 and SHA2 which are kind of big-endian


If raw Curve25519 implementations operate on input and outputs of byte
strings, in whatever order and curve shape, then it shouldn't be too hard
for applications using the raw Curve25519 implementation to shift the
input/output coordinates from/to short Weierstrass (yes, one has to choose
the a-value for this), and then unsort/sort the octets into MSB-first order


I appreciate that currently, TLS is thinking to use Curve25519 a named
curve, specified by an OID, and then determine all point representations,
including the internal used ones used in the KDF and signatures, based on
the named curve.  That should work too for TLS and any easily updatable


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.


Best regards,


Daniel Brown

Research In Motion Limited