Re: [Cfrg] Mishandling twist attacks

Samuel Neves <> Sat, 29 November 2014 01:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3C5931A1BB5 for <>; Fri, 28 Nov 2014 17:20:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4gTzQTHV8xy4 for <>; Fri, 28 Nov 2014 17:20:21 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFA431A1BAF for <>; Fri, 28 Nov 2014 17:20:20 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id sAT1JjMf002009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Sat, 29 Nov 2014 01:19:51 GMT
Message-ID: <>
Date: Sat, 29 Nov 2014 01:19:45 +0000
From: Samuel Neves <>
MIME-Version: 1.0
To: "" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-FCTUC-DEI-SIC-MailScanner-Information: Please contact for more information
X-FCTUC-DEI-SIC-MailScanner-ID: sAT1JjMf002009
X-FCTUC-DEI-SIC-MailScanner: Found to be clean
X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-60.25, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25, L_SMTP_AUTH -50.00)
Subject: Re: [Cfrg] Mishandling twist attacks
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, 29 Nov 2014 01:20:27 -0000

On 28-11-2014 17:22, Watson Ladd wrote:
> What exactly is wrong with telling everyone to multiply by 8, not 4,
> even if the cofactor is 4?

If your protocol is tightly coupled with an elliptic curve, nothing wrong with that, I suppose. But schemes and
protocols are often specified in terms of generic groups, where order and cofactor always exist, but the notion of twist
security may not.

> So if we add this requirement to have the curve have larger cofactor
> then the twist, then we still get E-521, and we will get Curve25519 at
> the low end. It seems to me like we should make this change to the
> generation method, and run it on 2^389-21 to get the intermediate size
> curve.

All this bickering further convinces me that complete Edwards curves over 3 (mod 4) primes are the way to go:

 - Square root computations are the simplest. 1 (mod 4) is too lenient, by the way: I don't think anybody is interested
in computing square roots over 1 (mod 8) primes.

 - Edwards curves over 3 (mod 4) primes can have both order and twist with cofactor 4.

 - For users obsessed with speed, Mike Hamburg has described how to use an isogeny to get twisted Edwards-speed out of
these curves [1].

We already have an excellent candidate in this space, namely Curve1174 over 2^251-9. E-521 is also such a curve. Since
2^389-21---which appears to be one of the nicest primes in that range (the other one being 2^379-19)---is also congruent
to 3 (mod 4), it seems logical to keep things consistent and choose 3 (mod 4) primes for every work factor.