Brumley & Boneh timing attack on OpenSSL

[David Wagner]

Nomen Nescio  wrote:
>Regarding using blinding to defend against timing attacks, and supposing
>that a crypto library is going to have support for blinding:
>
> - Should it do blinding for RSA signatures as well as RSA decryption?
> - How about for DSS signatures?

My guess is that it's not necessary, as the attacker doesn't
have as much control over the input to the modular exponentiation
process in the case of RSA signatures.  (For RSA decryption,
the attacker can specify the ciphertext freely.  However, for
signatures, the input to the modular exponentiation is a hash
of the attacker's chosen input, which gives the attacker a lot
less freedom to play Bleichenbacher-like games.)

But then, the recent Klima-Pokorny-Rosa paper shows how even
just a tiny crack can lead to subtle, totally unexpected attacks.
Who would have thought that SSL's version rollback check (two bytes
in the input to the modular exponentiation) could enable such a
devastating attack?  Not me.

The Boneh-Brumley and KPR papers have made me much more paranoid
about side-channel attacks.  As a result, I might turn blinding on
even for signatures by default, out of caution, even though I can't
see how such an attack could possibly work.

> - How about for ElGamal decryption?
> - Non-ephemeral (static) DH key exchange?

Yes, I think I'd use side channel defenses (like blinding) here.
I don't know of any attacks off the top of my head, but it sure
seems plausible to me that there might be some.

> - Ephemeral DH key exchange?

I wouldn't tend to be very worried about ephemeral exchanges,
since all the attacks we've seen so far require many interactions
with the server with the same key.  I could be wrong, but this
seems pretty safe to me.

>In other words, what do we need as far as blinding support either in
>developing a crypto library or in evaluating a crypto library for use?
>
>Suppose we are running a non-SSL protocol but it is across a real-time
>Internet or LAN connection where timing attacks are possible.  And suppose
>our goal is not to see a paper and exploit published within the next
>three years telling how to break the protocol's security with a few
>hours of connect time.

Good question.
Personally, I'd enable side channel defenses (like blinding) by
default in the crypto library in every place that the library does
some lengthy computation with a long-lived secret.
But I'll be interested to hear what others think.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com