Re: [Cfrg] Curve manipulation, revisited

Mike Hamburg <> Mon, 29 December 2014 21:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4A67E1A8F49 for <>; Mon, 29 Dec 2014 13:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.556
X-Spam-Level: *
X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SjwwYW5l_tZS for <>; Mon, 29 Dec 2014 13:02:12 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AFD61A8ACD for <>; Mon, 29 Dec 2014 13:02:11 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 880973AA12; Mon, 29 Dec 2014 13:00:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1419886806; bh=4xE6bQKdqtZg+pMuK849b81RVL3NnlV716iAxdqGuhc=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=Vcnkyj1zGXAQrcTBfU+7dVOTSye7DAZqMlF5X4jqn5LpangP4DkKatuhcYxpQ3pBk 5JdndCZ8tu4Y10E47bWUXpeAr6dgW9Cfl3uXBsBK4j4n1JWKARerz+0Etg29ODH8o0 Vgxtvm/AKJQoJAcQnDkCcf3An48vWXiEyLx9H1VY=
Message-ID: <>
Date: Mon, 29 Dec 2014 13:02:08 -0800
From: Mike Hamburg <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Benjamin Black <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------050105030604060503050101"
Cc: Adam Langley <>, "" <>
Subject: Re: [Cfrg] Curve manipulation, revisited
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: Mon, 29 Dec 2014 21:02:14 -0000

On 12/29/2014 10:59 AM, Benjamin Black wrote:
> I can only go on the things he puts in writing and they say the opposite.
> >Rather than
> >blaming the implementor, we eliminate these security failures by
> >
> >   * adding twist security, for both Montgomery and Edwards, and
> >   * switching to single-coordinate ladders.
> That is not a suggestion folks be allowed to implement the ladder if 
> they choose to. It is a requirement that they not be allowed to use 
> anything else. If they are allowed to use anything but 
> single-coordinate ladders, then, in his own words, we have not 
> eliminated these "security failures" and will be back to "blaming the 
> implementor". If he means something else he should say something else.
> b

Look, do you really want to argue one single message to death?  If so, 
maybe you should at least quote the whole message.  DJB wrote:
> Benjamin Black writes:
> > The concerns do not apply to the twisted Edwards curve we generated,
> > only to the isogenous Montgomery curve.
> False.
> Invalid-curve attacks completely break the simplest DH implementations
> in Montgomery coordinates _and_ in Edwards coordinates. Rather than
> blaming the implementor, we eliminate these security failures by
>     * adding twist security, for both Montgomery and Edwards, and
>     * switching to single-coordinate ladders.
> This is the primary motivation for twist security (and a closer look,
> as I've explained in detail, shows a twist-security criterion that's met
> by Curve25519 and not by PinkBikeShed). This has nothing to do with the
> superficial differences between the Montgomery x and the Edwards y, both
> of which support ladders.
> If you disagree, please explain why you're requiring _any_ type of twist
> security for Edwards curves. Why aren't you saying something like "The
> larger d forced by 'twist security' is a violation of rigidity" and
> objecting to the whole concept of twist security for Edwards curves?
> ---Dan
This is in the context of an argument against a cofactor-4 curve with a 
cofactor-8 twist (with Z8 torsion).  It is not about requiring ladders 
vs windows or combs.  The argument is that twist security is part of a 
strategy to secure single-coordinate ladders, so we should make sure 
that it actually does that.

To be clear, I'm ambivalent on this particular argument.  But if you 
read it as an argument that every implementation of ECDH should be 
banned except for single-coordinate ladders, then I believe that you are 
intentionally and obstinately misreading it.

And to think, I used to wonder why standards committees are so slow.

-- Mike