Dear OpenSSH devs, I came accross this paper yesterday. http://eprint.iacr.org/2011/232 It states that they were able to recover ECDSA keys from TLS servers by using timing attacks agains OpenSSL's ECDSA implementation. Is that known to be exploitable by OpenSSH ? (In my understanding, it's easy to get a payload signed by ECDSA during the key exchange so my opinion is that it is). There's a patch for openssl in the paper, that remove the detectable optimization away. Would you consider blacklisting openssl versions that do not implement that workaround ? Abstract follows. Kr, Aris Abstract: For over two decades, timing attacks have been an active area of research within applied cryptography. These attacks exploit cryptosystem or protocol implementations that do not run in constant time. When implementing an elliptic curve cryptosystem that provides side-channel resistance, the scalar multiplication routine is a critical component. In such instances, one attractive method often suggested in the literature is Montgomery's ladder that performs a fixed sequence of curve and field operations. This paper describes a timing attack vulnerability in OpenSSL's ladder implementation for curves over binary fields. We use this vulnerability to steal the private key of a TLS server where the server authenticates with ECDSA signatures. Using the timing of the exchanged messages, the messages themselves, and the signatures, we mount a lattice attack that recovers the private key. Finally, we describe and implement an effective countermeasure.
On Mon, 23 May 2011, Aris Adamantiadis wrote:> Dear OpenSSH devs, > > I came accross this paper yesterday. http://eprint.iacr.org/2011/232 > It states that they were able to recover ECDSA keys from TLS servers by > using timing attacks agains OpenSSL's ECDSA implementation. > Is that known to be exploitable by OpenSSH ? (In my understanding, it's > easy to get a payload signed by ECDSA during the key exchange so my > opinion is that it is). There's a patch for openssl in the paper, that > remove the detectable optimization away. Would you consider blacklisting > openssl versions that do not implement that workaroundThis result concerns binary/GF(2m) fields only and not the prime fields that OpenSSH uses in recent versions. Unless a similar timing oracle is found for GF(p) fields then no OpenSSH-side workaround is required. -d
> > This result concerns binary/GF(2m) fields only and not the prime fields > that OpenSSH uses in recent versions. > > Unless a similar timing oracle is found for GF(p) fields then no > OpenSSH-side workaround is required. > >OpenSSL has had timing attacks against most of their production ciphers (RSA, AES, etc). Has the author of the paper weighed in on whether he thinks his attack will affect GF(p)? --Dan
On Mon, 23 May 2011, Dan Kaminsky wrote:> > Unless a similar timing oracle is found for GF(p) fields then no > > OpenSSH-side workaround is required. > > > > > OpenSSL has had timing attacks against most of their production ciphers > (RSA, AES, etc). Has the author of the paper weighed in on whether he > thinks his attack will affect GF(p)?The Brumley and Tuveri attack is against a scalar multiplication algorithm that is specific to GF(2m) fields (see section 3.2 of the paper). An attack on prime fields would be a new one altogether. -d
Isn't it enough to limit the range of $k$ (the random value selected
during signature generation) to values with the top bit set?
(Or--if there are too few of those--only use values with "01" in the
top
bits, still leaving 2^{158} possible values?)
-a