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

Damien Miller <djm@mindrot.org> Mon, 26 January 2015 03:55 UTC

Return-Path: <djm@mindrot.org>
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 57E4D1A1A90 for <cfrg@ietfa.amsl.com>; Sun, 25 Jan 2015 19:55:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level:
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 VUaHAG9g27_J for <cfrg@ietfa.amsl.com>; Sun, 25 Jan 2015 19:55:55 -0800 (PST)
Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by ietfa.amsl.com (Postfix) with ESMTP id CF6591A1B2B for <cfrg@irtf.org>; Sun, 25 Jan 2015 19:55:54 -0800 (PST)
Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id t0Q3tqH7025312; Mon, 26 Jan 2015 13:55:52 +1000
Received: from mailhub.eait.uq.edu.au (taxus.eait.uq.edu.au [130.102.79.56]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id t0Q3tqg4019291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Jan 2015 13:55:52 +1000
Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.14.6/8.14.6) with ESMTP id t0Q3toFn014752; Mon, 26 Jan 2015 13:55:51 +1000 (EST)
Received: by natsu.mindrot.org (Postfix, from userid 1000) id 9FE03A4F08; Mon, 26 Jan 2015 14:55:50 +1100 (EST)
Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 9A886A4F07; Mon, 26 Jan 2015 14:55:50 +1100 (EST)
Date: Mon, 26 Jan 2015 14:55:50 +1100 (EST)
From: Damien Miller <djm@mindrot.org>
To: Mike Hamburg <mike@shiftleft.org>
In-Reply-To: <54C53542.60904@shiftleft.org>
Message-ID: <alpine.BSO.2.11.1501261450170.14751@natsu.mindrot.org>
References: <20150125083018.10434.qmail@cr.yp.to> <93c73db0ce2b40c90324e89ce404abc1.squirrel@www.trepanning.net> <54C53542.60904@shiftleft.org>
User-Agent: Alpine 2.11 (BSO 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub
X-Scanned-By: MIMEDefang 2.73 on 130.102.79.56
X-UQ-FilterTime: 1422244553
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/L37T4V_DSyT0LDKW89zBoXkI1DU>
Cc: cfrg@irtf.org
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: Mon, 26 Jan 2015 03:55:57 -0000

On Sun, 25 Jan 2015, Mike Hamburg wrote:

> I think that this is actually an interesting question, so maybewe can
> put aside religion and mockery thereof for little bit...
>
> Does anyone know of existing code which processes cryptography over
> multiple fields using a generic bignums package (hopefully with
> fixed-size bignums for timing resistance), and would be complicated by
> inconsistent endian practices in a new curve? If so, it might be worth
> considering a consistent endian.

We (OpenSSH) adopted the little-endian encoding from djb's ECDH
curve25519 and Ed25519 as specified despite all other SSH wire bignums
being encoded as big endian. We were happy to be able to use the
existing high quality and well-reviewed implementations. This more than
justified the small inconsistency.

The inconsistency is really just minor aesthetics - the wire values
are opaque to everything but the implementation of the primitives
themselves; it doesn't matter to the application at all.

-d