Re: [Cfrg] normative references

Manuel Pégourié-Gonnard <mpg@elzevir.fr> Wed, 15 January 2014 22:09 UTC

Return-Path: <mpg@elzevir.fr>
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 0991E1AE2AE for <cfrg@ietfa.amsl.com>; Wed, 15 Jan 2014 14:09:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.994
X-Spam-Level:
X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793] 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 RudMIuWwWXm0 for <cfrg@ietfa.amsl.com>; Wed, 15 Jan 2014 14:09:16 -0800 (PST)
Received: from mordell.elzevir.fr (unknown [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id D38731AE237 for <cfrg@irtf.org>; Wed, 15 Jan 2014 14:09:15 -0800 (PST)
Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 688F6161BF for <cfrg@irtf.org>; Wed, 15 Jan 2014 23:09:03 +0100 (CET)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 764E02986B for <cfrg@irtf.org>; Wed, 15 Jan 2014 23:09:02 +0100 (CET)
Message-ID: <52D706FE.9060703@elzevir.fr>
Date: Wed, 15 Jan 2014 23:09:02 +0100
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= <mpg@elzevir.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
References: <mailman.4685.1389738617.2658.cfrg@irtf.org> <52D645EC.4000408@gmail.com> <52D684EE.9050304@cisco.com> <CEFBFBE5.2C52B%paul@marvell.com> <CACsn0cmegQ8_CjCFx7VN30yQ=P=Neb8kLr-i+wgj680E16V1rQ@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7FB9B37@SC-VEXCH2.marvell.com> <CACsn0cnw8MydqSxL0fEjM+jzB+UUfqwMoMVqG2Df99pU30Tr5A@mail.gmail.com>
In-Reply-To: <CACsn0cnw8MydqSxL0fEjM+jzB+UUfqwMoMVqG2Df99pU30Tr5A@mail.gmail.com>
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Cfrg] normative references
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, 15 Jan 2014 22:09:17 -0000

On 15/01/2014 22:30, Watson Ladd wrote:
> On Wed, Jan 15, 2014 at 12:50 PM, Paul Lambert <paul@marvell.com> wrote:
>>
>> We're in the documentation business here - not code libraries. Plus we're
>> supposed to have multiple interoperable different implementations.
> 
> Do you really think everyone implementing P256 does it themselves? Or do they
> take example code from the Internet?
> 
It seems to me that the whole goals of standards is to allow multiple
interoperable implementations, as Paul says. (Besides, they often give much more
information than existing code if you want to modify/extend anything, make
different trade-offs, etc.)

>> Yes ... and why did you leave out Ed25519?       It's being used and should at least be discussed/reviewed/
> 
> It's the same as Curve25519, and not in safecurves. Let's be real
> clear: isogenies don't change anything substantial.

Of course they don't change anything to the DLOG security. But they change
everything on actual computations and representations.

My opinion is you should explain how to compute the isogeny or (inclusive)
include Ed25519 as a "different" curve and explain which formulas to use with
it. I honestly don't know which is the more helpful.

> I'm also going to explain the Montgomery ladder and double-and-add on
> Edwards and that's it. RFC 6090 doesn't talk about
> radix-k either, nor does it explain Shamir's trick, or fun with the
> Brier-Joyce ladder, or w-NAF, etc.

I fully agree that the document should only discuss the most "basic" (and safe)
algorithms for computing the necessary operations. However, if other algorithms
are know that have (potential) security issues (like, not being constant-time,
having special cases) it would be great if the document could point out these
dangers.

> I still don't see why this form is much better than a paragraph
> listing these things.
> 
Much easier to access each piece of information. Almost like an array compared
to a linked list (at least in my opinion).

>> Hex fits better in an RFC ...  decimal would be fine also.
> 
> Six of one, half-dozen of the other.
> 
I'm not sure I understand you comment. Anyway, in my experience, I feel like
I've seen much more (large) constants in hex than in decimal in RFCs.

On the very down-to-earth practical side, hex is more compact, so it means less
line breaks, so easier copy-pasting (yeah, I know, gory details).

Manuel.