Talk:Timing attack

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Cryptography / Computer science   
WikiProject icon This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the quality scale.
 ???  This article has not yet received a rating on the importance scale.
Taskforce icon
This article is supported by WikiProject Computer science.
 

I added a lot[edit]

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?[edit]

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?[edit]

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?[edit]

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[edit]

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)