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 10:35 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 A03261A8766 for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 02:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Level:
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 rMIYfCXrx48K for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 02:35:05 -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 B625C1A8738 for <cfrg@irtf.org>; Tue, 27 Jan 2015 02:35:01 -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=1422354905; x=1453890905; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=EImqITEcIztAgYHdsn6UGl8h50Ku4nyMMWK4ohUFNn8=; b=rjDAvSicN4wBY+kVZJ/SKvMkTI/R2Dm5ETXNLIvNLD9goOR2YR3cLqwP /xGxRaVP0WxVRXkSN9yqIF3AeGdTba/+edGBotweC6EoW0mlchQRntXCL k9r9ggJcgA/i8pB24L2R68k4RvwFoN0+2FVYgJHDvjHBAjv4zROjz3CS7 U=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="303896679"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Jan 2015 23:34:59 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 27 Jan 2015 23:34:59 +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: AdA6HOWyc3EIrAHPSf+7q6EEIfAl2Q==
Date: Tue, 27 Jan 2015 10:34:58 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF68325@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/CHE1iKRWSLuWH4RLUibItTbwY7M>
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 10:35:07 -0000
Michael Clark <michael@metaparadigm.com> writes: >This code could do with some optimization, bswap(32|64) intrinsic (uses BSWAP >machine instruction on x86_64, ARM, etc), working with a machine word size >loop with a small tail loop to handle the modulus of the difference in length >of the bignum from the machine word size. It is working byte by byte. This is another example of "I can't believe we're having this discussion". We're talking about bignum operations measured in the millions of CPU cycles (a basic 1024-bit RSA decrypt is about 10M cycles, with P256 it's 7M cycles, courtesy of the Crypto++ benchmark data) and you're bringing up optimising something that might take a few hundred cycles (ignoring memory latency overhead, which is going to hit you at some point whether you endian-reverse or not). The issue isn't about whether a 0.001% overhead is worth applying custom architecture-specific assembly-language to eliminate, it's the issue of encoding a particular implementation artefact into a standard. As djb has helpfully pointed out, he could have decided to encode the values as ASCII decimal digits, or perhaps doodles, sign language, and squirrel noises. Would crypto standards then require that everything using 25519 be able to encode the output as squirrel noises just because that's what one implementation does? The universal standard for crypto bignums is big-endian (things like curve25519-sha256@libssh.org aren't a standard, it's what one implementation chooses to do). The 25519 form is an implementation artefact and should have no place in a standard. Peter.
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Brown
- Re: [Cfrg] Point format endian (was: Adoption of … Peter Gutmann
- Re: [Cfrg] Point format endian (was: Adoption of … Alyssa Rowan
- Re: [Cfrg] Point format endian (was: Adoption of … Alyssa Rowan
- Re: [Cfrg] Point format endian (was: Adoption of … Michael Clark
- Re: [Cfrg] Point format endian (was: Adoption of … Michael Clark
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … Michael Clark
- Re: [Cfrg] Point format endian (was: Adoption of … Peter Gutmann
- Re: [Cfrg] Point format endian (was: Adoption of … Stephen Farrell
- Re: [Cfrg] Point format endian (was: Adoption of … Peter Gutmann
- Re: [Cfrg] Point format endian (was: Adoption of … Alyssa Rowan
- Re: [Cfrg] Point format endian (was: Adoption of … Stephen Farrell
- Re: [Cfrg] Point format endian (was: Adoption of … Peter Gutmann
- Re: [Cfrg] Point format endian (was: Adoption of … Stephen Farrell
- Re: [Cfrg] Point format endian (was: Adoption of … Salz, Rich
- Re: [Cfrg] Point format endian Derek Atkins
- Re: [Cfrg] Point format endian Salz, Rich
- Re: [Cfrg] Point format endian Stephen Farrell
- Re: [Cfrg] Point format endian Paul Hoffman
- Re: [Cfrg] Point format endian Derek Atkins
- Re: [Cfrg] Point format endian Derek Atkins
- Re: [Cfrg] Point format endian Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] Point format endian Paul Hoffman
- Re: [Cfrg] Point format endian Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Harkins
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … Andy Lutomirski
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Harkins
- Re: [Cfrg] Point format endian (was: Adoption of … Stephen Farrell
- Re: [Cfrg] Point format endian Tony Arcieri
- Re: [Cfrg] Point format endian (was: Adoption of … Michael Clark
- Re: [Cfrg] Point format endian Damien Miller
- Re: [Cfrg] Point format endian Phillip Hallam-Baker
- Re: [Cfrg] Point format endian Phillip Hallam-Baker
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … D. J. Bernstein
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Harkins
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd