Re: [Cfrg] Mishandling twist attacks

"Lochter, Manfred" <> Wed, 14 January 2015 13:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 67FA61B2C9B for <>; Wed, 14 Jan 2015 05:45:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.66
X-Spam-Status: No, score=-4.66 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aAjdmWlgkzFU for <>; Wed, 14 Jan 2015 05:45:19 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A44841A8AB4 for <>; Wed, 14 Jan 2015 05:45:17 -0800 (PST)
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t0EDjF60032014 for <>; Wed, 14 Jan 2015 14:45:15 +0100 (CET)
Received: (from localhost) by (MSCAN) id 5/; Wed Jan 14 14:45:15 2015
X-P350-Id: 25b396ea3d47c2b0
X-Virus-Scanned: by amavisd-new at
From: "Lochter, Manfred" <>
Organization: BSI Bonn
Date: Wed, 14 Jan 2015 14:44:45 +0100
User-Agent: KMail/1.9.10 (enterprise35 20141110.4f903a5)
References: <>
In-Reply-To: <>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-ID: <>
Archived-At: <>
Cc: "D. J. Bernstein" <>
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: Wed, 14 Jan 2015 13:45:22 -0000

Here we still seem to disagree, Dan. 

When we talked about this topic during RWC I had the impression that you were 
only adressing DH and not signatures. Now I rechecked your contribution and 
would like to make some comments:

For signatures setting any bit may allow lattice-attacks. Do you have a proof 
for your claim that "Setting the high bit of such a long nonce is also 
perfectly safe."? I would be glad to have a look at it if you provide a 

I' m not blaming the high bit, as you state, but the unnecessary tweak of the 
nonce. The same effect can easily be achived by using dummy operations.

In addition this method does not make an implementors life easier. In real 
world applications users will forget the additional bit and make their 
implementations vulnerable to Timing Attacks.

The necessary length of nonces depends on the stucture of the underlying prime 
field and of the order of the chosen group order. Whilst for NIST curves 32 
bits seem to be OK, for general n-bit curves over special prime fields n bits 
of blinding are necessary. This blinding length is then not "an extra long 
nonce" but the minimum-length nonce to withstand SCA. 

I admit, that for some implementations (depending on hardware used, and other 
factors) your method may still allow faster implementations than random prime 
curves with maximum necessary nonce length.

However implementation security may not be improved:

(a) Users will change to shorter nonces to become even faster. They be then 
use a too short nonce.
(b) Even if the curves support constant-time ladders, there is no guarantee 
that users will implement these ladders. 


__________ ursprüngliche Nachricht __________

Von:		"D. J. Bernstein" <>
Datum:	Montag, 1. Dezember 2014, 23:37:20
Betr.:	Re: [Cfrg] Mishandling twist attacks

> Lochter, Manfred writes:
> > On the other hand this countermeasure is quite dangerous, when applied
> > during signature generation.
> No. It's true that minimum-length signature nonces with the high bit set
> are dangerous, but minimum-length signature nonces _without_ the high
> bit set are _also_ dangerous, so blaming the high bit is unreasonable.
> The best protection we know is to generate much longer nonces---such as
> the 512-bit nonces in Ed25519. Then the system isn't broken by a timing
> attack revealing the nonce length. Setting the high bit of such a long
> nonce is also perfectly safe.
> Of course, an implementor can still get in trouble by (1) reducing these
> nonces and then (2) leaking the lengths of the reduced nonces through a
> variable-time scalarmult method. So, as another line of defense, we also
> choose curves that support simple, fast, constant-time ladders.
> ---Dan
> _______________________________________________
> Cfrg mailing list

Lochter, Manfred
Bundesamt für Sicherheit in der Informationstechnik (BSI)
Referat K21
Godesberger Allee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Telefon: +49 (0)228 99 9582 5643
Telefax: +49 (0)228 99 10 9582 5643