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 [EMAIL PROTECTED]
