Re: [Cfrg] ECC desiderata

"D. J. Bernstein" <> Sat, 09 August 2014 04:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 842481A0AAD for <>; Fri, 8 Aug 2014 21:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XQY7l7rlF_vv for <>; Fri, 8 Aug 2014 21:31:26 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 220531A0AA4 for <>; Fri, 8 Aug 2014 21:31:25 -0700 (PDT)
Received: (qmail 17191 invoked by uid 1011); 9 Aug 2014 04:31:25 -0000
Received: from unknown (unknown) by unknown with QMTP; 9 Aug 2014 04:31:25 -0000
Received: (qmail 10800 invoked by uid 1001); 9 Aug 2014 04:31:16 -0000
Date: Sat, 09 Aug 2014 04:31:16 -0000
Message-ID: <>
From: "D. J. Bernstein" <>
In-Reply-To: <>
Subject: Re: [Cfrg] ECC desiderata
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 09 Aug 2014 04:31:30 -0000

Bodo Moeller writes:
> As the example of TLS with its protocol flaws shows (see the unknown
> key-share attacks in, it is
> possible to end up in a situation in which public-key validation
> *does* matter; it's easier to get right with cofactor 1.

Are you sure that patching this protocol with (patented) public-key
validation is actually easier to get right with cofactor 1 than with,
e.g., Curve25519? For Curve25519 a simple check for ladder output 0
detects all "non-contributory" inputs, thanks to

   (1) the theorem guaranteeing that scalar multiplication works for all
       inputs and
   (2) the factor 8 in the local scalar.

For cofactor 1 the implementor has to go digging through obscure, poorly
tested code to figure out how the point at infinity might end up being
communicated (e.g., does the implementation treat input points off the
curve as infinity?) and then represented internally.

Isn't TLS actually moving to something much more confidence-inspiring
than such patches, namely hashing more inputs? Hashing stops the attack
without public-key validation and without the implementor having an
oportunity to screw up public-key validation. Isn't hashing also what
the attack authors recommended?

Anyway, these are evaluation questions, and all of them fit within my
suggested statement of desiderata:

   D1. Speed and simplicity (and speed-simplicity combinations) for
   secure implementations.

   D2. Avoiding speed incentives and simplicity incentives towards
   insecure implementations.

When you argue that in some situations cofactor 1 produces secure
implementations more simply than larger cofactors do, you're arguing
that to some extent cofactor 1 scores well on simplicity for secure
implementations and avoids simplicity incentives towards insecure
implementations (whereas I'm arguing that this evaluation is incorrect
and in any case is outweighed by the much more common situations in
which cofactor 1 scores very badly). This seems to be a confirming
example of D1+D2 as capturing the real desiderata: we're discussing the
simplicity of secure implementations and of insecure implementations.