Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)
Watson Ladd <watsonbladd@gmail.com> Wed, 28 January 2015 01:49 UTC
Return-Path: <watsonbladd@gmail.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 566741AC3D7 for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 17:49:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 mGG8zvUHr1oh for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 17:49:16 -0800 (PST)
Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6D01A9175 for <cfrg@irtf.org>; Tue, 27 Jan 2015 17:49:16 -0800 (PST)
Received: by mail-yh0-f46.google.com with SMTP id c41so7584076yho.5 for <cfrg@irtf.org>; Tue, 27 Jan 2015 17:49:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=80N5IZ9kJdeMBLOoGxvO40N5wvJ6TiCfNy7sJi0V7BE=; b=LGQojbByiOTknM6IOOygyRV97t1S7PF0nRuuFwQgp9q35ULi5wC+wSnRyX5IIPW8ES RpqkQrFZqW0tlkQVbSGcCOLFtoD+Z6ADcQOw/yVrSLgBMVIFV1CtZsLrfB9h8ypYA2Vk TOxptZs2dlwqJsxyjfQtqHmZ6DhGfTPyQFBha/ySAOWPpguJIDvqjo4CvZZ+gO6/FERW n0v+5LwJAj+1Olld2zzjqiIPEYjLeY5LlaVo7vmAoiKQBakWqOwHGPp71W2oCmgCI5Hc gStgIyDalbXJPcO3xVB7f/PS7BTOwrLBus7FVeaoaC5D5qBr0MT0VfsDtOzCmX+AQ/Qu jQzw==
MIME-Version: 1.0
X-Received: by 10.170.46.3 with SMTP id 3mr223469yko.24.1422409755417; Tue, 27 Jan 2015 17:49:15 -0800 (PST)
Received: by 10.170.115.77 with HTTP; Tue, 27 Jan 2015 17:49:15 -0800 (PST)
In-Reply-To: <4dbcfbff889d175765d549d96826767a.squirrel@www.trepanning.net>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF6839A@uxcn10-tdc05.UoA.auckland.ac.nz> <54C77376.3080005@cs.tcd.ie> <9ad11090808dc1e97bfc10196ad0e0c4.squirrel@www.trepanning.net> <CACsn0c=+uKicVmuex+jo5L6VQcJPLuQ45z3T1EZbSXMOrpy-=A@mail.gmail.com> <4dbcfbff889d175765d549d96826767a.squirrel@www.trepanning.net>
Date: Tue, 27 Jan 2015 17:49:15 -0800
Message-ID: <CACsn0cnFQhRrP=7oG+7eWKr_2+L+kNjGkXW0xHsdV5WLXsH1Tw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary="001a11437dca32659f050dac94dd"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/Cyk6ANheUVzgE0pKvN0Na2XtIOA>
Cc: "cfrg@irtf.org" <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: Wed, 28 Jan 2015 01:49:19 -0000
On Jan 27, 2015 9:30 AM, "Dan Harkins" <dharkins@lounge.org> wrote: > > > > On Tue, January 27, 2015 9:07 am, Watson Ladd wrote: > > > > My SPAKE2 draft contains specified M&N, generated by a C program > > Nathan McCullum sent me. I've been unable to determine what that > > program does in anything more than the vaguest terms because OpenSSL > > internals are opaque, but users do not need to generate their own > > points. > > Yes, it's opaque to you, the application writer. That's the point! But > to have curve25519 as a special case then you'd have to pry into the > opacity of the code and figure out what's going on. > > So to allow Nathan McCullum to send you a chunk of code that > should work with any curve supported by OpenSSL, and have it just > work without you knowing any opaque internals, it requires a > canonical conversion of bitstring to integer to field element and > back. > > If, as you say, users do not need to generate their own points then > they're gonna have to have a registry of M and N for all curves. And > to import a bitstring (for instance from the appendix of your draft) > into code requires converting that bitstring into an element. And > without the canonical conversion then you need to know about the > opaque internals. What makes you think I wouldn't write the point appropriately? More importantly, if this encoding was different for each curve, how would I notice, except when I generate the table? Every point has a representation either way. I can always do the calculation in PARI and reverse and pad the result. In fact, PARI only uses decimal IO so I have to convert anyway. I'm not insisting on decimal format to make my tools work. There is an encoding of x coordinates as 32 byte strings. The intent is that this encoding is used for everything having to do with Curve25519. Why is this such a large problem? At least with the Weierstrass coordinate on the wire proposal there was a clear rationale for the change in terms of compatibility. But this has nothing to do with compatibility: you will need to write new code anyway. Of course, it's not the case that there is a single universal key format. SEC1 serializes bignums as fixed-width in keys and variable width in signatures. PGP uses a different length encoding from TLS. Nor do all algorithms on words take the words the same way: MD5 uses a little-endian length encoding, and encodes the low byte first. SHA1 uses a big-endian length encoding and big-endian words. Furthermore, forcing applications to carry out encoding and decoding, instead of having the library do it has several bad effects. It makes it more complicated to use Curve25519. It prevents codesharing among libraries, unless they have identical bignum APIs. It makes applications non portable across libraries. Defining Curve25519 as a function of bigintegers was considered and rejected by multiple people due to interoperability problems historically caused by lack of canonical byte encodings: TLS DHE uses two distinct encodings at some point. What's wrong with the API everyone is already using? Sincerely, Watson Ladd > > Thank you for illustrating my point so well! > > Dan. > >
- 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