SLIDE 1 Error-prone cryptographic designs Daniel J. Bernstein University of Illinois at Chicago & Technische Universiteit Eindhoven “The poor user is given enough rope with which to hang himself—something a standard should not do.” —1992 Rivest, commenting on nonce generation inside Digital Signature Algorithm (1991 proposal by NIST, 1992 credited to NSA, 1994 standardized by NIST) Crypto horror story #1 2010 Bushing–Marcan–Segher– Sven “failOverflow” demolition
- f Sony PS3 security system:
Sony had ignored requirement to generate new random nonce for each ECDSA signature. ⇒ Sony’s signatures leaked Sony’s secret code-signing key.
SLIDE 2 Error-prone cryptographic designs Daniel J. Bernstein University of Illinois at Chicago & Technische Universiteit Eindhoven “The poor user is given enough rope with which to hang himself—something a standard should not do.” —1992 Rivest, commenting on nonce generation inside Digital Signature Algorithm (1991 proposal by NIST, 1992 credited to NSA, 1994 standardized by NIST) Crypto horror story #1 2010 Bushing–Marcan–Segher– Sven “failOverflow” demolition
- f Sony PS3 security system:
Sony had ignored requirement to generate new random nonce for each ECDSA signature. ⇒ Sony’s signatures leaked Sony’s secret code-signing key. Traditional response: Blame Sony. Blame the crypto implementor.
SLIDE 3 Error-prone cryptographic designs Daniel J. Bernstein University of Illinois at Chicago & Technische Universiteit Eindhoven “The poor user is given enough rope with which to hang himself—something a standard should not do.” —1992 Rivest, commenting on nonce generation inside Digital Signature Algorithm (1991 proposal by NIST, 1992 credited to NSA, 1994 standardized by NIST) Crypto horror story #1 2010 Bushing–Marcan–Segher– Sven “failOverflow” demolition
- f Sony PS3 security system:
Sony had ignored requirement to generate new random nonce for each ECDSA signature. ⇒ Sony’s signatures leaked Sony’s secret code-signing key. Traditional response: Blame Sony. Blame the crypto implementor. Rivest’s response: Blame DSA. Blame the crypto designer.
SLIDE 4 Error-prone cryptographic designs Daniel J. Bernstein University of Illinois at Chicago & Technische Universiteit Eindhoven “The poor user is given enough rope with which to hang himself—something a standard should not do.” —1992 Rivest, commenting on nonce generation inside Digital Signature Algorithm (1991 proposal by NIST, 1992 credited to NSA, 1994 standardized by NIST) Crypto horror story #1 2010 Bushing–Marcan–Segher– Sven “failOverflow” demolition
- f Sony PS3 security system:
Sony had ignored requirement to generate new random nonce for each ECDSA signature. ⇒ Sony’s signatures leaked Sony’s secret code-signing key. Traditional response: Blame Sony. Blame the crypto implementor. Rivest’s response: Blame DSA. Blame the crypto designer. Change DSA to avoid this pitfall!
SLIDE 5 rone cryptographic designs
University of Illinois at Chicago & echnische Universiteit Eindhoven poor user is enough rope with which hang himself—something standard should not do.” —1992 Rivest, commenting on nonce generation Digital Signature Algorithm proposal by NIST, credited to NSA, standardized by NIST) Crypto horror story #1 2010 Bushing–Marcan–Segher– Sven “failOverflow” demolition
- f Sony PS3 security system:
Sony had ignored requirement to generate new random nonce for each ECDSA signature. ⇒ Sony’s signatures leaked Sony’s secret code-signing key. Traditional response: Blame Sony. Blame the crypto implementor. Rivest’s response: Blame DSA. Blame the crypto designer. Change DSA to avoid this pitfall! Crypto ho 2005 Osvik–Shamir–T 65ms to used for Attack p but without Almost all use fast Kernel’s influences influencing influencing
65ms to
SLIDE 6 cryptographic designs Bernstein Illinois at Chicago & Universiteit Eindhoven is rope with which himself—something should not do.” nonce generation Signature Algorithm y NIST, NSA, rdized by NIST) Crypto horror story #1 2010 Bushing–Marcan–Segher– Sven “failOverflow” demolition
- f Sony PS3 security system:
Sony had ignored requirement to generate new random nonce for each ECDSA signature. ⇒ Sony’s signatures leaked Sony’s secret code-signing key. Traditional response: Blame Sony. Blame the crypto implementor. Rivest’s response: Blame DSA. Blame the crypto designer. Change DSA to avoid this pitfall! Crypto horror story 2005 Osvik–Shamir–T 65ms to steal Linux used for hard-disk Attack process on but without privileges. Almost all AES implementations use fast lookup tables. Kernel’s secret AES influences table-load influencing CPU cache influencing measurable
65ms to compute influence
SLIDE 7 designs Chicago & Eindhoven which himself—something ” generation Algorithm NIST) Crypto horror story #1 2010 Bushing–Marcan–Segher– Sven “failOverflow” demolition
- f Sony PS3 security system:
Sony had ignored requirement to generate new random nonce for each ECDSA signature. ⇒ Sony’s signatures leaked Sony’s secret code-signing key. Traditional response: Blame Sony. Blame the crypto implementor. Rivest’s response: Blame DSA. Blame the crypto designer. Change DSA to avoid this pitfall! Crypto horror story #2 2005 Osvik–Shamir–Tromer: 65ms to steal Linux AES key used for hard-disk encryption. Attack process on same CPU but without privileges. Almost all AES implementations use fast lookup tables. Kernel’s secret AES key influences table-load addresses, influencing CPU cache state, influencing measurable timings
65ms to compute influence−
SLIDE 8 Crypto horror story #1 2010 Bushing–Marcan–Segher– Sven “failOverflow” demolition
- f Sony PS3 security system:
Sony had ignored requirement to generate new random nonce for each ECDSA signature. ⇒ Sony’s signatures leaked Sony’s secret code-signing key. Traditional response: Blame Sony. Blame the crypto implementor. Rivest’s response: Blame DSA. Blame the crypto designer. Change DSA to avoid this pitfall! Crypto horror story #2 2005 Osvik–Shamir–Tromer: 65ms to steal Linux AES key used for hard-disk encryption. Attack process on same CPU but without privileges. Almost all AES implementations use fast lookup tables. Kernel’s secret AES key influences table-load addresses, influencing CPU cache state, influencing measurable timings
65ms to compute influence−1.
SLIDE 9 horror story #1 Bushing–Marcan–Segher– “failOverflow” demolition Sony PS3 security system: had ignored requirement generate new random nonce h ECDSA signature. Sony’s signatures leaked secret code-signing key. raditional response: Blame Sony. Blame the crypto implementor. Rivest’s response: Blame DSA. Blame the crypto designer. Change DSA to avoid this pitfall! Crypto horror story #2 2005 Osvik–Shamir–Tromer: 65ms to steal Linux AES key used for hard-disk encryption. Attack process on same CPU but without privileges. Almost all AES implementations use fast lookup tables. Kernel’s secret AES key influences table-load addresses, influencing CPU cache state, influencing measurable timings
65ms to compute influence−1. 2012 Mo Shacham: data-cache x86 processo somehow physical memory programs
SLIDE 10 story #1 Bushing–Marcan–Segher– “failOverflow” demolition security system: red requirement random nonce signature. signatures leaked de-signing key.
crypto implementor.
crypto designer. avoid this pitfall! Crypto horror story #2 2005 Osvik–Shamir–Tromer: 65ms to steal Linux AES key used for hard-disk encryption. Attack process on same CPU but without privileges. Almost all AES implementations use fast lookup tables. Kernel’s secret AES key influences table-load addresses, influencing CPU cache state, influencing measurable timings
65ms to compute influence−1. 2012 Mowery–Keelveedhi– Shacham: “We posit data-cache timing x86 processors that somehow subvert the physical indexing, memory requirements programs is doomed
SLIDE 11 rcan–Segher– demolition m: requirement nonce signature. ed key. Blame Sony. implementor. DSA. designer. pitfall! Crypto horror story #2 2005 Osvik–Shamir–Tromer: 65ms to steal Linux AES key used for hard-disk encryption. Attack process on same CPU but without privileges. Almost all AES implementations use fast lookup tables. Kernel’s secret AES key influences table-load addresses, influencing CPU cache state, influencing measurable timings
65ms to compute influence−1. 2012 Mowery–Keelveedhi– Shacham: “We posit that any data-cache timing attack against x86 processors that does not somehow subvert the prefetcher, physical indexing, and massive memory requirements of modern programs is doomed to fail.”
SLIDE 12 Crypto horror story #2 2005 Osvik–Shamir–Tromer: 65ms to steal Linux AES key used for hard-disk encryption. Attack process on same CPU but without privileges. Almost all AES implementations use fast lookup tables. Kernel’s secret AES key influences table-load addresses, influencing CPU cache state, influencing measurable timings
65ms to compute influence−1. 2012 Mowery–Keelveedhi– Shacham: “We posit that any data-cache timing attack against x86 processors that does not somehow subvert the prefetcher, physical indexing, and massive memory requirements of modern programs is doomed to fail.”
SLIDE 13 Crypto horror story #2 2005 Osvik–Shamir–Tromer: 65ms to steal Linux AES key used for hard-disk encryption. Attack process on same CPU but without privileges. Almost all AES implementations use fast lookup tables. Kernel’s secret AES key influences table-load addresses, influencing CPU cache state, influencing measurable timings
65ms to compute influence−1. 2012 Mowery–Keelveedhi– Shacham: “We posit that any data-cache timing attack against x86 processors that does not somehow subvert the prefetcher, physical indexing, and massive memory requirements of modern programs is doomed to fail.” 2014 Irazoqui–Inci–Eisenbarth– Sunar “Wait a minute! A fast, Cross-VM attack on AES” recovers “the AES keys
- f OpenSSL 1.0.1 running inside
the victim VM” in 60 seconds despite VMware virtualization.
SLIDE 14 horror story #2 Osvik–Shamir–Tromer: to steal Linux AES key for hard-disk encryption. process on same CPU without privileges. Almost all AES implementations fast lookup tables. Kernel’s secret AES key influences table-load addresses, influencing CPU cache state, influencing measurable timings attack process. to compute influence−1. 2012 Mowery–Keelveedhi– Shacham: “We posit that any data-cache timing attack against x86 processors that does not somehow subvert the prefetcher, physical indexing, and massive memory requirements of modern programs is doomed to fail.” 2014 Irazoqui–Inci–Eisenbarth– Sunar “Wait a minute! A fast, Cross-VM attack on AES” recovers “the AES keys
- f OpenSSL 1.0.1 running inside
the victim VM” in 60 seconds despite VMware virtualization. After many
today we plagued Warning:
SLIDE 15 story #2 Osvik–Shamir–Tromer: Linux AES key rd-disk encryption.
rivileges. implementations tables. AES key table-load addresses, cache state, measurable timings cess. compute influence−1. 2012 Mowery–Keelveedhi– Shacham: “We posit that any data-cache timing attack against x86 processors that does not somehow subvert the prefetcher, physical indexing, and massive memory requirements of modern programs is doomed to fail.” 2014 Irazoqui–Inci–Eisenbarth– Sunar “Wait a minute! A fast, Cross-VM attack on AES” recovers “the AES keys
- f OpenSSL 1.0.1 running inside
the victim VM” in 60 seconds despite VMware virtualization. After many, many,
today we still have plagued with AES Warning: more pap
SLIDE 16 romer: ey encryption. CPU implementations addresses, state, timings influence−1. 2012 Mowery–Keelveedhi– Shacham: “We posit that any data-cache timing attack against x86 processors that does not somehow subvert the prefetcher, physical indexing, and massive memory requirements of modern programs is doomed to fail.” 2014 Irazoqui–Inci–Eisenbarth– Sunar “Wait a minute! A fast, Cross-VM attack on AES” recovers “the AES keys
- f OpenSSL 1.0.1 running inside
the victim VM” in 60 seconds despite VMware virtualization. After many, many, many pap
- n implementations and attacks,
today we still have an ecosystem plagued with AES vulnerabilities. Warning: more papers = securit
SLIDE 17 2012 Mowery–Keelveedhi– Shacham: “We posit that any data-cache timing attack against x86 processors that does not somehow subvert the prefetcher, physical indexing, and massive memory requirements of modern programs is doomed to fail.” 2014 Irazoqui–Inci–Eisenbarth– Sunar “Wait a minute! A fast, Cross-VM attack on AES” recovers “the AES keys
- f OpenSSL 1.0.1 running inside
the victim VM” in 60 seconds despite VMware virtualization. After many, many, many papers
- n implementations and attacks,
today we still have an ecosystem plagued with AES vulnerabilities. Warning: more papers = security.
SLIDE 18 2012 Mowery–Keelveedhi– Shacham: “We posit that any data-cache timing attack against x86 processors that does not somehow subvert the prefetcher, physical indexing, and massive memory requirements of modern programs is doomed to fail.” 2014 Irazoqui–Inci–Eisenbarth– Sunar “Wait a minute! A fast, Cross-VM attack on AES” recovers “the AES keys
- f OpenSSL 1.0.1 running inside
the victim VM” in 60 seconds despite VMware virtualization. After many, many, many papers
- n implementations and attacks,
today we still have an ecosystem plagued with AES vulnerabilities. Warning: more papers = security. AES has a serious conflict between security, simplicity, speed. It’s tough to achieve security while insisting on the AES design —i.e., blaming the implementor.
SLIDE 19 2012 Mowery–Keelveedhi– Shacham: “We posit that any data-cache timing attack against x86 processors that does not somehow subvert the prefetcher, physical indexing, and massive memory requirements of modern programs is doomed to fail.” 2014 Irazoqui–Inci–Eisenbarth– Sunar “Wait a minute! A fast, Cross-VM attack on AES” recovers “the AES keys
- f OpenSSL 1.0.1 running inside
the victim VM” in 60 seconds despite VMware virtualization. After many, many, many papers
- n implementations and attacks,
today we still have an ecosystem plagued with AES vulnerabilities. Warning: more papers = security. AES has a serious conflict between security, simplicity, speed. It’s tough to achieve security while insisting on the AES design —i.e., blaming the implementor. Allowing the design to vary makes security much easier. Next-generation ciphers are naturally constant-time and fast.
SLIDE 20 Mowery–Keelveedhi– Shacham: “We posit that any data-cache timing attack against rocessors that does not somehow subvert the prefetcher, physical indexing, and massive ry requirements of modern rograms is doomed to fail.” Irazoqui–Inci–Eisenbarth– “Wait a minute! A fast, Cross-VM attack on AES” recovers “the AES keys enSSL 1.0.1 running inside victim VM” in 60 seconds despite VMware virtualization. After many, many, many papers
- n implementations and attacks,
today we still have an ecosystem plagued with AES vulnerabilities. Warning: more papers = security. AES has a serious conflict between security, simplicity, speed. It’s tough to achieve security while insisting on the AES design —i.e., blaming the implementor. Allowing the design to vary makes security much easier. Next-generation ciphers are naturally constant-time and fast. The big Crypto designs
implementations
SLIDE 21 ery–Keelveedhi– posit that any timing attack against that does not subvert the prefetcher, indexing, and massive requirements of modern
qui–Inci–Eisenbarth– minute! A fast, attack on AES” AES keys 1.0.1 running inside in 60 seconds virtualization. After many, many, many papers
- n implementations and attacks,
today we still have an ecosystem plagued with AES vulnerabilities. Warning: more papers = security. AES has a serious conflict between security, simplicity, speed. It’s tough to achieve security while insisting on the AES design —i.e., blaming the implementor. Allowing the design to vary makes security much easier. Next-generation ciphers are naturally constant-time and fast. The big picture Crypto designs more complexit less review more attacks less secur
implementations
SLIDE 22 any against not fetcher, massive modern fail.” qui–Inci–Eisenbarth– fast, inside seconds virtualization. After many, many, many papers
- n implementations and attacks,
today we still have an ecosystem plagued with AES vulnerabilities. Warning: more papers = security. AES has a serious conflict between security, simplicity, speed. It’s tough to achieve security while insisting on the AES design —i.e., blaming the implementor. Allowing the design to vary makes security much easier. Next-generation ciphers are naturally constant-time and fast. The big picture Crypto designs more complexity less review more attacks less security
implementations
SLIDE 23 After many, many, many papers
- n implementations and attacks,
today we still have an ecosystem plagued with AES vulnerabilities. Warning: more papers = security. AES has a serious conflict between security, simplicity, speed. It’s tough to achieve security while insisting on the AES design —i.e., blaming the implementor. Allowing the design to vary makes security much easier. Next-generation ciphers are naturally constant-time and fast. The big picture Crypto designs more complexity less review more attacks less security
implementations
SLIDE 24 After many, many, many papers
- n implementations and attacks,
today we still have an ecosystem plagued with AES vulnerabilities. Warning: more papers = security. AES has a serious conflict between security, simplicity, speed. It’s tough to achieve security while insisting on the AES design —i.e., blaming the implementor. Allowing the design to vary makes security much easier. Next-generation ciphers are naturally constant-time and fast. The big picture Primitive designs more complexity less review more attacks less security
implementations
designs more complexity less review more attacks less security
implementations
SLIDE 25 many, many, many papers implementations and attacks, we still have an ecosystem plagued with AES vulnerabilities. rning: more papers = security. has a serious conflict een security, simplicity, speed. tough to achieve security insisting on the AES design blaming the implementor. wing the design to vary security much easier. Next-generation ciphers are naturally constant-time and fast. The big picture Primitive designs more complexity less review more attacks less security
implementations
designs more complexity less review more attacks less security
implementations Public review towards ignoring protocols There’s much
than of ECDSA
SLIDE 26 many, many papers implementations and attacks, have an ecosystem AES vulnerabilities. papers = security. serious conflict , simplicity, speed. achieve security
the implementor. design to vary much easier. ciphers are constant-time and fast. The big picture Primitive designs more complexity less review more attacks less security
implementations
designs more complexity less review more attacks less security
implementations Public review is naturally towards the simplest ignoring complication protocols and implementations. There’s much more
than of ECDSA signatures.
SLIDE 27 papers attacks, ecosystem vulnerabilities. security. y, speed. security design implementor. ry easier. re and fast. The big picture Primitive designs more complexity less review more attacks less security
implementations
designs more complexity less review more attacks less security
implementations Public review is naturally biased towards the simplest targets, ignoring complications of protocols and implementations. There’s much more public re
- f, e.g., discrete logarithms
than of ECDSA signatures.
SLIDE 28 The big picture Primitive designs more complexity less review more attacks less security
implementations
designs more complexity less review more attacks less security
implementations Public review is naturally biased towards the simplest targets, ignoring complications of protocols and implementations. There’s much more public review
- f, e.g., discrete logarithms
than of ECDSA signatures.
SLIDE 29 The big picture Primitive designs more complexity less review more attacks less security
implementations
designs more complexity less review more attacks less security
implementations Public review is naturally biased towards the simplest targets, ignoring complications of protocols and implementations. There’s much more public review
- f, e.g., discrete logarithms
than of ECDSA signatures. There’s much more public review
than of ECDSA implementations.
SLIDE 30 The big picture Primitive designs more complexity less review more attacks less security
implementations
designs more complexity less review more attacks less security
implementations Public review is naturally biased towards the simplest targets, ignoring complications of protocols and implementations. There’s much more public review
- f, e.g., discrete logarithms
than of ECDSA signatures. There’s much more public review
than of ECDSA implementations. There’s much more public review
than of ECDSA applications.
SLIDE 31 big picture Primitive designs more complexity less review more attacks less security
implementations
designs more complexity less review more attacks less security
implementations Public review is naturally biased towards the simplest targets, ignoring complications of protocols and implementations. There’s much more public review
- f, e.g., discrete logarithms
than of ECDSA signatures. There’s much more public review
than of ECDSA implementations. There’s much more public review
than of ECDSA applications. What ab The fundamental
Prove that is as secure i.e.: Prove is as secure Prove that is as secure Then it’s to focus
SLIDE 32 complexity review attacks security
designs complexity less review re attacks security
implementations Public review is naturally biased towards the simplest targets, ignoring complications of protocols and implementations. There’s much more public review
- f, e.g., discrete logarithms
than of ECDSA signatures. There’s much more public review
than of ECDSA implementations. There’s much more public review
than of ECDSA applications. What about securit The fundamental goal
Prove that the whole is as secure as the i.e.: Prove that the is as secure as the Prove that the implementation is as secure as the Then it’s safe for review to focus on the primitive
SLIDE 33
designs y
implementations Public review is naturally biased towards the simplest targets, ignoring complications of protocols and implementations. There’s much more public review
- f, e.g., discrete logarithms
than of ECDSA signatures. There’s much more public review
than of ECDSA implementations. There’s much more public review
than of ECDSA applications. What about security proofs? The fundamental goal
Prove that the whole system is as secure as the primitive. i.e.: Prove that the protocol is as secure as the primitive. Prove that the implementation is as secure as the design. Then it’s safe for reviewers to focus on the primitive design.
SLIDE 34 Public review is naturally biased towards the simplest targets, ignoring complications of protocols and implementations. There’s much more public review
- f, e.g., discrete logarithms
than of ECDSA signatures. There’s much more public review
than of ECDSA implementations. There’s much more public review
than of ECDSA applications. What about security proofs? The fundamental goal
Prove that the whole system is as secure as the primitive. i.e.: Prove that the protocol is as secure as the primitive. Prove that the implementation is as secure as the design. Then it’s safe for reviewers to focus on the primitive design.
SLIDE 35 Public review is naturally biased towards the simplest targets, ignoring complications of protocols and implementations. There’s much more public review
- f, e.g., discrete logarithms
than of ECDSA signatures. There’s much more public review
than of ECDSA implementations. There’s much more public review
than of ECDSA applications. What about security proofs? The fundamental goal
Prove that the whole system is as secure as the primitive. i.e.: Prove that the protocol is as secure as the primitive. Prove that the implementation is as secure as the design. Then it’s safe for reviewers to focus on the primitive design. Maybe will succeed someday, but needs to overcome huge problems.
SLIDE 36 review is naturally biased rds the simplest targets, ring complications of cols and implementations. There’s much more public review e.g., discrete logarithms
There’s much more public review ECDSA design
There’s much more public review ECDSA implementations
What about security proofs? The fundamental goal
Prove that the whole system is as secure as the primitive. i.e.: Prove that the protocol is as secure as the primitive. Prove that the implementation is as secure as the design. Then it’s safe for reviewers to focus on the primitive design. Maybe will succeed someday, but needs to overcome huge problems. Problem Proofs are rarely review
SLIDE 37 naturally biased simplest targets,
implementations. more public review logarithms signatures. more public review design implementations. more public review implementations applications. What about security proofs? The fundamental goal
Prove that the whole system is as secure as the primitive. i.e.: Prove that the protocol is as secure as the primitive. Prove that the implementation is as secure as the design. Then it’s safe for reviewers to focus on the primitive design. Maybe will succeed someday, but needs to overcome huge problems. Problem 1: “Proofs” Proofs are increasingly rarely reviewed, rarely
SLIDE 38 biased rgets, implementations. review rithms signatures. review implementations. review implementations applications. What about security proofs? The fundamental goal
Prove that the whole system is as secure as the primitive. i.e.: Prove that the protocol is as secure as the primitive. Prove that the implementation is as secure as the design. Then it’s safe for reviewers to focus on the primitive design. Maybe will succeed someday, but needs to overcome huge problems. Problem 1: “Proofs” have erro Proofs are increasingly complex, rarely reviewed, rarely automated.
SLIDE 39 What about security proofs? The fundamental goal
Prove that the whole system is as secure as the primitive. i.e.: Prove that the protocol is as secure as the primitive. Prove that the implementation is as secure as the design. Then it’s safe for reviewers to focus on the primitive design. Maybe will succeed someday, but needs to overcome huge problems. Problem 1: “Proofs” have errors. Proofs are increasingly complex, rarely reviewed, rarely automated.
SLIDE 40 What about security proofs? The fundamental goal
Prove that the whole system is as secure as the primitive. i.e.: Prove that the protocol is as secure as the primitive. Prove that the implementation is as secure as the design. Then it’s safe for reviewers to focus on the primitive design. Maybe will succeed someday, but needs to overcome huge problems. Problem 1: “Proofs” have errors. Proofs are increasingly complex, rarely reviewed, rarely automated. Problem 2: Most proofs are of security bounds that aren’t tight: e.g. forking-lemma “security” is pure deception for typical sizes.
SLIDE 41 What about security proofs? The fundamental goal
Prove that the whole system is as secure as the primitive. i.e.: Prove that the protocol is as secure as the primitive. Prove that the implementation is as secure as the design. Then it’s safe for reviewers to focus on the primitive design. Maybe will succeed someday, but needs to overcome huge problems. Problem 1: “Proofs” have errors. Proofs are increasingly complex, rarely reviewed, rarely automated. Problem 2: Most proofs are of security bounds that aren’t tight: e.g. forking-lemma “security” is pure deception for typical sizes. Problem 3: “Security” definitions prioritize simplicity over accuracy. e.g. is MAC-pad-encrypt secure?
SLIDE 42 What about security proofs? The fundamental goal
Prove that the whole system is as secure as the primitive. i.e.: Prove that the protocol is as secure as the primitive. Prove that the implementation is as secure as the design. Then it’s safe for reviewers to focus on the primitive design. Maybe will succeed someday, but needs to overcome huge problems. Problem 1: “Proofs” have errors. Proofs are increasingly complex, rarely reviewed, rarely automated. Problem 2: Most proofs are of security bounds that aren’t tight: e.g. forking-lemma “security” is pure deception for typical sizes. Problem 3: “Security” definitions prioritize simplicity over accuracy. e.g. is MAC-pad-encrypt secure? Problem 4: Maybe the only way to achieve the fundamental goal is to switch to weak primitives.
SLIDE 43
about security proofs? fundamental goal rovable security”: that the whole system secure as the primitive. Prove that the protocol secure as the primitive. that the implementation secure as the design. it’s safe for reviewers cus on the primitive design. will succeed someday, but to overcome huge problems. Problem 1: “Proofs” have errors. Proofs are increasingly complex, rarely reviewed, rarely automated. Problem 2: Most proofs are of security bounds that aren’t tight: e.g. forking-lemma “security” is pure deception for typical sizes. Problem 3: “Security” definitions prioritize simplicity over accuracy. e.g. is MAC-pad-encrypt secure? Problem 4: Maybe the only way to achieve the fundamental goal is to switch to weak primitives. Some advice Creating Think ab implementations. What will What erro to appea Can you
SLIDE 44 security proofs? fundamental goal security”: whole system the primitive. the protocol the primitive. implementation the design. r reviewers primitive design. succeed someday, but
Problem 1: “Proofs” have errors. Proofs are increasingly complex, rarely reviewed, rarely automated. Problem 2: Most proofs are of security bounds that aren’t tight: e.g. forking-lemma “security” is pure deception for typical sizes. Problem 3: “Security” definitions prioritize simplicity over accuracy. e.g. is MAC-pad-encrypt secure? Problem 4: Maybe the only way to achieve the fundamental goal is to switch to weak primitives. Some advice to crypto Creating or evaluating Think about the implementations. What will the implemento What errors are lik to appear in implementations? Can you compensate
SLIDE 45
system rimitive. col rimitive. implementation ers design. someday, but roblems. Problem 1: “Proofs” have errors. Proofs are increasingly complex, rarely reviewed, rarely automated. Problem 2: Most proofs are of security bounds that aren’t tight: e.g. forking-lemma “security” is pure deception for typical sizes. Problem 3: “Security” definitions prioritize simplicity over accuracy. e.g. is MAC-pad-encrypt secure? Problem 4: Maybe the only way to achieve the fundamental goal is to switch to weak primitives. Some advice to crypto designers Creating or evaluating a design? Think about the implementations. What will the implementors What errors are likely to appear in implementations? Can you compensate for this?
SLIDE 46
Problem 1: “Proofs” have errors. Proofs are increasingly complex, rarely reviewed, rarely automated. Problem 2: Most proofs are of security bounds that aren’t tight: e.g. forking-lemma “security” is pure deception for typical sizes. Problem 3: “Security” definitions prioritize simplicity over accuracy. e.g. is MAC-pad-encrypt secure? Problem 4: Maybe the only way to achieve the fundamental goal is to switch to weak primitives. Some advice to crypto designers Creating or evaluating a design? Think about the implementations. What will the implementors do? What errors are likely to appear in implementations? Can you compensate for this?
SLIDE 47
Problem 1: “Proofs” have errors. Proofs are increasingly complex, rarely reviewed, rarely automated. Problem 2: Most proofs are of security bounds that aren’t tight: e.g. forking-lemma “security” is pure deception for typical sizes. Problem 3: “Security” definitions prioritize simplicity over accuracy. e.g. is MAC-pad-encrypt secure? Problem 4: Maybe the only way to achieve the fundamental goal is to switch to weak primitives. Some advice to crypto designers Creating or evaluating a design? Think about the implementations. What will the implementors do? What errors are likely to appear in implementations? Can you compensate for this? Is the design a primitive? Think about the protocols. Is the design a protocol? Think about the higher-level protocols. Will the system be secure?
SLIDE 48
Problem 1: “Proofs” have errors. are increasingly complex, reviewed, rarely automated. Problem 2: Most proofs are of y bounds that aren’t tight: rking-lemma “security” deception for typical sizes. Problem 3: “Security” definitions ritize simplicity over accuracy. MAC-pad-encrypt secure? Problem 4: Maybe the only way achieve the fundamental goal switch to weak primitives. Some advice to crypto designers Creating or evaluating a design? Think about the implementations. What will the implementors do? What errors are likely to appear in implementations? Can you compensate for this? Is the design a primitive? Think about the protocols. Is the design a protocol? Think about the higher-level protocols. Will the system be secure? Crypto ho HTTPS.
SLIDE 49
increasingly complex, rarely automated. Most proofs are of that aren’t tight: mma “security” for typical sizes. “Security” definitions simplicity over accuracy. C-pad-encrypt secure? ybe the only way fundamental goal eak primitives. Some advice to crypto designers Creating or evaluating a design? Think about the implementations. What will the implementors do? What errors are likely to appear in implementations? Can you compensate for this? Is the design a primitive? Think about the protocols. Is the design a protocol? Think about the higher-level protocols. Will the system be secure? Crypto horror story HTTPS.
SLIDE 50 errors. complex, automated. re of ren’t tight: “security” ypical sizes. definitions accuracy. secure?
fundamental goal rimitives. Some advice to crypto designers Creating or evaluating a design? Think about the implementations. What will the implementors do? What errors are likely to appear in implementations? Can you compensate for this? Is the design a primitive? Think about the protocols. Is the design a protocol? Think about the higher-level protocols. Will the system be secure? Crypto horror story #3 HTTPS.
SLIDE 51
Some advice to crypto designers Creating or evaluating a design? Think about the implementations. What will the implementors do? What errors are likely to appear in implementations? Can you compensate for this? Is the design a primitive? Think about the protocols. Is the design a protocol? Think about the higher-level protocols. Will the system be secure? Crypto horror story #3 HTTPS.
SLIDE 52
Some advice to crypto designers Creating or evaluating a design? Think about the implementations. What will the implementors do? What errors are likely to appear in implementations? Can you compensate for this? Is the design a primitive? Think about the protocols. Is the design a protocol? Think about the higher-level protocols. Will the system be secure? Crypto horror story #3 HTTPS. letsencrypt.org is a huge improvement in HTTPS usability; will obviously be widely used. But is HTTPS actually secure?
SLIDE 53
Some advice to crypto designers Creating or evaluating a design? Think about the implementations. What will the implementors do? What errors are likely to appear in implementations? Can you compensate for this? Is the design a primitive? Think about the protocols. Is the design a protocol? Think about the higher-level protocols. Will the system be secure? Crypto horror story #3 HTTPS. letsencrypt.org is a huge improvement in HTTPS usability; will obviously be widely used. But is HTTPS actually secure? “It’s not so bad against passive eavesdroppers!” —The eavesdroppers will start forging (more) packets.
SLIDE 54
Some advice to crypto designers Creating or evaluating a design? Think about the implementations. What will the implementors do? What errors are likely to appear in implementations? Can you compensate for this? Is the design a primitive? Think about the protocols. Is the design a protocol? Think about the higher-level protocols. Will the system be secure? Crypto horror story #3 HTTPS. letsencrypt.org is a huge improvement in HTTPS usability; will obviously be widely used. But is HTTPS actually secure? “It’s not so bad against passive eavesdroppers!” —The eavesdroppers will start forging (more) packets. “Then we’ll know they’re there!” —Yes, we knew that already. What we want is security.
SLIDE 55 advice to crypto designers Creating or evaluating a design? about the implementations. will the implementors do? errors are likely ear in implementations?
design a primitive? about the protocols. design a protocol? about the higher-level protocols. the system be secure? Crypto horror story #3 HTTPS. letsencrypt.org is a huge improvement in HTTPS usability; will obviously be widely used. But is HTTPS actually secure? “It’s not so bad against passive eavesdroppers!” —The eavesdroppers will start forging (more) packets. “Then we’ll know they’re there!” —Yes, we knew that already. What we want is security. 2013.01 State-of-the-a are obviou e.g. Defense requires assumption”
SLIDE 56
crypto designers evaluating a design? the implementations. implementors do? likely implementations? ensate for this? rimitive? the protocols. rotocol? the rotocols. be secure? Crypto horror story #3 HTTPS. letsencrypt.org is a huge improvement in HTTPS usability; will obviously be widely used. But is HTTPS actually secure? “It’s not so bad against passive eavesdroppers!” —The eavesdroppers will start forging (more) packets. “Then we’ll know they’re there!” —Yes, we knew that already. What we want is security. 2013.01 Green: State-of-the-art TLS are obviously unsatisfacto e.g. Defense vs. Bleichenbacher requires “goofy made-up assumption” for pro
SLIDE 57
designers design? rs do? implementations? this? cols. Crypto horror story #3 HTTPS. letsencrypt.org is a huge improvement in HTTPS usability; will obviously be widely used. But is HTTPS actually secure? “It’s not so bad against passive eavesdroppers!” —The eavesdroppers will start forging (more) packets. “Then we’ll know they’re there!” —Yes, we knew that already. What we want is security. 2013.01 Green: State-of-the-art TLS proofs are obviously unsatisfactory. e.g. Defense vs. Bleichenbacher requires “goofy made-up assumption” for proof.
SLIDE 58
Crypto horror story #3 HTTPS. letsencrypt.org is a huge improvement in HTTPS usability; will obviously be widely used. But is HTTPS actually secure? “It’s not so bad against passive eavesdroppers!” —The eavesdroppers will start forging (more) packets. “Then we’ll know they’re there!” —Yes, we knew that already. What we want is security. 2013.01 Green: State-of-the-art TLS proofs are obviously unsatisfactory. e.g. Defense vs. Bleichenbacher requires “goofy made-up assumption” for proof.
SLIDE 59
Crypto horror story #3 HTTPS. letsencrypt.org is a huge improvement in HTTPS usability; will obviously be widely used. But is HTTPS actually secure? “It’s not so bad against passive eavesdroppers!” —The eavesdroppers will start forging (more) packets. “Then we’ll know they’re there!” —Yes, we knew that already. What we want is security. 2013.01 Green: State-of-the-art TLS proofs are obviously unsatisfactory. e.g. Defense vs. Bleichenbacher requires “goofy made-up assumption” for proof. But that was “the good news : : : The problem with TLS is that we are cursed with implementations.” e.g. Defense vs. Bleichenbacher is in wrong order in OpenSSL. Does this allow timing attacks?
SLIDE 60 horror story #3 HTTPS. letsencrypt.org is a huge rovement in HTTPS usability;
HTTPS actually secure? not so bad against passive eavesdroppers!” eavesdroppers will start (more) packets. we’ll know they’re there!” we knew that already. we want is security. 2013.01 Green: State-of-the-art TLS proofs are obviously unsatisfactory. e.g. Defense vs. Bleichenbacher requires “goofy made-up assumption” for proof. But that was “the good news : : : The problem with TLS is that we are cursed with implementations.” e.g. Defense vs. Bleichenbacher is in wrong order in OpenSSL. Does this allow timing attacks? 2014.08 Weiss–Schw Successful exploiting variations NITROX
SLIDE 61
story #3 letsencrypt.org is a huge HTTPS usability; widely used. actually secure? eavesdroppers!” eavesdroppers will start packets. w they’re there!” that already. is security. 2013.01 Green: State-of-the-art TLS proofs are obviously unsatisfactory. e.g. Defense vs. Bleichenbacher requires “goofy made-up assumption” for proof. But that was “the good news : : : The problem with TLS is that we are cursed with implementations.” e.g. Defense vs. Bleichenbacher is in wrong order in OpenSSL. Does this allow timing attacks? 2014.08 Meyer–Somo Weiss–Schwenk–Schin Successful Bleichenbacher exploiting analogous variations in Java SSE, NITROX SSL accelerato
SLIDE 62
huge usability; used. secure? ers!” start there!” already. 2013.01 Green: State-of-the-art TLS proofs are obviously unsatisfactory. e.g. Defense vs. Bleichenbacher requires “goofy made-up assumption” for proof. But that was “the good news : : : The problem with TLS is that we are cursed with implementations.” e.g. Defense vs. Bleichenbacher is in wrong order in OpenSSL. Does this allow timing attacks? 2014.08 Meyer–Somorovsky– Weiss–Schwenk–Schinzel–Tews: Successful Bleichenbacher attacks, exploiting analogous timing variations in Java SSE, Cavium NITROX SSL accelerator chip.
SLIDE 63
2013.01 Green: State-of-the-art TLS proofs are obviously unsatisfactory. e.g. Defense vs. Bleichenbacher requires “goofy made-up assumption” for proof. But that was “the good news : : : The problem with TLS is that we are cursed with implementations.” e.g. Defense vs. Bleichenbacher is in wrong order in OpenSSL. Does this allow timing attacks? 2014.08 Meyer–Somorovsky– Weiss–Schwenk–Schinzel–Tews: Successful Bleichenbacher attacks, exploiting analogous timing variations in Java SSE, Cavium NITROX SSL accelerator chip.
SLIDE 64
2013.01 Green: State-of-the-art TLS proofs are obviously unsatisfactory. e.g. Defense vs. Bleichenbacher requires “goofy made-up assumption” for proof. But that was “the good news : : : The problem with TLS is that we are cursed with implementations.” e.g. Defense vs. Bleichenbacher is in wrong order in OpenSSL. Does this allow timing attacks? 2014.08 Meyer–Somorovsky– Weiss–Schwenk–Schinzel–Tews: Successful Bleichenbacher attacks, exploiting analogous timing variations in Java SSE, Cavium NITROX SSL accelerator chip. The whole concept of a “public-key cryptosystem” is a historical accident, dangerously unauthenticated.
SLIDE 65
2013.01 Green: State-of-the-art TLS proofs are obviously unsatisfactory. e.g. Defense vs. Bleichenbacher requires “goofy made-up assumption” for proof. But that was “the good news : : : The problem with TLS is that we are cursed with implementations.” e.g. Defense vs. Bleichenbacher is in wrong order in OpenSSL. Does this allow timing attacks? 2014.08 Meyer–Somorovsky– Weiss–Schwenk–Schinzel–Tews: Successful Bleichenbacher attacks, exploiting analogous timing variations in Java SSE, Cavium NITROX SSL accelerator chip. The whole concept of a “public-key cryptosystem” is a historical accident, dangerously unauthenticated. Do we seriously believe that we’ll make HTTPS secure by fixing the implementations? Fix the bad crypto design.
SLIDE 66 2013.01 Green: State-of-the-art TLS proofs
Defense vs. Bleichenbacher requires “goofy made-up assumption” for proof. that was “the good : : The problem with that we are cursed with implementations.” Defense vs. Bleichenbacher wrong order in OpenSSL. this allow timing attacks? 2014.08 Meyer–Somorovsky– Weiss–Schwenk–Schinzel–Tews: Successful Bleichenbacher attacks, exploiting analogous timing variations in Java SSE, Cavium NITROX SSL accelerator chip. The whole concept of a “public-key cryptosystem” is a historical accident, dangerously unauthenticated. Do we seriously believe that we’ll make HTTPS secure by fixing the implementations? Fix the bad crypto design. Exercise: failures can Renegotiation Diginota BEAST Trustwave CRIME comp Lucky 13 RC4 keystream TLS truncation. gotofail signature-verification Triple Handshak Heartbleed POODLE Winshock
SLIDE 67
TLS proofs unsatisfactory. Bleichenbacher made-up proof. “the good roblem with re cursed with .” Bleichenbacher rder in OpenSSL. timing attacks? 2014.08 Meyer–Somorovsky– Weiss–Schwenk–Schinzel–Tews: Successful Bleichenbacher attacks, exploiting analogous timing variations in Java SSE, Cavium NITROX SSL accelerator chip. The whole concept of a “public-key cryptosystem” is a historical accident, dangerously unauthenticated. Do we seriously believe that we’ll make HTTPS secure by fixing the implementations? Fix the bad crypto design. Exercise: How many failures can a designer Renegotiation attack. Diginotar CA comp BEAST CBC attack. Trustwave HTTPS CRIME compression Lucky 13 padding/tim RC4 keystream bias. TLS truncation. gotofail signature-verification Triple Handshake. Heartbleed buffer overread. POODLE padding-o Winshock buffer overflo
SLIDE 68
ry. Bleichenbacher with with Bleichenbacher enSSL. attacks? 2014.08 Meyer–Somorovsky– Weiss–Schwenk–Schinzel–Tews: Successful Bleichenbacher attacks, exploiting analogous timing variations in Java SSE, Cavium NITROX SSL accelerator chip. The whole concept of a “public-key cryptosystem” is a historical accident, dangerously unauthenticated. Do we seriously believe that we’ll make HTTPS secure by fixing the implementations? Fix the bad crypto design. Exercise: How many of these failures can a designer address? Renegotiation attack. Diginotar CA compromise. BEAST CBC attack. Trustwave HTTPS interception. CRIME compression attack. Lucky 13 padding/timing attack. RC4 keystream bias. TLS truncation. gotofail signature-verification Triple Handshake. Heartbleed buffer overread. POODLE padding-oracle attack. Winshock buffer overflow.
SLIDE 69
2014.08 Meyer–Somorovsky– Weiss–Schwenk–Schinzel–Tews: Successful Bleichenbacher attacks, exploiting analogous timing variations in Java SSE, Cavium NITROX SSL accelerator chip. The whole concept of a “public-key cryptosystem” is a historical accident, dangerously unauthenticated. Do we seriously believe that we’ll make HTTPS secure by fixing the implementations? Fix the bad crypto design. Exercise: How many of these TLS failures can a designer address? Renegotiation attack. Diginotar CA compromise. BEAST CBC attack. Trustwave HTTPS interception. CRIME compression attack. Lucky 13 padding/timing attack. RC4 keystream bias. TLS truncation. gotofail signature-verification bug. Triple Handshake. Heartbleed buffer overread. POODLE padding-oracle attack. Winshock buffer overflow.
