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

Watson Ladd <watsonbladd@gmail.com> Tue, 27 January 2015 17:08 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 F40A91A889D for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 09:08:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 njI-vHwSD7Fb for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 09:08:08 -0800 (PST)
Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4671A8892 for <cfrg@irtf.org>; Tue, 27 Jan 2015 09:07:57 -0800 (PST)
Received: by mail-yh0-f44.google.com with SMTP id i57so6581666yha.3 for <cfrg@irtf.org>; Tue, 27 Jan 2015 09:07:56 -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=fWjVgriHEiMniu7WwcDbfIPGLk3NimMBhrqlW03Wq50=; b=Z+V8DZRXp/jB4qilkc/3qbpeg0gZJnnUW0AP4Ne0owfHjtSxRxlFidWhrLJy8baZlE BIjd+DEjFIk/UJxbdfaMlfRvKurdRulRCOSdta1DoAN0fJlWtwhniHV/jKcPt2Scxzph RdFSv+v1d381x4M1F9kePtvEB6t02lRObmsJYYZS/8c/hJGcMoY8QyzBuYZQk3Yi1SOT 8G44c0K6RMWzLgozTnpy8LzTYs60LNFDhaZG/KIgHME3s4YVpFbTFu6Gcjx8zXR8ja04 Q/k94GAl+n15VQCgZj8N36DSwZ4fJSRHIueLPbPV/iByz+lR1HVuIKtn/8DSY9NL1BXX EkvA==
MIME-Version: 1.0
X-Received: by 10.170.89.130 with SMTP id g124mr1567726yka.24.1422378476366; Tue, 27 Jan 2015 09:07:56 -0800 (PST)
Received: by 10.170.115.77 with HTTP; Tue, 27 Jan 2015 09:07:56 -0800 (PST)
In-Reply-To: <9ad11090808dc1e97bfc10196ad0e0c4.squirrel@www.trepanning.net>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF6839A@uxcn10-tdc05.UoA.auckland.ac.nz> <54C77376.3080005@cs.tcd.ie> <9ad11090808dc1e97bfc10196ad0e0c4.squirrel@www.trepanning.net>
Date: Tue, 27 Jan 2015 09:07:56 -0800
Message-ID: <CACsn0c=+uKicVmuex+jo5L6VQcJPLuQ45z3T1EZbSXMOrpy-=A@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/8jvMIGuKCd26dmszFiMavfnMB1U>
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "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: Tue, 27 Jan 2015 17:08:15 -0000

On Tue, Jan 27, 2015 at 8:41 AM, Dan Harkins <dharkins@lounge.org> wrote:
>
>
> On Tue, January 27, 2015 3:16 am, Stephen Farrell wrote:
>>>>
>>>> But seriously, if in fact this makes little or no difference, which I
>>>> believe
>>>> is the case, and which I believe you are also arguing, then what is the
>>>> problem with going with the initial coder's choice here?
>>>
>>> Because, as I've already pointed out in an earlier message, if the
>>> universal
>>> standard is big-endian and the vast majority of your potential user base
>>> (via
>>> OpenSSL, not sure about MS CryptoAPI) only does big-endian, then
>>> choosing a
>>> format that's not big-endian is a really bad idea.
>>
>> You didn't say why. Why is it a bad idea? What is the downside?
>> ("only does big-endian" isn't it clearly, because if the little
>> endian form were adopted here that'd no longer be true so the
>> question is how that'd cause problems if the spec called for it
>> to be done.)
>>
>> I'm really asking there and not point-scoring btw. mostly because I
>> think this entire process has been quite fraught about even the
>> least important things, and I'd hope we don't do that to ourselves
>> again;-)
>
>   It's a bad idea because standards like X9.62 and ISO/IEC 15946
> and RFC 5090 have all defined the way to go from a bitstring to an
> integer to a field element and back that involve representation in
> big endian. This is the canonical conversion between bit strings
> and elements.
>
>   And this is not some arbitrary issue that can just be relegated to
> the bowels of the crypto library where we no longer care. Knowledge
> of the special-case-ness of curve25519 will percolate up to the
> application writer. For instance,
>
>   * After doing an ECDH you take the X-coordinate and pass it to
>     a KDF. But how? Well, there's those rules to go from field element
>     to integer to bitstring. Except now you have to have a special case.
>     So you do BN_bn2bin() unless it's curve25519 then you do
>     BN_bn2binle() (which doesn't exist now for a very good reason).
>
>    * Or Imagine if someone wanted to implement Watson's SPAKE2 draft.
>     It involves hashing into an elliptic curve to get elements M and N.
>     So after you hash up a bunch of cruft you convert the digest as a bit
>     string into an integer and then into the X-coordinate of your element.
>     But how do you do that? Well you do BN_bin2bn() unless it's curve25519
>     and then you do BN_bin2bnle() (which does not exist now for a very
>     good reason).
>
>   This spells interop problems even if you just adopt DJB's code to
> handle curve25519. Special cases will be a continued source of trouble.

Curve25519 was specified as a function from 32 byte strings cross a
private key to 32 byte strings. There is no conversion from field
elements to strings before or after a Curve25519 calculation.

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.

>
>   And for what? At least Martin Luther had a list of grievances that he
> nailed to the church door to start his reformation. This particular attempt
> at reformation to free curves from the canonical format has none.
>
>   regards,
>
>   Dan.
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin