Cache-Timing Attacks on AES
2005 · paper · Computer science
Demonstrates recovery of a complete AES key from known-plaintext timings of a network server running OpenSSL. The author argues the weakness lies in AES's design, since fast constant-time AES software is extremely hard to write, and discusses the obstacles.
Checked: PDF from cr.yp.to, fetched 4 Oct 2026. Page numbers are those of that PDF.
3 findings
Substance Section 5 (p. 5) says "the server was listening for UDP packets on port 1000 of IP address 192.168.123.141", but the same server.c binds htons(10000), and Sections 4 and 6 say port 10000; it should read port 10000.
- p. 5 Section 5, sentence after the ./server command
listening for UDP packets on port 1000 of IP address
- p. 4 Section 4, second paragraph
packets sent to port 10000 of that IP address
- p. 9 Section 6, after the ./server command
listening for UDP packets sent to port 10000 of
- p. 27 Appendix A, server.c main()
server.sin_port = htons(10000);
Judge's note: I checked the page images. On p. 5 the text reads 'port 1000'. On p. 4 (Section 4) it reads 'port 10000', and on p. 9 (Section 6) it reads 'sent to port 10000'. On p. 27, Appendix A server.c has 'server.sin_port = htons(10000);', and the text layer shows htons(10000) twice more, in the Appendix B and C client code. Section 5 compiles and runs that same unmodified server.c (the gcc command on p. 5), and the port is hard-coded rather than given on the command line. So the server was on 10000, and 1000 is a dropped digit. Nothing in the paper explains the difference.
Second check: another model agreed · checked by hand
Report a problem with this finding
Substance In the b = 5 discussion of Figure 5.2 (p. 7), "the timings distinguish n[0] ⊕ {0, 1, 2, 3, 4, 5, 6, 7} from n[0] ⊕ i for all other i" names byte 0 where byte 5 (n[5]) is meant.
- p. 7 Section 5, paragraph below Fig. 5.2
distinguish n[0] ⊕ {0, 1, 2, 3, 4, 5, 6, 7} from n[0] ⊕ i for all other i
- p. 7
distinguish n[0] ⊕{0, 1, 2, 3, 4, 5, 6, 7} from n[0]
- p. 7 Section 5, same paragraph, preceding and following sentences
Figure 5.2 shows the time differences for b = 5
- p. 7 paragraph following Fig. 5.2
the timings distinguish n[0] ⊕{0, 1, 2, 3, 4, 5, 6, 7} from n[0] ⊕i for all other i
Judge's note: I checked the page 7 image. The paragraph opens with 'Figure 5.2 shows the time differences for b = 5' and quotes the correlations for that case. The sentence beginning 'in other words' then names n[0], and the next sentence concludes that the timings leak k[5] ⊕ {0,...,7}. The parallel sentence for b = 13 just above correctly says n[13]. The result for n[0] appears separately in the next paragraph's list. So the n[0] here is an index slip for n[5].
Second check: another model agreed
Report a problem with this finding
Substance The aes_ppro listing prints "eax &= 4096", but the stated effect ("esp[0],esp[1],...,esp[207] are just before the 2048-byte AES tables (aes_ppro_constants) modulo 4096") requires the mask 4095.
- p. 22 Section 14, aes_ppro listing
eax &= 4096
- p. 23 Section 14, text after the listing
are just before the 2048-byte AES tables (aes_ppro_constants) modulo 4096
- p. 23 text after listing
just before the 2048-byte AES tables (aes_ppro_constants) modulo 4096
- p. 22 text before listing
just below the beginning of the AES S-boxes modulo 4096
Judge's note: Page 22 image shows "eax &= 4096"; page 23 image shows the prose claim. With mask 4095, eax = ((esp - C) mod 4096) + 208, so the new esp is congruent to C - 208 modulo 4096 and the 208 stack bytes end just before the tables, as the prose says. With mask 4096 only bit 12 survives, eax is 208 or 4304, and the new esp is congruent to esp - 208 modulo 4096, which does not depend on the table address. The other operators in the listing (-=, +=) have their C meanings, so &= is a bitwise AND. The listing as printed contradicts the paper's own description; the fix (4095) is evident from the prose. The original source file is not in the files provided.
Second check: another model agreed · checked by hand
Report a problem with this finding
1 minor (typos and the like; most checked by the judge only)
Wording Text says the extra packet sizes "pinned down k[1], k[4], k[8], k[9], k[12], and k[13]", but the listing that follows shows two candidates for byte 13: "2 13 ec e3".
- p. 10 Section 6, sentence before the second output listing
down k[1], k[4], k[8], k[9], k[12], and k[13]:
- p. 10 Section 6, second output listing, last row
2 13 ec e3
- p. 10 text before final listing of Section 6
in particular pinned down k[1], k[4], k[8], k[9], k[12], and k[13]:
Judge's note: Page 10 image: the rows for bytes 4, 8, 12, 1 and 9 have count 1; the row for byte 13 has count 2 with candidates ec and e3. So k[13] is narrowed to two values, not pinned down, in the listing the sentence introduces. The final key does have ec at byte 13, and the search program resolves it, so this is loose wording only.
Second check: another model agreed