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

Andrey Jivsov <crypto@brainhub.org> Sun, 25 January 2015 20:51 UTC

Return-Path: <crypto@brainhub.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 E6E281A6FE9 for <cfrg@ietfa.amsl.com>; Sun, 25 Jan 2015 12:51:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 bcWkB2JSeMqg for <cfrg@ietfa.amsl.com>; Sun, 25 Jan 2015 12:51:19 -0800 (PST)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D703C1A6F3B for <cfrg@irtf.org>; Sun, 25 Jan 2015 12:51:18 -0800 (PST)
Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-10v.sys.comcast.net with comcast id kLrG1p0012Udklx01LrHAS; Sun, 25 Jan 2015 20:51:17 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-ch2-18v.sys.comcast.net with comcast id kLrG1p00T4uhcbK01LrHxM; Sun, 25 Jan 2015 20:51:17 +0000
Message-ID: <54C55744.5020908@brainhub.org>
Date: Sun, 25 Jan 2015 12:51:16 -0800
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <20150125083018.10434.qmail@cr.yp.to> <93c73db0ce2b40c90324e89ce404abc1.squirrel@www.trepanning.net> <54C53542.60904@shiftleft.org> <d8fa5b9cc371411fbea460b1cd042fe0@usma1ex-dag1mb2.msg.corp.akamai.com>
In-Reply-To: <d8fa5b9cc371411fbea460b1cd042fe0@usma1ex-dag1mb2.msg.corp.akamai.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1422219077; bh=lAo0lxlhyy4i05aSES30MsACGNP0pnpHoRZWpvLBPSU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bqJa0V8Sqm4NMmWNkBTrg9y2dJyEEV3TUyP+VqJ+ghFBO38e7detC9dK11VldLaxR oVNqQsA86ZmdsQuLKkWv3nGb5N/jmg/z4LBqALiQLOChkhEw/3e1TMlMlJR1zmXwV/ YJhf5J0o80PDZmmo3jjhy360ZcVmjIvC1cKmpaJQl6aoEu1nL2Lv9f5HaCE+7GlMxB fvTw5Sr+yFgdKlGvlAnkEuOSLdME+gPNGy2JG5FUOkaeOHgxgWSGgD1d+jBXRWzXJq hr5UQ09NgKJodjYBsTBQm1Pwqt6+gkUuMh/yXyjQay18m0yRkG6wofDrqrbbdEQhkb Ikmz7ygCl+KGw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/HD5kdScZDoY8K7Qsa8G4wcR5EzA>
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: Sun, 25 Jan 2015 20:51:21 -0000

On 01/25/2015 11:47 AM, Salz, Rich wrote:
> OpenSSL.  I'm on the dev team.  But we want the interop and efficiency of the X25519 defined wire rep.

I don't have strong opinion regarding the format, primarily because 
there is no efficiency argument here.

If you consider Curve25519, the two implemetnations I looked at 
curve25519-donna and more optimized X25519 from 
http://www.ietf.org/mail-archive/web/cfrg/current/msg05247.html unpack 
the public values byte-by-byte. An implementation with delayed reduction 
will have uneven boundaries between wire format and an internal 
representation, and so this is expected.

It would be trivial to tweak the implementation to assign input bytes to 
different target positions (and use different constants in shifts) for 
identical performance / code size.

If an implementation does something like 4-to-4, or 8-to-8 mapping, most 
platforms, x86 in particular, have instructions like bswap to take care 
of this.

Is there evidence that matching endianess has any performance impact?