Re: [Cfrg] draft-ladd-safecurves-02

Manuel Pégourié-Gonnard <mpg@elzevir.fr> Sat, 11 January 2014 16:45 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 F01741AE07D for <cfrg@ietfa.amsl.com>; Sat, 11 Jan 2014 08:45: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 27T9woVLlk1m for <cfrg@ietfa.amsl.com>; Sat, 11 Jan 2014 08:45:17 -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 E80DF1AE080 for <cfrg@irtf.org>; Sat, 11 Jan 2014 08:45:16 -0800 (PST)
Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 2082E161C1; Sat, 11 Jan 2014 17:45:06 +0100 (CET)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 2975C2986F; Sat, 11 Jan 2014 17:45:05 +0100 (CET)
Message-ID: <52D17510.8060207@elzevir.fr>
Date: Sat, 11 Jan 2014 17:45:04 +0100
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <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: Watson Ladd <watsonbladd@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <CACsn0c=uuzsH3Zd-tPEAMsxAbk-RpQEHpfbTh9gHJi5ggjT+qg@mail.gmail.com>
In-Reply-To: <CACsn0c=uuzsH3Zd-tPEAMsxAbk-RpQEHpfbTh9gHJi5ggjT+qg@mail.gmail.com>
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Cfrg] draft-ladd-safecurves-02
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: Sat, 11 Jan 2014 16:45:18 -0000

Hi,

Notes taken while reading -02 (in order of reading, so mixing typos with more
important comments).

- abstract: why mention the Jacobian rather than say "elliptic curves" (as you
do in the intro)? Maybe say that DDH is *believed* to be hard, too.

- end of the intro: "then short Weierstrass curves": then -> than

- section 2 "Validation information is given at [SAFECURVES]." What do you mean
exactly? Is it a repeat of "Proofs of all properties claimed exist in
[SAFECURVES]." in the intro, or do you mean something else?

- as an implementer, I'd have a preference for constants in hex. Also, I don't
like the formatting very much. Starting each constant on a new line might help.

- I second Alyssa's suggestion to split the content in two sections, too.

- formulas for Montgomery curves: I think "P_i = [i] P_1" is not what you want
to say. Also, I'm not sure the reference to the Kummer curve is of any help.

- why give the formulas for Edwards with common sub-expressions already
eliminated, but not for Montgomery?

- point encoding "GF_p point on E(GF_p)" isn't that a bit redundant?

- "Formulas for decompression are left as an exercise to the reader." You can't
be serious. The goal should be to actually help people write correct
implementations, which this kind of funny (?) non-reference does not.

- security considerations: "some checks in some protocols": which and which?
"certain attacks": which ones? Again, please, this should be a technical
document giving precise, actionable information.

- IANA: sorry if this is a dumb question, but I'm not sure I see the need for a
IANA register here (an would it be only for the "chicago" curves or all known
curves)? So far, there are protocol-specific registries (eg, TLS Named Curves)
and it seems to me it has been enough.

- OTOH, it would probably be good to have OIDs for the curves here, since they
could be used by many protocols.

Manuel.