Re: [Cfrg] Point format endian

Derek Atkins <derek@ihtfp.com> Tue, 27 January 2015 16:12 UTC

Return-Path: <derek@ihtfp.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 D3D241A8876 for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 08:12:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3dpqQFDO76QJ for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 08:12:27 -0800 (PST)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572CC1A8831 for <cfrg@irtf.org>; Tue, 27 Jan 2015 08:12:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C8BB2E203F; Tue, 27 Jan 2015 11:12:25 -0500 (EST)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 14132-02; Tue, 27 Jan 2015 11:12:23 -0500 (EST)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id D54E1E2039; Tue, 27 Jan 2015 11:12:23 -0500 (EST)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t0RGCNvT009547; Tue, 27 Jan 2015 11:12:23 -0500
From: Derek Atkins <derek@ihtfp.com>
To: "Salz, Rich" <rsalz@akamai.com>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF68325@uxcn10-tdc05.UoA.auckland.ac.nz> <54C76EED.6090205@cs.tcd.ie> <sjm386wjko8.fsf@securerf.ihtfp.org> <b2b8d964885246748ebde894064b6a3c@ustx2ex-dag1mb2.msg.corp.akamai.com>
Date: Tue, 27 Jan 2015 11:12:22 -0500
In-Reply-To: <b2b8d964885246748ebde894064b6a3c@ustx2ex-dag1mb2.msg.corp.akamai.com> (Rich Salz's message of "Tue, 27 Jan 2015 15:46:28 +0000")
Message-ID: <sjmy4ooi4nt.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/q2v1nEKHbMtf5844_OD3HPO0CEI>
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "'cfrg@irtf.org'" <cfrg@irtf.org>
Subject: Re: [Cfrg] Point format endian
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 16:12:29 -0000

"Salz, Rich" <rsalz@akamai.com> writes:

>> It would mean a completely separate code path to support 25519 versus
>> supporting most (all?) existing ECC curves.
>
> Don't they have a different code path for the math implementation?

Maybe.  Maybe not.  A modmult is a modmult (to some degree).

> If the parsing/serialization special-code so onerous?  If so,
> shouldn't we have the Y coordinate?

Anything new and different is onerous.  ;-) It means additional work
in terms of implementation, testing, validation, and interop.

My point is that there's years (decades, even) of standards and
implementation that parse network-byte-order numbers, even when the
local system is little-endian.  I don't see a good reason to change
that.  The only real argument I've seen is "well, the initial
implementation didn't do it that way, and other people have therefore
not done it that way."

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant