Timing attack threatens private keys on SSL servers
Security researchers have discovered a "timing attack" that creates a possible mechanism for a hacker to extract the secret key of a TLS/SSL server that uses elliptic curve cryptography (ECC). Elliptic curve cryptography is a type of public-key algorithm that uses the maths of elliptic curves rather than integer factorisation, …
Countermeasure
The article makes sense to me. The one thing I don't understand is their countermeasure, specifically how it does anything other than increase the factors to consider when measuring the time taken.
contermeasure
presumably, it makes the time it takes to process more random, so it can't be used for timing attacks
Cryptic...get it?
I understood the article just fine...I was making a wordplay on "cryptic"...perhaps the joke alert would have been a more appropriate icon.
i understand the article so well that I wonder why they don't use a random delay in the algorithm, rather than a set time to compute. The random delay would be interesting, because attackers would not know if they were facing an encryption algorithm that was vulnerable to such attacks, or one that was smart enough to randomly delay. As such, they may waste time attempting timing attacks.
Random is not random
Most random number generation is itself predictable, so a badly implemented random delays would probably give you an entry into the system.
The only random delay that would work and prevent intrusion is adding a random amount onto a fixed delay which is guaranteed to be longer than the time to compute, thus completely hiding the compute time.
Again ?
Haven't there been timing attacks against SSL before ?
Seedy code
I guess this is due to some code using the current time of day as a way of seeding a random number generator?
Nope.
No this is the result of a ladder function being directly sensitive to the length of the input. Probably done in an effort to make the ladder function as fast as possible, rather than as consistent as possible. (I.e, it's not timing as in when you make the request, but timing as in how long the request takes to process.)
Their fix makes the ladder function consistent. Me, I'd fix it by adding a random delay adjusted for the input length, thereby teasing fuzzers with what initially looks like it might be a timing exploit candidate but leads to garbage. But I'm a jerk.
Not quite
That's not the issue here. The problem is with knowing that certain functions take different amounts of time to perform for different inputs. These time differentials allows the attacker to make educated guessed as to the contents of the input.
Maybe a fix is
for openssl to sleep() for a brief random period after doing the ECC thing, thus obscuring the time interval that the attack is trying to measure?
Six years out of date
This attack, and a robust counter-measure to it, were published in 2005 in "Advances in Elliptic Curve Cryptography" (Blake, Seroussi, & Smart - editors). So you are wrong to say 'Security researchers have discovered a "timing attack"'. If you had taken the trouble to follow your own link and read the Abstract there, you would have seen that all the Secutiry Researchers have done is to take this hackneyed old idea and show that OpenSSL is still vulnerable to it.
Six years out of date
This attack, and a robust counter-measure to it, were published in 2005 in "Advances in Elliptic Curve Cryptography" (Blake, Seroussi, & Smart - editors). So you are wrong to say 'Security researchers have discovered a "timing attack"'. If you had taken the trouble to follow your own link and read the Abstract there, you would have seen that all the Secutiry Researchers have done is to take this hackneyed old idea and show that OpenSSL is still vulnerable to it.
a
thats funny posted first time then Anonymous (you not want to post your name)
still he still does have an point ()
Hardcore hacking
Clever stuff - not one for the script kiddies, judging by the research paper. I think the countermeasure idea is to amend the algorithm so that it takes a similar time to perform whatever the bit length of the input, but I could be wrong (as always :-)
Nice timing
OpenSSH just got through changing their default host-key format to ECDSA (cue much faffing around with my Linux boxen). Hope they can get "countermeasures" in place rather than reverting to DSA.
