Talk:Timing attack

I added a lot

Hi! I added a lot. I tried to make it less technical in the introduction, and I added an example that I think is relatively easy to understand. It is not complete in the sense that things are missing here and there, but it gives the general feeling of the idea behind timing attacks.

I must note, that timing attack is NOT AT ALL connected with assymetric ciphers, and in fact most timing attacks are done on the protocols(e.g. SSL implementations) rather than the crypto-engine implementations (El-Gamal, RSA, IDEA, etc). Of course it is right to note that it is easier to do a cracking on a bad assymetric cipher implementation this way since it takes much more time to compute than the symmetric (if the symmetric implementation has a bug), but this is not connected to the assymetric cipher, only its implementation! Msoos 19:32, 27 April 2006 (UTC)

Any reference to a successful attack on perfect coding?

The section The idea behind the attack says:

It can be used to attack anything, including perfect coding.

I would appreciate a reference or an example for a successful timing attack upon perfect coding. I doubt it is possible because the encryption/decryption algorithm takes the same time to accomplish for any plain text and key. --Yecril 11:41, 4 December 2006 (UTC)

I was once told a story that a certain hardware implementation of a one-time-pad was attackable, because the XOR gate would have slight timing differences for computing 0 xor 0 vs. 1 xor 1 and that this timing difference was observable by measuring the output signal of the device. I don't have a reference for this and would really like to have this story verified myself. Also, it seems rather improbable that a similar attack would be possible against a software implementation. 85.0.79.160 13:39, 6 December 2006 (UTC)

Here is a link to a page that mentions such a story at the end of the page. 85.0.79.160 13:48, 6 December 2006 (UTC)

A primitive timing attack: Rotary dial phone?

To find out whom another person is dialing to, you can stand nearby and hear the length of the rotary dial recoils for each number. So no matter how much the dialing person wants to keep the telephone number secret, as long as you can hear it, you can find out the telephone number, with some training. This is an archaic example.

An interesting related issues is, today, with tone-dial telephone, you can still "rotary dial" it by tapping the "hook" by the number of times by each number you want to dial. For example, to call number 555-1234, tap 5 times, pause, another 5 times, pause, etc.

Perhaps this would also all under "Acoustic cryptanalysis," although this involves a monotonous dialing sound, only meaningful by the length of the sound.

Step time function?

I was thinking about ways to combat timing attacks - the obvious approach of forcing the computation to always take the same length of time obviously increases average response time. But it occurred to me that one can achieve a compromise between information leaked and average response time by limiting the time the function takes to one of k discrete values. Is there anything in the literature about this approach, or is it infeasible for some reason? Thanks. Dcoetzee 19:44, 16 June 2008 (UTC)

The library 'cryptolib' by Jack Lacy did have an implementation of this idea. I'm not aware of any analysis of such a protection. It is quite unclear whether forcing the timing to some discrete value protects against timing attacks. It seems possible that it might make the situation worse, e.g. if forcing discrete times changes small timing differences into larger ones that are hence easier to measure by an attacker. 85.1.96.11 (talk) 20:13, 17 June 2008 (UTC)

My immediate thought after reading the article was to just add a random sleep after every algorithm. 110.175.254.120 (talk) 01:28, 15 October 2010 (UTC)

Removed SSL/TLS CBC attack

This section was confusing. While the example applied to OpenSSL, the attack was general to SSL/TLS using block ciphers in CBC mode (which itself might be a good example). I think the article requires more background to timing attacks, and then include more detailed examples if needed. Mmernex (talk) 15:17, 16 March 2009 (UTC)

isochronous code

One way to avoid leaking information during a timing attack: design and build a system so that the time measured by the attacker is always some fixed constant number of clock cycles, and each clock cycle is always some fixed constant amount of time.

Is there Wikipedia: common name for "software that always finishes in exactly some fixed constant number of clock cycles"? I'd like to mention that name in this article. (Perhaps even make that name a redirect to the appropriate section of this article).

Some people (a, b) call such code "constant-time code" or "a constant-time algorithm", but many more people use the term "constant time" to refer to code "with a fixed upper-bound on execution times" such as a O(1) scheduler that still leaks some timing information, or amortized constant-time code that leaks even more timing information.

("branch-free code", also called "straight line code" in the optimizing compiler article, when run on hardware with a fixed number of cycles per instruction, is perhaps the most common type of such software. But I'm looking for a more general term that covers all "software that always finishes in exactly some fixed constant number of clock cycles", including some software that has loops or other branches).

Is there some other name(s) people use for "software that always finishes in exactly some fixed constant number of clock cycles"? --DavidCary (talk) 15:20, 7 April 2015 (UTC)

You mention "when run on hardware with a fixed number of cycles per instruction" as a premise, but this is not always (and is perhaps rarely) to be assumed. The concept you might be looking for is more precisely a code–hardware combination that runs an algorithm is a fixed number of clock cycles. So the best term might imply a software–hardware combination that achieves the constant time goal, such as "fixed-time execution". —Quondum 15:55, 7 April 2015 (UTC)

A timing attack IS IMPOSSIBLE

Well, its possible but only in rarest case: The machine should run a single process, it shouldn't run multi tasks the attacks should be done locally, and the machine should be incredibly slow (a embedded machine). Why? Because modern machines are doing several tasks at the same time and it affects the speed to run every operation.

I tried to replicate the exercise and it was impossible. How?

Lets say the next pseudocode

t1=currenttime

compare=hash1==hash2

t2=currenttime

interval=t2-t1 //(this value is always different)

No matter how many times you could run it, interval always returns a different value, no matter the conditions. And i am talking about a controlled machine, where the network latency is zero. Even a single comparison of interval between trivial operations is not the always the same 19:43, 14 October 2017 (UTC)201.241.84.134 (talk)

Even further, the results obtained look random. There is not a clear pattern. I found differences of over 300%, for the same operator running over and over.

We could conclude that the interval (and this number is the used for the attack) is based in the next formula:

interval = ${\tfrac {(NumberOfOperationsToExecute-NumberOfOerationsExecutedByOtherTask)*Factor}{NominalSpeedOfCpu}}$ (note: yay, wikipedia could writes fractions).

Where Factor is a value that could be variable depending of the cpu, memory and the system in general. For example, a cpu in a warm day could works slower than in a cold day. 20:03, 14 October 2017 (UTC)201.241.84.134 (talk)

Side-channel Speculative execution Timing attack

• Spectre was discovered independently by ...
• Meltdown was discovered independently by ...

These long-standing critical vulnerabilities in basic modern computing CPU technology were sudden discovered independently by multiple researchers in 2017, after lying dormant for over twenty years. Please add information about why these kinds of problems are just now being uncovered. Are there recent new approaches to looking for these?-73.61.15.235 (talk) 20:19, 5 January 2018 (UTC)