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

Dan Brown <dbrown@certicom.com> Sun, 25 January 2015 20:52 UTC

Return-Path: <dbrown@certicom.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 A0B041A6F3B for <cfrg@ietfa.amsl.com>; Sun, 25 Jan 2015 12:52:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6] autolearn=no
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 Ktr4KW9wtfV6 for <cfrg@ietfa.amsl.com>; Sun, 25 Jan 2015 12:52:18 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 49DDA1A1AD2 for <cfrg@irtf.org>; Sun, 25 Jan 2015 12:52:18 -0800 (PST)
Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 25 Jan 2015 15:52:08 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0210.002; Sun, 25 Jan 2015 15:52:07 -0500
From: Dan Brown <dbrown@certicom.com>
To: "Salz, Rich" <rsalz@akamai.com>, Mike Hamburg <mike@shiftleft.org>, "Dan Harkins" <dharkins@lounge.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)
Thread-Index: AdA44MccVw2g3MTa2EaapRh3VZJptg==
Date: Sun, 25 Jan 2015 20:52:06 +0000
Message-ID: <20150125205204.6639764.45436.25432@certicom.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1944662354=="
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/KvvCmCkLh-SAfRGDdPjhQjRzXxw>
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:52:19 -0000

Endianess also matters for the ECDH shared secret and signature point to integer, or point to byte string, conversion, not just wire format, right? 

The internal op formats seem more important than wire format it since cannot be fixed by an external wrapper that translates formats, and it deals with secrets, so needs side channel security, etc.

For interoperability, an implementation of generic short Weierstrass  ECDH would need to know what shared secret endianness is needed, if it were to try to operate with a new format Curve25519 ECDH public key that has been translated by some kind of wrapper. Maybe we don't need or want this kind of backwards interop?

Network order maybe makes sense for plaintext numerics, to allow more rapid response than even throughput, but for crypto bignums, I don't see this as applicable: usually the whole big num is essential. My vague understanding is that most crypto standards only followed network order‎ for wire format in order to fit in (tradition) , and then just used the same order for internal conversions, to avoid having two different formats.

 

Best regards, 

-- Dan
  Original Message  
From: Salz, Rich
Sent: Sunday, January 25, 2015 2:48 PM
To: Mike Hamburg; Dan Harkins; cfrg@irtf.org
Subject: Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)


> 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.

OpenSSL. I'm on the dev team. But we want the interop and efficiency of the X25519 defined wire rep.

I apologize if I offended anyone (esp Dan)by my note. I don't find tradition a compelling argument. Especially since for X25519, you just do a buffer-copy from the network buffer into the crypto buffer. Much less work.

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg