Talk:Side-channel attack

Scope of side channel attacks

I wonder why we don't use the general definition here. Actually, side channel attacks are attacks based on unintended output channels from a system. Such an attack could be launched against various systems including cryptographic implementations. For instance, T. Ristenpart showed in his 2009 paper that one can estimate the HTTP traffic rate of a web service by exploiting cache-based side channel. There are also several side channel attacks in the case of cloud storage services. All of these attacks are not launched against any cryptosystem implementation. So is the current definition adequate? ParadoXien (talk) 23:49, 30 August 2015 (UTC)

I think the article could use some revisions to widen the scope, since the recent Meltdown and Spectre attacks showed just how pervasive and fatal side-channel attacks on non-cryptographic systems can be. -- Phiarc (talk) 23:22, 5 January 2018 (UTC)

Why is it called "side channel"?

76.19.75.87 (talk) 07:00, 19 August 2010 (UTC)

Because it is "based on information gained from the physical implementation of a cryptosystem, rather than brute force or theoretical weaknesses in the algorithms (compare cryptanalysis).".84.152.61.223 (talk) 10:06, 1 November 2011 (UTC)

It comes from telecommunications jargon. A side channel or band is a input signal carrying transmission which is made because of some inherent property of a particular transmission medium. 67.61.170.124 (talk) 01:57, 23 December 2011 (UTC)

What constitutes a side-channel attack?

Matt, I was attempting here to briefly convey (or rather to briefly prevent the conveyance of the inverse) that a break due to a poorly designed crypto system or poor algorithm choice, not merely a mathematical break, are not instances of a side channel attack. Perhaps the confusion is due to insufficient willingness to rewrite?

I'll ponder for a bit and have another try. The category boundaries are worth deliniating I think, and what we have at present isn't very well distinguishing of those boundaries. ww 14:29, 7 Jul 2004 (UTC)

Yes, but don't mention the various distinctions quite thoroughly in the very next paragraph of the lead; surely that's sufficient? — Matt 14:52, 7 Jul 2004 (UTC)

Here's a hair to split: would the old "snoop traffic off a mini-hub's poorly designed status LED" trick qualify as a "side-channel" attack given that it is not a cryptographic system? Probably not. Might serve as a good introductory metaphor, however. (71.233.167.118 (talk) 05:04, 15 December 2010 (UTC))

I would say that

display-related TEMPEST attacks are not technically side-channel attacks, as they would typically reveal the decrypted data and not anything about the process of encryption (except a known-cyphertext, which falls under traditional cryptanalysis).

Also, what about those attacks where you bend or break the smart card and watch for/analyze errors? Are those side-channel attacks? —Preceding unsigned comment added by 216.106.175.189 (talk) 21:29, 17 May 2008 (UTC)

By and large, yep. Just random twiddling would be sort of pointless, but any repeatable would certainly be. ww (talk) 22:38, 17 May 2008 (UTC)

Random delays do not stop timing attacks?

A recent talk at Blackhat USA on timing attacks against OpenID and OAuth illustrated that random delays did not appear to act as a countermeasure and could be filtered out through the simple tactic of increasing the number of samples being analysed. The statement that timing attacks can be solved through random delays added to response times does not appear to hold true in all scenarios as a result. So is this statement factually false at this time? YouTube - Black Hat USA 2010: Exploiting Timing Attacks in Widespread Systems

86.42.129.22 (talk) 23:08, 5 October 2010 (UTC)

Comments on the update I just made

I just made a first pass at fixing numerous errors, e.g. timing attacks reveal keys (not just key lengths). As noted above, recommendations of fixes were completely (and dangerously) wrong, e.g. random delays do not prevent timing attacks. (An adversary can average multiple operations to remove the delays.) I reduced material on TEMPEST monitoring, and put this into more of a historical context, since side channel attacks refer to attacks on cryptosystems whilst TEMPEST monitoring is an eavesdropping attack with no particular cryptographic component. There were some stylistic fixes, e.g. removing phrases like "inescapable fact of life".

This article still has problems, e.g. a crazy number of references to a master's thesis by Spadavecchia instead of references to primary sources (e.g., Kocher's timing attack and DPA papers). It still needs more work, but it's a lot better than it was. —Preceding unsigned comment added by 76.201.169.157 (talk) 09:07, 5 November 2010 (UTC)

Ultrasonic sound and USB

• Two Amusing Side Channel Attacks October 26, 2011 .84.152.61.223 (talk) 10:05, 1 November 2011 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Side-channel attack. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20030503005825/http://csrc.nist.gov:80/encryption/aes/round1/conf2/papers/chari.pdf to http://csrc.nist.gov/encryption/aes/round1/conf2/papers/chari.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 14:33, 28 February 2016 (UTC)

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:17, 5 January 2018 (UTC)

Example needs more explanation

The example "An attempt to decode RSA key bits.." needs more details. I stared at it for a while and I still don't see what aspect of the signal an attacker is looking at. And what does it mean to say "allowing the attacker to read bits 0,1"? 198.206.219.131 (talk) 18:24, 4 November 2021 (UTC)