Subject: Re: [Cfrg] Mishandling twist attacks

From: "Lochter, Manfred" <[email-masked]>
Date: Wed, 14 Jan 2015 14:44:45 +0100

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 
source.

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. 

Manfred

__________ ursprüngliche Nachricht __________

Von:		"D. J. Bernstein" <[email-masked]>
Datum:	Montag, 1. Dezember 2014, 23:37:20
An:		[email-masked]
Kopie:	
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
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
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
E-Mail: [email-masked]
Internet:
www.bsi.bund.de
www.bsi-fuer-buerger.de

---

From: Watson Ladd <[email-masked]>
Date: Wed, 14 Jan 2015 07:55:40 -0800

> perfectly safe."? I would be glad to have a look at it if you provide a

Remember how the Bleichenbacher attack actually works, and what the
countermeasure recommended in standards is.

The Bleichenbacher attack relies on the bias caused by reducing a
number uniformly in the range [0, 2^n) modulo p, where p
is close to 2^n. The bias is approximately 1/2^(n-log(p)). When n is
about 2 log p, this becomes negligible.

Adding the high bit means taking numbers in the range [2^(n-1), 2^n).
The bias is now 1/2^(n-1-log(p)), which is still small.

> implementations vulnerable to Timing Attacks.

Implementors can also use powering computations that are constant
time. The countermeasures you describe are frequently not implemented,
and in many cases can be bypassed by cache-based attacks examining
data flow, for instance. It's also not clear that they are necessary:
the Montgomery ladder is extremely performant and has a uniform flow
of operations. Comb based methods with protection can be trickier.

(For use in signatures, one would likely need to add on y coordinate
reconstruction and an isogeny: the formulas  for reconstruction exist
out there, but I've not found a good source yet.)

> nonce" but the minimum-length nonce to withstand SCA.

You appear to be confusing two issues: generation of signature nonces
and computing scalar multiples securely. Using a double-length nonce
solves the secure generation problem. When it comes to computing
scalar multiples, blinding of the scalar involves adding a random
multiple of the
prime. Of course, when this is a nonce used in a signature, produced
by reducing a double length nonce, adding back a random multiple might
as well be using the original nonce.

In particular, the length of extra bits required for Bleichenbacher
defense is largely independent of the prime. The claimed superiority
of random primes for blinding is in doubt: several people have pointed
to papers breaking this protection unless we use 256, not 32 extra
bits. Certainly for the NIST primes 32 bits extra will not randomize
significant blocks of bits.

> that users will implement these ladders.

One can use a uniform nonce in [0, p), obtained by rejection sampling.
I don't see how this issue doesn't also apply to random primes.

Yes, implementors in the pay of the NSA or BND can always make
"mistakes". However, we've described the constant-time ladder in the
draft and explained why it should be used. When it comes to
signatures, I expect that a similar amount of attention will be paid.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Lochter, Manfred" <[email-masked]>
Date: Thu, 15 Jan 2015 17:12:27 +0100

Watson,

I think we have a communication problem. At least I do not see any relation 
between my remarks and your replies. For details please see below.

Manfred

Von:            Watson Ladd <[email-masked]>
Datum:  Mittwoch, 14. Januar 2015, 16:55:40
An:             "Lochter, Manfred" <[email-masked]>
Kopie:  "[email-masked]" <[email-masked]>, "D. J. Bernstein" <[email-masked]>
Betr.:  Re: [Cfrg] Mishandling twist attacks

> > 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 source.
>

Watson, it is interesting that you mention Bleichenbacher's attack in reply on 
my contribution that is dealing with securely randomized ephemeral keys. 

I did not even mention the generation of unbiased (mod group order) ephemeral 
keys. Of course Dan's method gives keys that are sufficiently equally 
distributed mod group order.

But this is not my topic here. I was discussing Dan's proposal for blinding 
ephemeral keys in the range 1..q-1 by adding a multiple of q and then setting 
the msb to 1. 
This may lead to lattice attacks as e.g. described by 
Smart-Nguyen-Shparlinski. (Literature references are given in my posting from 
October, 8, 2014.)

You might also want to check Bleichenbachers talk during the rump session of 
Crypto 2005 http://www.iacr.org/conferences/crypto2005/rumpSchedule.html

>
> > 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.
>

Actually I'm not describing a countermeasure but discussing a proposed 
countermeasure which I believe is dangerous. And I'm also stating that a full 
ladder is better than adding an extra bit. What is your point exactly?
> > 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.
>

Again: I'm talking about Dan's proposal. You brought in Bleichenbacher which 
is a different topic. But please do not blame me for mixing up things.
> significant blocks of bits.

Again: I am not talking about the Bleichenbacher-bias-attack!
If 32 for NIST are sufficient is an implementation issue. As a minimum 32 are 
needed. The situation is different for primes like the 25519 prime, where the 
gap between 1s is much larger. Consequently curves over these fields need 
more randomisation. In principle I do not see which part of my statement you 
think is incorrect. Who is several people and what exactly did they say?
>
> > 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.
> >
> > (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.
>

There is no connection between my statement and my comment.
> signatures, I expect that a similar amount of attention will be paid.

And other implementors will also make mistakes. Anyhow: What do you want to 
imply here?

My whole posting is dealing with Dan's proposal for signatures (!). It is not 
connected to any of your papers. 

Postfach 20 03 63
53133 Bonn

---

From: Watson Ladd <[email-masked]>
Date: Thu, 15 Jan 2015 10:26:26 -0800

> between my remarks and your replies. For details please see below.

Yes, you are correct: I was thinking of lattice attacks on signatures
as instances of Bleichenbacher HNP solution.
> Crypto 2005 http://www.iacr.org/conferences/crypto2005/rumpSchedule.html

I'm familiar with both of these sources. And both rely on being able
to rewrite the equation describing how the nonce is generated to
create an instance of the hidden number problem that's easy to solve.
What I don't see is how you propose to do that for an ephemeral scalar
generated by
selecting x in  [0, 2^(2\log q-1)) and using x+2^(2\log q). Knowing
that we can subtract 2^(2\log q) modulo q, and then get x generated as
a random number in [0, 2^(2\log q-1)) isn't enough to solve the hidden
number problem; x is almost uniformly distributed modulo q.

(If we know the bit for x in [0, q), then the range after subtracting
is [0, q/2) which is enough)

If we're talking about purely exponent randomization, rather than
generation of nonces for signatures, then for 2^255-19 for instance, a
product with a number of the form (2^254+z), z smaller, will be less
than 2^510 and greater than 2^509-19*2^254.  The need to have the high
bit set doesn't substantially reduce the randomization. (Yes, this
doesn't always do it: with a bit more analysis one can calculate the
exact range of multipliers required)

> ladder is better than adding an extra bit. What is your point exactly?

My point is that DJB has always recommended the full Montgomery
ladder, isn't talking about signatures in this message, and when he is
talking about signatures, has a countermeasure that seems to me works.
What do you think the proposal he's discussing is, and why do you
think it's vulnerable? It's different from the ones attacked in the
papers you mention, in ways that make those attacks not apply.

In particular his proposal for signatures is to generated double
length nonces, and then either set the high bit or use a possibly
length revealing algorithm for scalar multiplication. This isn't
affected by lattice based attacks.

> think is incorrect. Who is several people and what exactly did they say?

One NIST prime is = 2^256 -2^224 + 2^192 + 2^96-1. Adding a 32 bit
multiple of this prime doesn't obscure bits between the 96th and 32nd
bit. This seems to be what
https://www.nics.uma.es/pub/acns2011/files/ppt/2-2.pdf exploits, for
instance.
http://link.springer.com/article/10.1007/s13389-014-0081-y#page-1
seems to exploit similarly small degrees of randomization, even on SPA
protected devices.

> And other implementors will also make mistakes. Anyhow: What do you want to

I'm not implying anything. I don't see how random primes improve the
issue, or why the countermeasures you are bringing up are better than
the ones proposed by DJB. In particular, why wouldn't users of random
prime curves reduce nonce size and disable countermeasure to timing
attacks for the same reasons they would on Curve25519?