Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)
Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 27 January 2015 11:59 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 27CFE1A87AB for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 03:59:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 DHGSiWTtPqkN for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 03:59:29 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAB41A876C for <cfrg@irtf.org>; Tue, 27 Jan 2015 03:59:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 01383BE8F; Tue, 27 Jan 2015 11:59:28 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU_F-K9Nr1ZZ; Tue, 27 Jan 2015 11:59:27 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D2F12BE87; Tue, 27 Jan 2015 11:59:27 +0000 (GMT)
Message-ID: <54C77DA0.7000603@cs.tcd.ie>
Date: Tue, 27 Jan 2015 11:59:28 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "'cfrg@irtf.org'" <cfrg@irtf.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF683E5@uxcn10-tdc05.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF683E5@uxcn10-tdc05.UoA.auckland.ac.nz>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/8St-M6-gIpXxEB-LMK0Ykj2tCSE>
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 11:59:32 -0000
Hiya, On 27/01/15 11:44, Peter Gutmann wrote: > Stephen Farrell <stephen.farrell@cs.tcd.ie> writes: > >> You didn't say why. Why is it a bad idea? What is the downside? > > The fact that it's one more piece of special-case code to add, debug, and test > when we've already got perfectly-functional, debugged, and tested code, some > of it in active use for twenty years or more, to do it present everywhere that > uses bignums. It would be a special case, yes, and there is a small downside there I guess. I'm not sure how much implementation and deployment of current 25519 ought weigh against that, but its a trade-off, not a slam dunk, esp as the special-case code is not at all special in this case. (Remembering to do it is special I guess, but what you do is not a deal, and if you get it wrong your first test vector check will tell you immediately.) > (Another issue is that using a nonstandard form for representing the values is > bound to cause interop problems in the future when the 25519 form is the > opposite to what everything else does. Look at the mess that occurred during > the AES competition with different endiannesses used in various algorithms, > until the problems were pointed out at the second AES conference by someone > who'd actually implemented things from the spec ("Implementation Experience > with AES Candidate Algorithms") and NIST revised the requirements). I'd think that a change from the current (albeit smallish) amount of deployed stuff is more likely to result in interop issues actually since some code won't be updated no matter what an RFC says. But again, I don't see a showstopper argument there either way. FWIW, I don't own relevant code here, but I'd go with the current implementations myself as I don't think the special case is a real problem. Confusion and having to go and change existing code are IMO bigger downsides in this particular case. Not by much, but then this particular choice is not hugely important, as we all I hope agree. > > If the "spec" for 25519 is going to be "the standard is to blindly do whatever > djb's code does" then there's no need for a spec or any CFRG involvement, just > provide a link to djb's code, since that'll be the spec. It's decent code, > I'm not complaining about it, but the CFRG shouldn't be pretending to be > setting any standard if it's just "do whatever this code happens to do". The > code then becomes the spec. The series of humongous mail threads this RG has gone through just to get to this point makes it clear that "blindly do" etc. is just incorrect. S. > > Peter. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > >
- 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