Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Timing attack
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Examples == The execution time for the [[square-and-multiply algorithm]] used in [[modular exponentiation]] depends linearly on the number of '1' bits in the key. While the number of '1' bits alone is not nearly enough information to make finding the key easy, repeated executions with the same key and different inputs can be used to perform statistical correlation analysis of timing information to recover the key completely, even by a passive attacker. Observed timing measurements often include noise (from such sources as network latency, or disk drive access differences from access to access, and the [[error correction]] techniques used to recover from transmission errors). Nevertheless, timing attacks are practical against a number of encryption algorithms, including [[RSA (algorithm)|RSA]], [[ElGamal encryption|ElGamal]], and the [[Digital Signature Algorithm]]. In 2003, [[Dan Boneh|Boneh]] and [[David Brumley|Brumley]] demonstrated a practical network-based timing attack on [[Secure Sockets Layer|SSL]]-enabled web servers, based on a different vulnerability having to do with the use of RSA with [[Chinese remainder theorem]] optimizations. The actual network distance was small in their experiments, but the attack successfully recovered a server private key in a matter of hours. This demonstration led to the widespread deployment and use of [[Blinding (cryptography)|blinding]] techniques in SSL implementations. In this context, blinding is intended to remove correlations between key and encryption time.<ref>David Brumley and Dan Boneh. [http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf Remote timing attacks are practical.] USENIX Security Symposium, August 2003.</ref> Some versions of [[Unix]] use a relatively expensive implementation of the ''crypt'' library function for hashing an 8-character password into an 11-character string. On older hardware, this computation took a deliberately and measurably long time: as much as two or three seconds in some cases.{{Citation needed|date=October 2012}} The ''login'' program in early versions of Unix executed the crypt function only when the login name was recognized by the system. This leaked information through timing about the validity of the login name, even when the password was incorrect. An attacker could exploit such leaks by first applying [[Brute-force attack|brute-force]] to produce a list of login names known to be valid, then attempt to gain access by combining only these names with a large set of passwords known to be frequently used. Without any information on the validity of login names the time needed to execute such an approach would increase by orders of magnitude, effectively rendering it useless. Later versions of Unix have fixed this leak by always executing the crypt function, regardless of login name validity.{{Citation needed|date=October 2012}} Two otherwise securely isolated processes running on a single system with either [[cache memory]] or [[virtual memory]] can communicate by deliberately causing [[page fault]]s and/or [[cache miss]]es in one process, then monitoring the resulting changes in access times from the other. Likewise, if an application is trusted, but its paging/caching is affected by branching logic, it may be possible for a second application to determine the values of the data compared to the branch condition by monitoring access time changes; in extreme examples, this can allow recovery of cryptographic key bits.<ref>See Percival, Colin, [http://www.daemonology.net/papers/htt.pdf Cache Missing for Fun and Profit], 2005.</ref><ref>Bernstein, Daniel J., [http://cr.yp.to/antiforgery/cachetiming-20050414.pdf Cache-timing attacks on AES], 2005.</ref> The 2017 [[Meltdown (security vulnerability)|Meltdown]] and [[Spectre (security vulnerability)|Spectre]] attacks which forced CPU manufacturers (including Intel, AMD, ARM, and IBM) to redesign their CPUs both rely on timing attacks.<ref>{{Cite web|url=https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html |title=Reading privileged memory with a side-channel |date=January 3, 2018 |author-first=Jann |author-last=Horn |publisher=googleprojectzero.blogspot.com}}</ref> As of early 2018, almost every computer system in the world is affected by Spectre.<ref>{{Cite web|url=https://spectreattack.com/#faq-systems-spectre|title=Spectre systems FAQ|website=Meltdown and Spectre}}</ref><ref>{{Cite news|url=https://www.reuters.com/article/us-cyber-intel-idUSKBN1ES1BO|title=Security flaws put virtually all phones, computers at risk|date=4 January 2018|work=Reuters}}</ref><ref>{{Cite web|url=https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/|title=Potential Impact on Processors in the POWER Family|date=14 May 2019|website=IBM PSIRT Blog}}</ref> Timing attacks are difficult to prevent and can often be used to extend other attacks. For example, in 2018, an old attack on RSA was rediscovered in a timing side-channel variant, two decades after the original bug.<ref>{{Cite web |last=Kario |first=Hubert |title=The Marvin Attack |url=https://people.redhat.com/~hkario/marvin/ |access-date=2023-12-19 |website=people.redhat.com |language=en}}</ref> === Algorithm === The following [[C (programming language)|C]] code demonstrates a typical insecure string comparison which stops testing as soon as a character doesn't match. For example, when comparing "ABCDE" with "ABxDE" it will return after 3 loop iterations: <syntaxhighlight lang="c"> bool insecureStringCompare(const void *a, const void *b, size_t length) { const char *ca = a, *cb = b; for (size_t i = 0; i < length; i++) if (ca[i] != cb[i]) return false; return true; } </syntaxhighlight> By comparison, the following version runs in constant-time by testing all characters and using a [[bitwise operation]] to accumulate the result: <syntaxhighlight lang="c"> bool constantTimeStringCompare(const void *a, const void *b, size_t length) { const char *ca = a, *cb = b; bool result = true; for (size_t i = 0; i < length; i++) result &= ca[i] == cb[i]; return result; } </syntaxhighlight> In the world of C library functions, the first function is analogous to {{code|memcmp()}}, while the latter is analogous to NetBSD's {{code|consttime_memequal()}} or<ref>{{Cite web|url=https://www.freebsd.org/cgi/man.cgi?query=consttime_memequal&manpath=NetBSD+7.0|title = Consttime_memequal}}</ref> OpenBSD's {{code|timingsafe_bcmp()}} and {{code|timingsafe_memcmp}}. On other systems, the comparison function from cryptographic libraries like [[OpenSSL]] and [[libsodium]] can be used.<!-- There should be a big flashy "don't roll your own crypto" paragraph here, but I have no idea how to phrase it. Whatever. -->
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)