Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 27 January 2015 11:45 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 E751A1A876C for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 03:45:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 xWcy17PebD_Q for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 03:44:59 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28191A877B for <cfrg@irtf.org>; Tue, 27 Jan 2015 03:44:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1422359099; x=1453895099; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=P8sz828DmydjIQwvhcD0ims0lFms5iH6ridj57tIEi8=; b=q9YTIQCLvwhAZrdd4Pj+C9DY2EHCeMlmbtuw8OJKseo7D+QvLk5lIXNx M4jh9zkcSgL/CICV4KqWXax/txv57lZEQ17tOj11caQSKYelcSa1QLJdq 8PARl1BV2ViFIEGzfAIHSvGraaUeWjW8ZEsz/1xRHpdsx7bjFLMOPD4C1 o=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="303901618"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 Jan 2015 00:44:54 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 28 Jan 2015 00:44:47 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "'cfrg@irtf.org'" <cfrg@irtf.org>
Thread-Topic: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)
Thread-Index: AdA6JqZyE82jbGIkR3GvMKslgwBkuA==
Date: Tue, 27 Jan 2015 11:44:46 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF683E5@uxcn10-tdc05.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/0OwPSNHpx-sppW3ZCJdQIUko7Co>
Subject: Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)
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 11:45:01 -0000

Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:

>You didn't say why. Why is it a bad idea? What is the downside?

The fact that it's one more piece of special-case code to add, debug, and test
when we've already got perfectly-functional, debugged, and tested code, some
of it in active use for twenty years or more, to do it present everywhere that
uses bignums.

(Another issue is that using a nonstandard form for representing the values is
bound to cause interop problems in the future when the 25519 form is the
opposite to what everything else does.  Look at the mess that occurred during
the AES competition with different endiannesses used in various algorithms,
until the problems were pointed out at the second AES conference by someone
who'd actually implemented things from the spec ("Implementation Experience
with AES Candidate Algorithms") and NIST revised the requirements).

If the "spec" for 25519 is going to be "the standard is to blindly do whatever
djb's code does" then there's no need for a spec or any CFRG involvement, just
provide a link to djb's code, since that'll be the spec.  It's decent code,
I'm not complaining about it, but the CFRG shouldn't be pretending to be
setting any standard if it's just "do whatever this code happens to do".  The
code then becomes the spec.

Peter.