Re: [Cfrg] Mishandling twist attacks

[Watson Ladd <[e-mail]>]

On Thu, Jan 15, 2015 at 8:12 AM, Lochter, Manfred
<[e-mail]> wrote:
>  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

Yes, you are correct: I was thinking of lattice attacks on signatures
as instances of Bleichenbacher HNP solution.
>
>
>
>
> __________ ursprüngliche Nachricht __________
>
> Von:            Watson Ladd <[e-mail]>
> Datum:  Mittwoch, 14. Januar 2015, 16:55:40
> An:             "Lochter, Manfred" <[e-mail]>
> Kopie:  "[e-mail]" <[e-mail]>, "D. J. Bernstein" <[e-mail]>
> Betr.:  Re: [Cfrg] Mishandling twist attacks
>
>> On Wed, Jan 14, 2015 at 5:44 AM, Lochter, Manfred
>>
>> <[e-mail]> wrote:
>> > 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.
>>
>> 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.
>
> 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 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)

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

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.

>>
>> (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.)
>>
>> > 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.
>>
>> 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.
>
> 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.
>>
>> 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.
>
> 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?

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.

>>
>> > 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.
>>
>> 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.
>
> There is no connection between my statement and my comment.
>>
>> 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.
>
> And other implementors will also make mistakes. Anyhow: What do you want to
> imply here?

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?

>
> My whole posting is dealing with Dan's proposal for signatures (!). It is not
> connected to any of your papers.
>>
>> Sincerely,
>> Watson Ladd
>>
>> > Manfred
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > __________ ursprüngliche Nachricht __________
>> >
>> > Von:            "D. J. Bernstein" <[e-mail]>
>> > Datum:  Montag, 1. Dezember 2014, 23:37:20
>> > An:             [e-mail]
>> > 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
>> >> [e-mail]
>> >> 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: [phone] 5643
>> > Telefax: [phone] 5643
>> > E-Mail: [e-mail]
>> > Internet:
>> > www.bsi.bund.de
>> > www.bsi-fuer-buerger.de
>> >
>> > _______________________________________________
>> > Cfrg mailing list
>> > [e-mail]
>> > 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: [phone] 5643
> Telefax: [phone] 5643
> E-Mail: [e-mail]
> Internet:
> www.bsi.bund.de
> www.bsi-fuer-buerger.de



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