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

"Dan Harkins" <dharkins@lounge.org> Mon, 26 January 2015 06:31 UTC

Return-Path: <dharkins@lounge.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 7F3D91A1EFF for <cfrg@ietfa.amsl.com>; Sun, 25 Jan 2015 22:31:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 soEEQZfq6wOr for <cfrg@ietfa.amsl.com>; Sun, 25 Jan 2015 22:31:01 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1351A1BD7 for <cfrg@irtf.org>; Sun, 25 Jan 2015 22:31:01 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CABCB1022400A; Sun, 25 Jan 2015 22:31:00 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 25 Jan 2015 22:31:01 -0800 (PST)
Message-ID: <feba0d7b1ebb594574ecfd34cb836ad8.squirrel@www.trepanning.net>
In-Reply-To: <CACsn0c=bA=dRR8Y3vOp9o+Cmmdu7ZPr3vYbuRdBczRL2Uu+Gog@mail.gmail.com>
References: <20150125083018.10434.qmail@cr.yp.to> <93c73db0ce2b40c90324e89ce404abc1.squirrel@www.trepanning.net> <54C53542.60904@shiftleft.org> <CACsn0c=bA=dRR8Y3vOp9o+Cmmdu7ZPr3vYbuRdBczRL2Uu+Gog@mail.gmail.com>
Date: Sun, 25 Jan 2015 22:31:01 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Watson Ladd" <watsonbladd@gmail.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/nAdV_KQmP15wZHR7W8i3Dd_ys8s>
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: Mon, 26 Jan 2015 06:31:02 -0000

On Sun, January 25, 2015 12:35 pm, Watson Ladd wrote:
> On Sun, Jan 25, 2015 at 10:26 AM, Mike Hamburg <mike@shiftleft.org>; wrote:
>> I think that this is actually an interesting question, so maybewe can
>> put aside religion and mockery thereof for little bit...
>>
>> 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.

  Yes Mike, there are numerous crypto libraries, both open source and
proprietary, that use a generic bignum package. And it is that "might be
worth considering" that is making me raise this issue.

> Both NSS and OpenSSL have a bignum library underlying ECC operations,
> but I don't know how often that gets used in practice vs per curve
> optimized implementations. But we're talking about swapping bytes in a
> serialization function: it's a potential wart, but a small one. If we
> do reverse endianness, then what SSH is already doing won't be
> included.

  Warts are ugly. And if small warts are not a concern then let's just
leave SSH with a wart and everyone else can be wart-free.

> The fact that actual developers making actual projects don't consider
> this a problem should register.

  Well this actual developer making actual projects considers this a
problem. The argument from Rich is that he's OK with curve25519
being a special case because of he wants to interop with some existing
implementations. And I guess that's the difference. Aside from SSH
(which will have "a potential ward, but a small one") I don't see
a large number of protocols implemented with this format that
make this change compelling.

  Dan.