Boring crypto Some recent TLS failures Daniel J. Bernstein - - PowerPoint PPT Presentation

boring crypto some recent tls failures daniel j bernstein
SMART_READER_LITE
LIVE PREVIEW

Boring crypto Some recent TLS failures Daniel J. Bernstein - - PowerPoint PPT Presentation

Boring crypto Some recent TLS failures Daniel J. Bernstein Diginotar CA compromise. University of Illinois at Chicago & BEAST CBC attack. Technische Universiteit Eindhoven Trustwave HTTPS interception. CRIME compression attack. Lucky 13


slide-1
SLIDE 1

Boring crypto Daniel J. Bernstein University of Illinois at Chicago & Technische Universiteit Eindhoven Ancient Chinese curse: “May you live in interesting times, so that you have many papers to write.” Related mailing list: boring-crypto+subscribe @googlegroups.com Some recent TLS failures 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. FREAK factorization attack. Logjam discrete-log attack.

slide-2
SLIDE 2

crypto

  • J. Bernstein

University of Illinois at Chicago & echnische Universiteit Eindhoven Ancient Chinese curse: “May you interesting times, so that ve many papers to write.” Related mailing list: boring-crypto+subscribe @googlegroups.com Some recent TLS failures 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. FREAK factorization attack. Logjam discrete-log attack. TLS is not New attacks! Disputes Improved Proposed Even better Emergency Different New proto

slide-3
SLIDE 3

Bernstein Illinois at Chicago & Universiteit Eindhoven curse: “May you interesting times, so that papers to write.” list: boring-crypto+subscribe @googlegroups.com Some recent TLS failures 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. FREAK factorization attack. Logjam discrete-log attack. TLS is not boring New attacks! Disputes about sec Improved attacks! Proposed fixes! Even better attacks! Emergency upgrades! Different attacks! New protocol versions!

slide-4
SLIDE 4

Chicago & Eindhoven “May you that write.” boring-crypto+subscribe Some recent TLS failures 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. FREAK factorization attack. Logjam discrete-log attack. TLS is not boring crypto. New attacks! Disputes about security! Improved attacks! Proposed fixes! Even better attacks! Emergency upgrades! Different attacks! New protocol versions!

slide-5
SLIDE 5

Some recent TLS failures 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. FREAK factorization attack. Logjam discrete-log attack. TLS is not boring crypto. New attacks! Disputes about security! Improved attacks! Proposed fixes! Even better attacks! Emergency upgrades! Different attacks! New protocol versions!

slide-6
SLIDE 6

Some recent TLS failures 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. FREAK factorization attack. Logjam discrete-log attack. TLS is not boring crypto. New attacks! Disputes about security! Improved attacks! Proposed fixes! Even better attacks! Emergency upgrades! Different attacks! New protocol versions! Continual excitement; tons of research papers; more jobs for cryptographers.

slide-7
SLIDE 7

Some recent TLS failures 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. FREAK factorization attack. Logjam discrete-log attack. TLS is not boring crypto. New attacks! Disputes about security! Improved attacks! Proposed fixes! Even better attacks! Emergency upgrades! Different attacks! New protocol versions! Continual excitement; tons of research papers; more jobs for cryptographers. Let’s look at an example.

slide-8
SLIDE 8

recent TLS failures Diginotar CA compromise. BEAST CBC attack. ave HTTPS interception. CRIME compression attack. 13 padding/timing attack. eystream bias. truncation. gotofail signature-verification bug. Handshake. rtbleed buffer overread. POODLE padding-oracle attack. Winshock buffer overflow. FREAK factorization attack. discrete-log attack. TLS is not boring crypto. New attacks! Disputes about security! Improved attacks! Proposed fixes! Even better attacks! Emergency upgrades! Different attacks! New protocol versions! Continual excitement; tons of research papers; more jobs for cryptographers. Let’s look at an example. The RC4 1987: Ron Does not

slide-9
SLIDE 9

TLS failures compromise. attack. HTTPS interception. ression attack. padding/timing attack. bias. signature-verification bug. e. buffer overread. padding-oracle attack.

  • verflow.

rization attack. discrete-log attack. TLS is not boring crypto. New attacks! Disputes about security! Improved attacks! Proposed fixes! Even better attacks! Emergency upgrades! Different attacks! New protocol versions! Continual excitement; tons of research papers; more jobs for cryptographers. Let’s look at an example. The RC4 stream cipher 1987: Ron Rivest Does not publish it.

slide-10
SLIDE 10

ise. interception. attack. attack. signature-verification bug.

  • verread.

attack. attack. attack. TLS is not boring crypto. New attacks! Disputes about security! Improved attacks! Proposed fixes! Even better attacks! Emergency upgrades! Different attacks! New protocol versions! Continual excitement; tons of research papers; more jobs for cryptographers. Let’s look at an example. The RC4 stream cipher 1987: Ron Rivest designs RC4. Does not publish it.

slide-11
SLIDE 11

TLS is not boring crypto. New attacks! Disputes about security! Improved attacks! Proposed fixes! Even better attacks! Emergency upgrades! Different attacks! New protocol versions! Continual excitement; tons of research papers; more jobs for cryptographers. Let’s look at an example. The RC4 stream cipher 1987: Ron Rivest designs RC4. Does not publish it.

slide-12
SLIDE 12

TLS is not boring crypto. New attacks! Disputes about security! Improved attacks! Proposed fixes! Even better attacks! Emergency upgrades! Different attacks! New protocol versions! Continual excitement; tons of research papers; more jobs for cryptographers. Let’s look at an example. The RC4 stream cipher 1987: Ron Rivest designs RC4. Does not publish it. 1992: NSA makes a deal with Software Publishers Association. “NSA allows encryption : : : The U.S. Department of State will grant export permission to any program that uses the RC2 or RC4 data-encryption algorithm with a key size

  • f less than 40 bits.”
slide-13
SLIDE 13

not boring crypto. attacks! Disputes about security! roved attacks!

  • sed fixes!

etter attacks! Emergency upgrades! Different attacks! rotocol versions! Continual excitement;

  • f research papers;

jobs for cryptographers. look at an example. The RC4 stream cipher 1987: Ron Rivest designs RC4. Does not publish it. 1992: NSA makes a deal with Software Publishers Association. “NSA allows encryption : : : The U.S. Department of State will grant export permission to any program that uses the RC2 or RC4 data-encryption algorithm with a key size

  • f less than 40 bits.”

1994: Someone posts RC4 New York dissemination the long-term system : the de facto for many programs Windows,

  • perating
  • Notes. : :

was part be kept confidential,’ president

slide-14
SLIDE 14

ring crypto. security! attacks! cks! pgrades! attacks! versions! excitement; papers; cryptographers. example. The RC4 stream cipher 1987: Ron Rivest designs RC4. Does not publish it. 1992: NSA makes a deal with Software Publishers Association. “NSA allows encryption : : : The U.S. Department of State will grant export permission to any program that uses the RC2 or RC4 data-encryption algorithm with a key size

  • f less than 40 bits.”

1994: Someone anonymously posts RC4 source co New York Times: dissemination could the long-term effec system : : : [RC4] has the de facto coding for many popular soft programs including Windows, Apple’s

  • perating system a
  • Notes. : : : ‘I have

was part of this deal be kept confidential,’ president of RSA,

slide-15
SLIDE 15

cryptographers. The RC4 stream cipher 1987: Ron Rivest designs RC4. Does not publish it. 1992: NSA makes a deal with Software Publishers Association. “NSA allows encryption : : : The U.S. Department of State will grant export permission to any program that uses the RC2 or RC4 data-encryption algorithm with a key size

  • f less than 40 bits.”

1994: Someone anonymously posts RC4 source code. New York Times: “Widespread dissemination could compromise the long-term effectiveness of system : : : [RC4] has become the de facto coding standard for many popular software programs including Microsoft Windows, Apple’s Macintosh

  • perating system and Lotus
  • Notes. : : : ‘I have been told

was part of this deal that RC4 be kept confidential,’ Jim Bidzos, president of RSA, said.”

slide-16
SLIDE 16

The RC4 stream cipher 1987: Ron Rivest designs RC4. Does not publish it. 1992: NSA makes a deal with Software Publishers Association. “NSA allows encryption : : : The U.S. Department of State will grant export permission to any program that uses the RC2 or RC4 data-encryption algorithm with a key size

  • f less than 40 bits.”

1994: Someone anonymously posts RC4 source code. New York Times: “Widespread dissemination could compromise the long-term effectiveness of the system : : : [RC4] has become the de facto coding standard for many popular software programs including Microsoft Windows, Apple’s Macintosh

  • perating system and Lotus
  • Notes. : : : ‘I have been told it

was part of this deal that RC4 be kept confidential,’ Jim Bidzos, president of RSA, said.”

slide-17
SLIDE 17

RC4 stream cipher Ron Rivest designs RC4. not publish it. NSA makes a deal with re Publishers Association. allows encryption : : : U.S. Department of State grant export permission program that uses the r RC4 data-encryption rithm with a key size than 40 bits.” 1994: Someone anonymously posts RC4 source code. New York Times: “Widespread dissemination could compromise the long-term effectiveness of the system : : : [RC4] has become the de facto coding standard for many popular software programs including Microsoft Windows, Apple’s Macintosh

  • perating system and Lotus
  • Notes. : : : ‘I have been told it

was part of this deal that RC4 be kept confidential,’ Jim Bidzos, president of RSA, said.” 1994: Netscap SSL (“Secure web browser RSA Data SSL supp RC4 is fastest

slide-18
SLIDE 18

cipher Rivest designs RC4. it. es a deal with Publishers Association. encryption : : : rtment of State permission that uses the data-encryption key size bits.” 1994: Someone anonymously posts RC4 source code. New York Times: “Widespread dissemination could compromise the long-term effectiveness of the system : : : [RC4] has become the de facto coding standard for many popular software programs including Microsoft Windows, Apple’s Macintosh

  • perating system and Lotus
  • Notes. : : : ‘I have been told it

was part of this deal that RC4 be kept confidential,’ Jim Bidzos, president of RSA, said.” 1994: Netscape intro SSL (“Secure Sock web browser and server RSA Data Security SSL supports many RC4 is fastest cipher

slide-19
SLIDE 19

RC4. with ciation. : State ermission the data-encryption 1994: Someone anonymously posts RC4 source code. New York Times: “Widespread dissemination could compromise the long-term effectiveness of the system : : : [RC4] has become the de facto coding standard for many popular software programs including Microsoft Windows, Apple’s Macintosh

  • perating system and Lotus
  • Notes. : : : ‘I have been told it

was part of this deal that RC4 be kept confidential,’ Jim Bidzos, president of RSA, said.” 1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL.

slide-20
SLIDE 20

1994: Someone anonymously posts RC4 source code. New York Times: “Widespread dissemination could compromise the long-term effectiveness of the system : : : [RC4] has become the de facto coding standard for many popular software programs including Microsoft Windows, Apple’s Macintosh

  • perating system and Lotus
  • Notes. : : : ‘I have been told it

was part of this deal that RC4 be kept confidential,’ Jim Bidzos, president of RSA, said.” 1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based on RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL.

slide-21
SLIDE 21

1994: Someone anonymously posts RC4 source code. New York Times: “Widespread dissemination could compromise the long-term effectiveness of the system : : : [RC4] has become the de facto coding standard for many popular software programs including Microsoft Windows, Apple’s Macintosh

  • perating system and Lotus
  • Notes. : : : ‘I have been told it

was part of this deal that RC4 be kept confidential,’ Jim Bidzos, president of RSA, said.” 1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based on RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL. 1995: Finney posts some examples of SSL ciphertexts. Back–Byers–Young, Doligez, Back–Brooks extract plaintexts.

slide-22
SLIDE 22

1994: Someone anonymously posts RC4 source code. New York Times: “Widespread dissemination could compromise the long-term effectiveness of the system : : : [RC4] has become the de facto coding standard for many popular software programs including Microsoft Windows, Apple’s Macintosh

  • perating system and Lotus
  • Notes. : : : ‘I have been told it

was part of this deal that RC4 be kept confidential,’ Jim Bidzos, president of RSA, said.” 1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based on RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL. 1995: Finney posts some examples of SSL ciphertexts. Back–Byers–Young, Doligez, Back–Brooks extract plaintexts. Fix: RC4-128?

slide-23
SLIDE 23

1994: Someone anonymously posts RC4 source code. New York Times: “Widespread dissemination could compromise the long-term effectiveness of the system : : : [RC4] has become the de facto coding standard for many popular software programs including Microsoft Windows, Apple’s Macintosh

  • perating system and Lotus
  • Notes. : : : ‘I have been told it

was part of this deal that RC4 be kept confidential,’ Jim Bidzos, president of RSA, said.” 1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based on RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL. 1995: Finney posts some examples of SSL ciphertexts. Back–Byers–Young, Doligez, Back–Brooks extract plaintexts. Fix: RC4-128? Unacceptable: 1995 Roos shows that RC4 fails a basic definition of cipher security.

slide-24
SLIDE 24

Someone anonymously RC4 source code.

  • rk Times: “Widespread

dissemination could compromise long-term effectiveness of the : : : [RC4] has become facto coding standard any popular software rograms including Microsoft ws, Apple’s Macintosh erating system and Lotus : : : ‘I have been told it rt of this deal that RC4 ept confidential,’ Jim Bidzos, resident of RSA, said.” 1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based on RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL. 1995: Finney posts some examples of SSL ciphertexts. Back–Byers–Young, Doligez, Back–Brooks extract plaintexts. Fix: RC4-128? Unacceptable: 1995 Roos shows that RC4 fails a basic definition of cipher security. So the crypto throws a And thro

slide-25
SLIDE 25

anonymously e code. : “Widespread could compromise effectiveness of the [RC4] has become ding standard r software ding Microsoft Apple’s Macintosh and Lotus have been told it deal that RC4 confidential,’ Jim Bidzos, RSA, said.” 1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based on RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL. 1995: Finney posts some examples of SSL ciphertexts. Back–Byers–Young, Doligez, Back–Brooks extract plaintexts. Fix: RC4-128? Unacceptable: 1995 Roos shows that RC4 fails a basic definition of cipher security. So the crypto communit throws away 40-bit And throws away RC4?

slide-26
SLIDE 26

anonymously “Widespread romise tiveness of the ecome rd Microsoft Macintosh Lotus told it RC4 Bidzos, 1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based on RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL. 1995: Finney posts some examples of SSL ciphertexts. Back–Byers–Young, Doligez, Back–Brooks extract plaintexts. Fix: RC4-128? Unacceptable: 1995 Roos shows that RC4 fails a basic definition of cipher security. So the crypto community throws away 40-bit keys? And throws away RC4?

slide-27
SLIDE 27

1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based on RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL. 1995: Finney posts some examples of SSL ciphertexts. Back–Byers–Young, Doligez, Back–Brooks extract plaintexts. Fix: RC4-128? Unacceptable: 1995 Roos shows that RC4 fails a basic definition of cipher security. So the crypto community throws away 40-bit keys? And throws away RC4?

slide-28
SLIDE 28

1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based on RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL. 1995: Finney posts some examples of SSL ciphertexts. Back–Byers–Young, Doligez, Back–Brooks extract plaintexts. Fix: RC4-128? Unacceptable: 1995 Roos shows that RC4 fails a basic definition of cipher security. So the crypto community throws away 40-bit keys? And throws away RC4? Here’s what actually happens.

slide-29
SLIDE 29

1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based on RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL. 1995: Finney posts some examples of SSL ciphertexts. Back–Byers–Young, Doligez, Back–Brooks extract plaintexts. Fix: RC4-128? Unacceptable: 1995 Roos shows that RC4 fails a basic definition of cipher security. So the crypto community throws away 40-bit keys? And throws away RC4? Here’s what actually happens. 1997: IEEE standardizes WEP (“Wired Equivalent Privacy”) for 802.11 wireless networks. WEP uses RC4 for encryption.

slide-30
SLIDE 30

1994: Netscape introduces SSL (“Secure Sockets Layer”) web browser and server “based on RSA Data Security technology”. SSL supports many options. RC4 is fastest cipher in SSL. 1995: Finney posts some examples of SSL ciphertexts. Back–Byers–Young, Doligez, Back–Brooks extract plaintexts. Fix: RC4-128? Unacceptable: 1995 Roos shows that RC4 fails a basic definition of cipher security. So the crypto community throws away 40-bit keys? And throws away RC4? Here’s what actually happens. 1997: IEEE standardizes WEP (“Wired Equivalent Privacy”) for 802.11 wireless networks. WEP uses RC4 for encryption. 1999: TLS (“Transport Layer Security”), new version of SSL. RC4 is fastest cipher in TLS. TLS still supports “export keys”.

slide-31
SLIDE 31

Netscape introduces Secure Sockets Layer”) rowser and server “based on Data Security technology”. supports many options. fastest cipher in SSL. Finney posts some examples of SSL ciphertexts. Back–Byers–Young, Doligez, Back–Brooks extract plaintexts. RC4-128? Unacceptable: Roos shows that RC4 fails a definition of cipher security. So the crypto community throws away 40-bit keys? And throws away RC4? Here’s what actually happens. 1997: IEEE standardizes WEP (“Wired Equivalent Privacy”) for 802.11 wireless networks. WEP uses RC4 for encryption. 1999: TLS (“Transport Layer Security”), new version of SSL. RC4 is fastest cipher in TLS. TLS still supports “export keys”. More RC4 1995 Wagner, 1997 Golic, 1998 Knudsen–Meier–Preneel– Rijmen–V 2000 Golic, 2000 Fluhrer–McGrew, 2001 Mantin–Shamir, 2001 Fluhrer–Mantin–Shamir, 2001 Stubblefield–Ioannidis– Rubin. RC4 key-output ⇒ practical

slide-32
SLIDE 32

introduces ckets Layer”) server “based on Security technology”. any options. cipher in SSL.

  • sts some

ciphertexts.

  • ung, Doligez,

extract plaintexts. Unacceptable: ws that RC4 fails a

  • f cipher security.

So the crypto community throws away 40-bit keys? And throws away RC4? Here’s what actually happens. 1997: IEEE standardizes WEP (“Wired Equivalent Privacy”) for 802.11 wireless networks. WEP uses RC4 for encryption. 1999: TLS (“Transport Layer Security”), new version of SSL. RC4 is fastest cipher in TLS. TLS still supports “export keys”. More RC4 cryptanalysis: 1995 Wagner, 1997 Golic, 1998 Knudsen–Meier–Preneel– Rijmen–Verdo 2000 Golic, 2000 Fluhrer–McGrew, 2001 Mantin–Shamir, 2001 Fluhrer–Mantin–Shamir, 2001 Stubblefield–Ioannidis– Rubin. RC4 key-output co ⇒ practical attacks

slide-33
SLIDE 33

duces er”) “based on technology”.

  • ptions.

SSL. ciphertexts. Doligez, plaintexts. Unacceptable: RC4 fails a security. So the crypto community throws away 40-bit keys? And throws away RC4? Here’s what actually happens. 1997: IEEE standardizes WEP (“Wired Equivalent Privacy”) for 802.11 wireless networks. WEP uses RC4 for encryption. 1999: TLS (“Transport Layer Security”), new version of SSL. RC4 is fastest cipher in TLS. TLS still supports “export keys”. More RC4 cryptanalysis: 1995 Wagner, 1997 Golic, 1998 Knudsen–Meier–Preneel– Rijmen–Verdoolaege, 2000 Golic, 2000 Fluhrer–McGrew, 2001 Mantin–Shamir, 2001 Fluhrer–Mantin–Shamir, 2001 Stubblefield–Ioannidis– Rubin. RC4 key-output correlations ⇒ practical attacks on WEP

slide-34
SLIDE 34

So the crypto community throws away 40-bit keys? And throws away RC4? Here’s what actually happens. 1997: IEEE standardizes WEP (“Wired Equivalent Privacy”) for 802.11 wireless networks. WEP uses RC4 for encryption. 1999: TLS (“Transport Layer Security”), new version of SSL. RC4 is fastest cipher in TLS. TLS still supports “export keys”. More RC4 cryptanalysis: 1995 Wagner, 1997 Golic, 1998 Knudsen–Meier–Preneel– Rijmen–Verdoolaege, 2000 Golic, 2000 Fluhrer–McGrew, 2001 Mantin–Shamir, 2001 Fluhrer–Mantin–Shamir, 2001 Stubblefield–Ioannidis– Rubin. RC4 key-output correlations ⇒ practical attacks on WEP.

slide-35
SLIDE 35

crypto community away 40-bit keys? throws away RC4? what actually happens. IEEE standardizes WEP Wired Equivalent Privacy”) 2.11 wireless networks. uses RC4 for encryption. TLS (“Transport Layer Security”), new version of SSL. fastest cipher in TLS. still supports “export keys”. More RC4 cryptanalysis: 1995 Wagner, 1997 Golic, 1998 Knudsen–Meier–Preneel– Rijmen–Verdoolaege, 2000 Golic, 2000 Fluhrer–McGrew, 2001 Mantin–Shamir, 2001 Fluhrer–Mantin–Shamir, 2001 Stubblefield–Ioannidis– Rubin. RC4 key-output correlations ⇒ practical attacks on WEP. 2001 Rivest “Applications the encryption using hashing discard th pseudo-random be considered proposed

  • f RC4 is

and extremely random generato likely to choice fo embedded

slide-36
SLIDE 36

community 40-bit keys? y RC4? actually happens. standardizes WEP Equivalent Privacy”) wireless networks. for encryption. ransport Layer version of SSL. cipher in TLS. rts “export keys”. More RC4 cryptanalysis: 1995 Wagner, 1997 Golic, 1998 Knudsen–Meier–Preneel– Rijmen–Verdoolaege, 2000 Golic, 2000 Fluhrer–McGrew, 2001 Mantin–Shamir, 2001 Fluhrer–Mantin–Shamir, 2001 Stubblefield–Ioannidis– Rubin. RC4 key-output correlations ⇒ practical attacks on WEP. 2001 Rivest response “Applications which the encryption key using hashing and/o discard the first 256 pseudo-random output be considered secure proposed attacks. :

  • f RC4 is its exceptionally

and extremely efficient random generator. likely to remain the choice for many applications embedded systems.”

slide-37
SLIDE 37

ens. WEP Privacy”) rks. tion. yer SSL. TLS. keys”. More RC4 cryptanalysis: 1995 Wagner, 1997 Golic, 1998 Knudsen–Meier–Preneel– Rijmen–Verdoolaege, 2000 Golic, 2000 Fluhrer–McGrew, 2001 Mantin–Shamir, 2001 Fluhrer–Mantin–Shamir, 2001 Stubblefield–Ioannidis– Rubin. RC4 key-output correlations ⇒ practical attacks on WEP. 2001 Rivest response: TLS is “Applications which pre-process the encryption key and IV by using hashing and/or which discard the first 256 bytes of pseudo-random output should be considered secure from the proposed attacks. : : : The ‘hea

  • f RC4 is its exceptionally simple

and extremely efficient pseudo- random generator. : : : RC4 is likely to remain the algorithm choice for many applications embedded systems.”

slide-38
SLIDE 38

More RC4 cryptanalysis: 1995 Wagner, 1997 Golic, 1998 Knudsen–Meier–Preneel– Rijmen–Verdoolaege, 2000 Golic, 2000 Fluhrer–McGrew, 2001 Mantin–Shamir, 2001 Fluhrer–Mantin–Shamir, 2001 Stubblefield–Ioannidis– Rubin. RC4 key-output correlations ⇒ practical attacks on WEP. 2001 Rivest response: TLS is ok. “Applications which pre-process the encryption key and IV by using hashing and/or which discard the first 256 bytes of pseudo-random output should be considered secure from the proposed attacks. : : : The ‘heart’

  • f RC4 is its exceptionally simple

and extremely efficient pseudo- random generator. : : : RC4 is likely to remain the algorithm of choice for many applications and embedded systems.”

slide-39
SLIDE 39

RC4 cryptanalysis: agner, Golic, Knudsen–Meier–Preneel– Rijmen–Verdoolaege, Golic, Fluhrer–McGrew, Mantin–Shamir, Fluhrer–Mantin–Shamir, Stubblefield–Ioannidis– Rubin. ey-output correlations ractical attacks on WEP. 2001 Rivest response: TLS is ok. “Applications which pre-process the encryption key and IV by using hashing and/or which discard the first 256 bytes of pseudo-random output should be considered secure from the proposed attacks. : : : The ‘heart’

  • f RC4 is its exceptionally simple

and extremely efficient pseudo- random generator. : : : RC4 is likely to remain the algorithm of choice for many applications and embedded systems.” Even mo 2002 Hulton, 2002 Mironov, 2002 Pudovkina, 2003 Bittau, 2003 Pudovkina, 2004 Paul–Preneel, 2004 Ko 2004 Devine, 2005 Maximov, 2005 Mantin, 2005 d’Otrepp 2006 Klein, 2006 Do 2006 Chaab

slide-40
SLIDE 40

cryptanalysis: Knudsen–Meier–Preneel– erdoolaege, Fluhrer–McGrew, Mantin–Shamir, Fluhrer–Mantin–Shamir, Stubblefield–Ioannidis– correlations attacks on WEP. 2001 Rivest response: TLS is ok. “Applications which pre-process the encryption key and IV by using hashing and/or which discard the first 256 bytes of pseudo-random output should be considered secure from the proposed attacks. : : : The ‘heart’

  • f RC4 is its exceptionally simple

and extremely efficient pseudo- random generator. : : : RC4 is likely to remain the algorithm of choice for many applications and embedded systems.” Even more RC4 cryptanalysis: 2002 Hulton, 2002 Mironov, 2002 Pudovkina, 2003 Bittau, 2003 Pudovkina, 2004 Paul–Preneel, 2004 KoreK, 2004 Devine, 2005 Maximov, 2005 Mantin, 2005 d’Otreppe, 2006 Klein, 2006 Doroshenko–R 2006 Chaabouni.

slide-41
SLIDE 41

Knudsen–Meier–Preneel–

  • laege,

Fluhrer–Mantin–Shamir, Stubblefield–Ioannidis– rrelations WEP. 2001 Rivest response: TLS is ok. “Applications which pre-process the encryption key and IV by using hashing and/or which discard the first 256 bytes of pseudo-random output should be considered secure from the proposed attacks. : : : The ‘heart’

  • f RC4 is its exceptionally simple

and extremely efficient pseudo- random generator. : : : RC4 is likely to remain the algorithm of choice for many applications and embedded systems.” Even more RC4 cryptanalysis: 2002 Hulton, 2002 Mironov, 2002 Pudovkina, 2003 Bittau, 2003 Pudovkina, 2004 Paul–Preneel, 2004 KoreK, 2004 Devine, 2005 Maximov, 2005 Mantin, 2005 d’Otreppe, 2006 Klein, 2006 Doroshenko–Ryabko, 2006 Chaabouni.

slide-42
SLIDE 42

2001 Rivest response: TLS is ok. “Applications which pre-process the encryption key and IV by using hashing and/or which discard the first 256 bytes of pseudo-random output should be considered secure from the proposed attacks. : : : The ‘heart’

  • f RC4 is its exceptionally simple

and extremely efficient pseudo- random generator. : : : RC4 is likely to remain the algorithm of choice for many applications and embedded systems.” Even more RC4 cryptanalysis: 2002 Hulton, 2002 Mironov, 2002 Pudovkina, 2003 Bittau, 2003 Pudovkina, 2004 Paul–Preneel, 2004 KoreK, 2004 Devine, 2005 Maximov, 2005 Mantin, 2005 d’Otreppe, 2006 Klein, 2006 Doroshenko–Ryabko, 2006 Chaabouni.

slide-43
SLIDE 43

Rivest response: TLS is ok. “Applications which pre-process encryption key and IV by hashing and/or which the first 256 bytes of pseudo-random output should considered secure from the

  • sed attacks. : : : The ‘heart’

is its exceptionally simple extremely efficient pseudo-

  • generator. : : : RC4 is

to remain the algorithm of for many applications and edded systems.” Even more RC4 cryptanalysis: 2002 Hulton, 2002 Mironov, 2002 Pudovkina, 2003 Bittau, 2003 Pudovkina, 2004 Paul–Preneel, 2004 KoreK, 2004 Devine, 2005 Maximov, 2005 Mantin, 2005 d’Otreppe, 2006 Klein, 2006 Doroshenko–Ryabko, 2006 Chaabouni. WEP blamed million credit-ca

  • T. J. Maxx.

settled fo

slide-44
SLIDE 44
  • nse: TLS is ok.

which pre-process ey and IV by and/or which 256 bytes of

  • utput should

ecure from the

  • attacks. : : : The ‘heart’

exceptionally simple efficient pseudo-

  • r. : : : RC4 is

the algorithm of applications and systems.” Even more RC4 cryptanalysis: 2002 Hulton, 2002 Mironov, 2002 Pudovkina, 2003 Bittau, 2003 Pudovkina, 2004 Paul–Preneel, 2004 KoreK, 2004 Devine, 2005 Maximov, 2005 Mantin, 2005 d’Otreppe, 2006 Klein, 2006 Doroshenko–Ryabko, 2006 Chaabouni. WEP blamed for 2007 million credit-card

  • T. J. Maxx. Subse

settled for $40900000

slide-45
SLIDE 45

TLS is ok. rocess by which

  • f

should the ‘heart’ simple pseudo- RC4 is rithm of applications and Even more RC4 cryptanalysis: 2002 Hulton, 2002 Mironov, 2002 Pudovkina, 2003 Bittau, 2003 Pudovkina, 2004 Paul–Preneel, 2004 KoreK, 2004 Devine, 2005 Maximov, 2005 Mantin, 2005 d’Otreppe, 2006 Klein, 2006 Doroshenko–Ryabko, 2006 Chaabouni. WEP blamed for 2007 theft million credit-card numbers from

  • T. J. Maxx. Subsequent lawsuit

settled for $40900000.

slide-46
SLIDE 46

Even more RC4 cryptanalysis: 2002 Hulton, 2002 Mironov, 2002 Pudovkina, 2003 Bittau, 2003 Pudovkina, 2004 Paul–Preneel, 2004 KoreK, 2004 Devine, 2005 Maximov, 2005 Mantin, 2005 d’Otreppe, 2006 Klein, 2006 Doroshenko–Ryabko, 2006 Chaabouni. WEP blamed for 2007 theft of 45 million credit-card numbers from

  • T. J. Maxx. Subsequent lawsuit

settled for $40900000.

slide-47
SLIDE 47

Even more RC4 cryptanalysis: 2002 Hulton, 2002 Mironov, 2002 Pudovkina, 2003 Bittau, 2003 Pudovkina, 2004 Paul–Preneel, 2004 KoreK, 2004 Devine, 2005 Maximov, 2005 Mantin, 2005 d’Otreppe, 2006 Klein, 2006 Doroshenko–Ryabko, 2006 Chaabouni. WEP blamed for 2007 theft of 45 million credit-card numbers from

  • T. J. Maxx. Subsequent lawsuit

settled for $40900000. Cryptanalysis continues: 2007 Paul–Maitra–Srivastava, 2007 Paul–Rathi–Maitra, 2007 Paul–Maitra, 2007 Vaudenay–Vuagnoux, 2007 Tews–Weinmann–Pyshkin, 2007 Tomasevic–Bojanic– Nieto-Taladriz, 2007 Maitra–Paul, 2008 Basu–Ganguly–Maitra–Paul.

slide-48
SLIDE 48

more RC4 cryptanalysis: Hulton, Mironov, Pudovkina, Bittau, Pudovkina, aul–Preneel, KoreK, Devine, Maximov, Mantin, d’Otreppe, Klein, Doroshenko–Ryabko, Chaabouni. WEP blamed for 2007 theft of 45 million credit-card numbers from

  • T. J. Maxx. Subsequent lawsuit

settled for $40900000. Cryptanalysis continues: 2007 Paul–Maitra–Srivastava, 2007 Paul–Rathi–Maitra, 2007 Paul–Maitra, 2007 Vaudenay–Vuagnoux, 2007 Tews–Weinmann–Pyshkin, 2007 Tomasevic–Bojanic– Nieto-Taladriz, 2007 Maitra–Paul, 2008 Basu–Ganguly–Maitra–Paul. And mor 2008 Biham–Ca 2008 Golic–Mo 2008 Maximov–Khovratovich, 2008 Akgun–Kavak–Demirci, 2008 Maitra–P 2008 Beck–T 2009 Basu–Maitra–P 2010 Sep Vuagnoux, 2010 Vua 2011 Maitra–P 2011 Sen Sark 2011 Pau

slide-49
SLIDE 49

cryptanalysis: Pudovkina, Pudovkina, aul–Preneel,

  • –Ryabko,
  • uni.

WEP blamed for 2007 theft of 45 million credit-card numbers from

  • T. J. Maxx. Subsequent lawsuit

settled for $40900000. Cryptanalysis continues: 2007 Paul–Maitra–Srivastava, 2007 Paul–Rathi–Maitra, 2007 Paul–Maitra, 2007 Vaudenay–Vuagnoux, 2007 Tews–Weinmann–Pyshkin, 2007 Tomasevic–Bojanic– Nieto-Taladriz, 2007 Maitra–Paul, 2008 Basu–Ganguly–Maitra–Paul. And more: 2008 Biham–Carmeli, 2008 Golic–Morgari, 2008 Maximov–Khovratovich, 2008 Akgun–Kavak–Demirci, 2008 Maitra–Paul. 2008 Beck–Tews, 2009 Basu–Maitra–P 2010 Sepehrdad–V Vuagnoux, 2010 Vuagnoux, 2011 Maitra–Paul–Sen 2011 Sen Gupta–Maitra–P Sarkar, 2011 Paul–Maitra

slide-50
SLIDE 50

cryptanalysis:

  • ,

WEP blamed for 2007 theft of 45 million credit-card numbers from

  • T. J. Maxx. Subsequent lawsuit

settled for $40900000. Cryptanalysis continues: 2007 Paul–Maitra–Srivastava, 2007 Paul–Rathi–Maitra, 2007 Paul–Maitra, 2007 Vaudenay–Vuagnoux, 2007 Tews–Weinmann–Pyshkin, 2007 Tomasevic–Bojanic– Nieto-Taladriz, 2007 Maitra–Paul, 2008 Basu–Ganguly–Maitra–Paul. And more: 2008 Biham–Carmeli, 2008 Golic–Morgari, 2008 Maximov–Khovratovich, 2008 Akgun–Kavak–Demirci, 2008 Maitra–Paul. 2008 Beck–Tews, 2009 Basu–Maitra–Paul–Talukda 2010 Sepehrdad–Vaudenay– Vuagnoux, 2010 Vuagnoux, 2011 Maitra–Paul–Sen Gupta, 2011 Sen Gupta–Maitra–Paul– Sarkar, 2011 Paul–Maitra book.

slide-51
SLIDE 51

WEP blamed for 2007 theft of 45 million credit-card numbers from

  • T. J. Maxx. Subsequent lawsuit

settled for $40900000. Cryptanalysis continues: 2007 Paul–Maitra–Srivastava, 2007 Paul–Rathi–Maitra, 2007 Paul–Maitra, 2007 Vaudenay–Vuagnoux, 2007 Tews–Weinmann–Pyshkin, 2007 Tomasevic–Bojanic– Nieto-Taladriz, 2007 Maitra–Paul, 2008 Basu–Ganguly–Maitra–Paul. And more: 2008 Biham–Carmeli, 2008 Golic–Morgari, 2008 Maximov–Khovratovich, 2008 Akgun–Kavak–Demirci, 2008 Maitra–Paul. 2008 Beck–Tews, 2009 Basu–Maitra–Paul–Talukdar, 2010 Sepehrdad–Vaudenay– Vuagnoux, 2010 Vuagnoux, 2011 Maitra–Paul–Sen Gupta, 2011 Sen Gupta–Maitra–Paul– Sarkar, 2011 Paul–Maitra book.

slide-52
SLIDE 52

blamed for 2007 theft of 45 credit-card numbers from

  • Maxx. Subsequent lawsuit

for $40900000. Cryptanalysis continues: aul–Maitra–Srivastava, aul–Rathi–Maitra, aul–Maitra, audenay–Vuagnoux, ews–Weinmann–Pyshkin,

  • masevic–Bojanic–

Nieto-Taladriz, Maitra–Paul, Basu–Ganguly–Maitra–Paul. And more: 2008 Biham–Carmeli, 2008 Golic–Morgari, 2008 Maximov–Khovratovich, 2008 Akgun–Kavak–Demirci, 2008 Maitra–Paul. 2008 Beck–Tews, 2009 Basu–Maitra–Paul–Talukdar, 2010 Sepehrdad–Vaudenay– Vuagnoux, 2010 Vuagnoux, 2011 Maitra–Paul–Sen Gupta, 2011 Sen Gupta–Maitra–Paul– Sarkar, 2011 Paul–Maitra book. 2012 Aka “Up to 75% web sites BEAST] is the current use and v1.0. : : : prefer th TLS v1.0 128 is faster processor 15% of SSL/T

  • n the Ak

RC4 : : : support the

slide-53
SLIDE 53

r 2007 theft of 45 rd numbers from bsequent lawsuit $40900000. continues: aul–Maitra–Srivastava, thi–Maitra, aul–Maitra, y–Vuagnoux, einmann–Pyshkin,

  • masevic–Bojanic–

aladriz, aul, Basu–Ganguly–Maitra–Paul. And more: 2008 Biham–Carmeli, 2008 Golic–Morgari, 2008 Maximov–Khovratovich, 2008 Akgun–Kavak–Demirci, 2008 Maitra–Paul. 2008 Beck–Tews, 2009 Basu–Maitra–Paul–Talukdar, 2010 Sepehrdad–Vaudenay– Vuagnoux, 2010 Vuagnoux, 2011 Maitra–Paul–Sen Gupta, 2011 Sen Gupta–Maitra–Paul– Sarkar, 2011 Paul–Maitra book. 2012 Akamai blog “Up to 75% of SSL-enabled web sites are vulne BEAST] : : : OpenSSL is the current version use and it only supp v1.0. : : : the interim prefer the RC4-128 TLS v1.0 and SSL 128 is faster and cheap processor time : : : 15% of SSL/TLS negotiations

  • n the Akamai platfo

RC4 : : : most browsers support the RC4 fix

slide-54
SLIDE 54

theft of 45 ers from lawsuit aul–Maitra–Srivastava, agnoux, einmann–Pyshkin, Basu–Ganguly–Maitra–Paul. And more: 2008 Biham–Carmeli, 2008 Golic–Morgari, 2008 Maximov–Khovratovich, 2008 Akgun–Kavak–Demirci, 2008 Maitra–Paul. 2008 Beck–Tews, 2009 Basu–Maitra–Paul–Talukdar, 2010 Sepehrdad–Vaudenay– Vuagnoux, 2010 Vuagnoux, 2011 Maitra–Paul–Sen Gupta, 2011 Sen Gupta–Maitra–Paul– Sarkar, 2011 Paul–Maitra book. 2012 Akamai blog entry: “Up to 75% of SSL-enabled web sites are vulnerable [to BEAST] : : : OpenSSL v0.9.8w is the current version in broad use and it only supports TLS v1.0. : : : the interim fix is to prefer the RC4-128 cipher fo TLS v1.0 and SSL v3. : : : RC4- 128 is faster and cheaper in processor time : : : approximately 15% of SSL/TLS negotiations

  • n the Akamai platform use

RC4 : : : most browsers can support the RC4 fix for BEAST.”

slide-55
SLIDE 55

And more: 2008 Biham–Carmeli, 2008 Golic–Morgari, 2008 Maximov–Khovratovich, 2008 Akgun–Kavak–Demirci, 2008 Maitra–Paul. 2008 Beck–Tews, 2009 Basu–Maitra–Paul–Talukdar, 2010 Sepehrdad–Vaudenay– Vuagnoux, 2010 Vuagnoux, 2011 Maitra–Paul–Sen Gupta, 2011 Sen Gupta–Maitra–Paul– Sarkar, 2011 Paul–Maitra book. 2012 Akamai blog entry: “Up to 75% of SSL-enabled web sites are vulnerable [to BEAST] : : : OpenSSL v0.9.8w is the current version in broad use and it only supports TLS v1.0. : : : the interim fix is to prefer the RC4-128 cipher for TLS v1.0 and SSL v3. : : : RC4- 128 is faster and cheaper in processor time : : : approximately 15% of SSL/TLS negotiations

  • n the Akamai platform use

RC4 : : : most browsers can support the RC4 fix for BEAST.”

slide-56
SLIDE 56

more: Biham–Carmeli, Golic–Morgari, Maximov–Khovratovich, Akgun–Kavak–Demirci, Maitra–Paul. Beck–Tews, Basu–Maitra–Paul–Talukdar, Sepehrdad–Vaudenay– uagnoux, uagnoux, Maitra–Paul–Sen Gupta, Sen Gupta–Maitra–Paul– Sarkar, aul–Maitra book. 2012 Akamai blog entry: “Up to 75% of SSL-enabled web sites are vulnerable [to BEAST] : : : OpenSSL v0.9.8w is the current version in broad use and it only supports TLS v1.0. : : : the interim fix is to prefer the RC4-128 cipher for TLS v1.0 and SSL v3. : : : RC4- 128 is faster and cheaper in processor time : : : approximately 15% of SSL/TLS negotiations

  • n the Akamai platform use

RC4 : : : most browsers can support the RC4 fix for BEAST.” RC4 cryptanalysis 2013 Lv–Zhang–Lin, 2013 Lv–Lin, 2013 Sen Paul–Sa 2013 Sark Maitra, 2013 Isob Mo 2013 AlF Paterson–P Schuldt, 2014 Paterson–Strefler, 2015 Sep Vuagnoux.

slide-57
SLIDE 57

rmeli, rgari, Maximov–Khovratovich, Akgun–Kavak–Demirci, aul. ews, Basu–Maitra–Paul–Talukdar, ehrdad–Vaudenay– aul–Sen Gupta, Gupta–Maitra–Paul– l–Maitra book. 2012 Akamai blog entry: “Up to 75% of SSL-enabled web sites are vulnerable [to BEAST] : : : OpenSSL v0.9.8w is the current version in broad use and it only supports TLS v1.0. : : : the interim fix is to prefer the RC4-128 cipher for TLS v1.0 and SSL v3. : : : RC4- 128 is faster and cheaper in processor time : : : approximately 15% of SSL/TLS negotiations

  • n the Akamai platform use

RC4 : : : most browsers can support the RC4 fix for BEAST.” RC4 cryptanalysis 2013 Lv–Zhang–Lin, 2013 Lv–Lin, 2013 Sen Gupta–Maitra–Meier– Paul–Sarkar, 2013 Sarkar–Sen Gupta–P Maitra, 2013 Isobe–Ohigashi–W Morii, 2013 AlFardan–Bernstein– Paterson–Poettering– Schuldt, 2014 Paterson–Strefler, 2015 Sepehrdad–Su Vuagnoux.

slide-58
SLIDE 58

Maximov–Khovratovich, Akgun–Kavak–Demirci, alukdar, y– Gupta, aul– 2012 Akamai blog entry: “Up to 75% of SSL-enabled web sites are vulnerable [to BEAST] : : : OpenSSL v0.9.8w is the current version in broad use and it only supports TLS v1.0. : : : the interim fix is to prefer the RC4-128 cipher for TLS v1.0 and SSL v3. : : : RC4- 128 is faster and cheaper in processor time : : : approximately 15% of SSL/TLS negotiations

  • n the Akamai platform use

RC4 : : : most browsers can support the RC4 fix for BEAST.” RC4 cryptanalysis continues: 2013 Lv–Zhang–Lin, 2013 Lv–Lin, 2013 Sen Gupta–Maitra–Meier– Paul–Sarkar, 2013 Sarkar–Sen Gupta–Paul– Maitra, 2013 Isobe–Ohigashi–Watanab Morii, 2013 AlFardan–Bernstein– Paterson–Poettering– Schuldt, 2014 Paterson–Strefler, 2015 Sepehrdad–Suˇ sil–Vaudena Vuagnoux.

slide-59
SLIDE 59

2012 Akamai blog entry: “Up to 75% of SSL-enabled web sites are vulnerable [to BEAST] : : : OpenSSL v0.9.8w is the current version in broad use and it only supports TLS v1.0. : : : the interim fix is to prefer the RC4-128 cipher for TLS v1.0 and SSL v3. : : : RC4- 128 is faster and cheaper in processor time : : : approximately 15% of SSL/TLS negotiations

  • n the Akamai platform use

RC4 : : : most browsers can support the RC4 fix for BEAST.” RC4 cryptanalysis continues: 2013 Lv–Zhang–Lin, 2013 Lv–Lin, 2013 Sen Gupta–Maitra–Meier– Paul–Sarkar, 2013 Sarkar–Sen Gupta–Paul– Maitra, 2013 Isobe–Ohigashi–Watanabe– Morii, 2013 AlFardan–Bernstein– Paterson–Poettering– Schuldt, 2014 Paterson–Strefler, 2015 Sepehrdad–Suˇ sil–Vaudenay– Vuagnoux.

slide-60
SLIDE 60

Akamai blog entry: 75% of SSL-enabled sites are vulnerable [to BEAST] : : : OpenSSL v0.9.8w current version in broad and it only supports TLS : : the interim fix is to the RC4-128 cipher for v1.0 and SSL v3. : : : RC4- faster and cheaper in cessor time : : : approximately

  • f SSL/TLS negotiations

Akamai platform use : : most browsers can rt the RC4 fix for BEAST.” RC4 cryptanalysis continues: 2013 Lv–Zhang–Lin, 2013 Lv–Lin, 2013 Sen Gupta–Maitra–Meier– Paul–Sarkar, 2013 Sarkar–Sen Gupta–Paul– Maitra, 2013 Isobe–Ohigashi–Watanabe– Morii, 2013 AlFardan–Bernstein– Paterson–Poettering– Schuldt, 2014 Paterson–Strefler, 2015 Sepehrdad–Suˇ sil–Vaudenay– Vuagnoux. Maybe the 2015 Mantin 2015 Garman–P van “RC4 2015 Vanho “RC4

slide-61
SLIDE 61

blog entry: SSL-enabled vulnerable [to enSSL v0.9.8w version in broad supports TLS interim fix is to RC4-128 cipher for SSL v3. : : : RC4- cheaper in : : approximately LS negotiations platform use rowsers can fix for BEAST.” RC4 cryptanalysis continues: 2013 Lv–Zhang–Lin, 2013 Lv–Lin, 2013 Sen Gupta–Maitra–Meier– Paul–Sarkar, 2013 Sarkar–Sen Gupta–Paul– Maitra, 2013 Isobe–Ohigashi–Watanabe– Morii, 2013 AlFardan–Bernstein– Paterson–Poettering– Schuldt, 2014 Paterson–Strefler, 2015 Sepehrdad–Suˇ sil–Vaudenay– Vuagnoux. Maybe the final stra 2015 Mantin “Bar 2015 Garman–Paterson– van der Merw “RC4 must die”, 2015 Vanhoef–Piessens “RC4 no more”.

slide-62
SLIDE 62

SSL-enabled [to v0.9.8w road TLS to for RC4- in ximately negotiations use can BEAST.” RC4 cryptanalysis continues: 2013 Lv–Zhang–Lin, 2013 Lv–Lin, 2013 Sen Gupta–Maitra–Meier– Paul–Sarkar, 2013 Sarkar–Sen Gupta–Paul– Maitra, 2013 Isobe–Ohigashi–Watanabe– Morii, 2013 AlFardan–Bernstein– Paterson–Poettering– Schuldt, 2014 Paterson–Strefler, 2015 Sepehrdad–Suˇ sil–Vaudenay– Vuagnoux. Maybe the final straws: 2015 Mantin “Bar Mitzvah”, 2015 Garman–Paterson– van der Merwe “RC4 must die”, 2015 Vanhoef–Piessens “RC4 no more”.

slide-63
SLIDE 63

RC4 cryptanalysis continues: 2013 Lv–Zhang–Lin, 2013 Lv–Lin, 2013 Sen Gupta–Maitra–Meier– Paul–Sarkar, 2013 Sarkar–Sen Gupta–Paul– Maitra, 2013 Isobe–Ohigashi–Watanabe– Morii, 2013 AlFardan–Bernstein– Paterson–Poettering– Schuldt, 2014 Paterson–Strefler, 2015 Sepehrdad–Suˇ sil–Vaudenay– Vuagnoux. Maybe the final straws: 2015 Mantin “Bar Mitzvah”, 2015 Garman–Paterson– van der Merwe “RC4 must die”, 2015 Vanhoef–Piessens “RC4 no more”.

slide-64
SLIDE 64

RC4 cryptanalysis continues: 2013 Lv–Zhang–Lin, 2013 Lv–Lin, 2013 Sen Gupta–Maitra–Meier– Paul–Sarkar, 2013 Sarkar–Sen Gupta–Paul– Maitra, 2013 Isobe–Ohigashi–Watanabe– Morii, 2013 AlFardan–Bernstein– Paterson–Poettering– Schuldt, 2014 Paterson–Strefler, 2015 Sepehrdad–Suˇ sil–Vaudenay– Vuagnoux. Maybe the final straws: 2015 Mantin “Bar Mitzvah”, 2015 Garman–Paterson– van der Merwe “RC4 must die”, 2015 Vanhoef–Piessens “RC4 no more”. Meanwhile IETF publishes RFC 7465 (“RC4 die die die”), prohibiting RC4 in TLS.

slide-65
SLIDE 65

RC4 cryptanalysis continues: 2013 Lv–Zhang–Lin, 2013 Lv–Lin, 2013 Sen Gupta–Maitra–Meier– Paul–Sarkar, 2013 Sarkar–Sen Gupta–Paul– Maitra, 2013 Isobe–Ohigashi–Watanabe– Morii, 2013 AlFardan–Bernstein– Paterson–Poettering– Schuldt, 2014 Paterson–Strefler, 2015 Sepehrdad–Suˇ sil–Vaudenay– Vuagnoux. Maybe the final straws: 2015 Mantin “Bar Mitzvah”, 2015 Garman–Paterson– van der Merwe “RC4 must die”, 2015 Vanhoef–Piessens “RC4 no more”. Meanwhile IETF publishes RFC 7465 (“RC4 die die die”), prohibiting RC4 in TLS. 2015.09.01: Google, Microsoft, Mozilla say that in 2016 their browsers will no longer allow RC4.

slide-66
SLIDE 66

cryptanalysis continues: Lv–Zhang–Lin, Lv–Lin, Sen Gupta–Maitra–Meier– aul–Sarkar, Sarkar–Sen Gupta–Paul– Maitra, Isobe–Ohigashi–Watanabe– Morii, AlFardan–Bernstein– aterson–Poettering– Schuldt, aterson–Strefler, Sepehrdad–Suˇ sil–Vaudenay– uagnoux. Maybe the final straws: 2015 Mantin “Bar Mitzvah”, 2015 Garman–Paterson– van der Merwe “RC4 must die”, 2015 Vanhoef–Piessens “RC4 no more”. Meanwhile IETF publishes RFC 7465 (“RC4 die die die”), prohibiting RC4 in TLS. 2015.09.01: Google, Microsoft, Mozilla say that in 2016 their browsers will no longer allow RC4. Another 2005 Tromer–Osvik–Shamir: 65ms to used for Attack p but without

slide-67
SLIDE 67

cryptanalysis continues: Lv–Zhang–Lin, Gupta–Maitra–Meier– r, Gupta–Paul– e–Ohigashi–Watanabe– rdan–Bernstein–

  • ettering–

aterson–Strefler, ehrdad–Suˇ sil–Vaudenay– Maybe the final straws: 2015 Mantin “Bar Mitzvah”, 2015 Garman–Paterson– van der Merwe “RC4 must die”, 2015 Vanhoef–Piessens “RC4 no more”. Meanwhile IETF publishes RFC 7465 (“RC4 die die die”), prohibiting RC4 in TLS. 2015.09.01: Google, Microsoft, Mozilla say that in 2016 their browsers will no longer allow RC4. Another example: 2005 Tromer–Osvik–Shamir: 65ms to steal Linux used for hard-disk Attack process on but without privileges.

slide-68
SLIDE 68

continues: Gupta–Maitra–Meier– aul– atanabe– ettering– audenay– Maybe the final straws: 2015 Mantin “Bar Mitzvah”, 2015 Garman–Paterson– van der Merwe “RC4 must die”, 2015 Vanhoef–Piessens “RC4 no more”. Meanwhile IETF publishes RFC 7465 (“RC4 die die die”), prohibiting RC4 in TLS. 2015.09.01: Google, Microsoft, Mozilla say that in 2016 their browsers will no longer allow RC4. Another example: timing attacks 2005 Tromer–Osvik–Shamir: 65ms to steal Linux AES key used for hard-disk encryption. Attack process on same CPU but without privileges.

slide-69
SLIDE 69

Maybe the final straws: 2015 Mantin “Bar Mitzvah”, 2015 Garman–Paterson– van der Merwe “RC4 must die”, 2015 Vanhoef–Piessens “RC4 no more”. Meanwhile IETF publishes RFC 7465 (“RC4 die die die”), prohibiting RC4 in TLS. 2015.09.01: Google, Microsoft, Mozilla say that in 2016 their browsers will no longer allow RC4. Another example: timing attacks 2005 Tromer–Osvik–Shamir: 65ms to steal Linux AES key used for hard-disk encryption. Attack process on same CPU but without privileges.

slide-70
SLIDE 70

Maybe the final straws: 2015 Mantin “Bar Mitzvah”, 2015 Garman–Paterson– van der Merwe “RC4 must die”, 2015 Vanhoef–Piessens “RC4 no more”. Meanwhile IETF publishes RFC 7465 (“RC4 die die die”), prohibiting RC4 in TLS. 2015.09.01: Google, Microsoft, Mozilla say that in 2016 their browsers will no longer allow RC4. Another example: timing attacks 2005 Tromer–Osvik–Shamir: 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

  • f the attack process.

65ms: compute key from timings.

slide-71
SLIDE 71

the final straws: Mantin “Bar Mitzvah”, Garman–Paterson– van der Merwe “RC4 must die”, anhoef–Piessens “RC4 no more”. Meanwhile IETF publishes 7465 (“RC4 die die die”), rohibiting RC4 in TLS. 2015.09.01: Google, Microsoft, Mozilla say that in 2016 their rs will no longer allow RC4. Another example: timing attacks 2005 Tromer–Osvik–Shamir: 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

  • f the attack process.

65ms: compute key from timings. 2011 Brumley–T minutes machine’s Secret branch influence

slide-72
SLIDE 72

straws: “Bar Mitzvah”, aterson– Merwe must die”, ef–Piessens more”. publishes (“RC4 die die die”), in TLS.

  • gle, Microsoft,

in 2016 their longer allow RC4. Another example: timing attacks 2005 Tromer–Osvik–Shamir: 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

  • f the attack process.

65ms: compute key from timings. 2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL Secret branch conditions influence timings.

slide-73
SLIDE 73

Mitzvah”, die”), Microsoft, their allow RC4. Another example: timing attacks 2005 Tromer–Osvik–Shamir: 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

  • f the attack process.

65ms: compute key from timings. 2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL ECDSA Secret branch conditions influence timings.

slide-74
SLIDE 74

Another example: timing attacks 2005 Tromer–Osvik–Shamir: 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

  • f the attack process.

65ms: compute key from timings. 2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL ECDSA key. Secret branch conditions influence timings.

slide-75
SLIDE 75

Another example: timing attacks 2005 Tromer–Osvik–Shamir: 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

  • f the attack process.

65ms: compute key from timings. 2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL ECDSA key. Secret branch conditions influence timings. Most cryptographic software has many more small-scale variations in timing: e.g., memcmp for IPsec MACs.

slide-76
SLIDE 76

Another example: timing attacks 2005 Tromer–Osvik–Shamir: 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

  • f the attack process.

65ms: compute key from timings. 2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL ECDSA key. Secret branch conditions influence timings. Most cryptographic software has many more small-scale variations in timing: e.g., memcmp for IPsec MACs. Many more timing attacks: e.g. 2014 van de Pol–Smart–Yarom extracted Bitcoin secret keys from 25 OpenSSL signatures.

slide-77
SLIDE 77

Another example: timing attacks romer–Osvik–Shamir: 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. compute key from timings. 2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL ECDSA key. Secret branch conditions influence timings. Most cryptographic software has many more small-scale variations in timing: e.g., memcmp for IPsec MACs. Many more timing attacks: e.g. 2014 van de Pol–Smart–Yarom extracted Bitcoin secret keys from 25 OpenSSL signatures. 2008 RF Layer Securit Version 1.2”: small timing performance extent on fragment, be large due to the existing MA

  • f the timing
slide-78
SLIDE 78

example: timing attacks romer–Osvik–Shamir: Linux AES key rd-disk encryption.

  • n same CPU

rivileges. implementations tables. AES key table-load addresses, cache state, measurable timings cess. key from timings. 2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL ECDSA key. Secret branch conditions influence timings. Most cryptographic software has many more small-scale variations in timing: e.g., memcmp for IPsec MACs. Many more timing attacks: e.g. 2014 van de Pol–Smart–Yarom extracted Bitcoin secret keys from 25 OpenSSL signatures. 2008 RFC 5246 “The Layer Security (TLS) Version 1.2”: “This small timing channel, performance depends extent on the size fragment, but it is be large enough to due to the large blo existing MACs and

  • f the timing signal.”
slide-79
SLIDE 79

attacks romer–Osvik–Shamir: ey encryption. CPU implementations addresses, state, timings timings. 2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL ECDSA key. Secret branch conditions influence timings. Most cryptographic software has many more small-scale variations in timing: e.g., memcmp for IPsec MACs. Many more timing attacks: e.g. 2014 van de Pol–Smart–Yarom extracted Bitcoin secret keys from 25 OpenSSL signatures. 2008 RFC 5246 “The Transp Layer Security (TLS) Protocol, Version 1.2”: “This leaves a small timing channel, since MA performance depends to some extent on the size of the data fragment, but it is not believed be large enough to be exploitable due to the large block size of existing MACs and the small

  • f the timing signal.”
slide-80
SLIDE 80

2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL ECDSA key. Secret branch conditions influence timings. Most cryptographic software has many more small-scale variations in timing: e.g., memcmp for IPsec MACs. Many more timing attacks: e.g. 2014 van de Pol–Smart–Yarom extracted Bitcoin secret keys from 25 OpenSSL signatures. 2008 RFC 5246 “The Transport Layer Security (TLS) Protocol, Version 1.2”: “This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size

  • f the timing signal.”
slide-81
SLIDE 81

2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL ECDSA key. Secret branch conditions influence timings. Most cryptographic software has many more small-scale variations in timing: e.g., memcmp for IPsec MACs. Many more timing attacks: e.g. 2014 van de Pol–Smart–Yarom extracted Bitcoin secret keys from 25 OpenSSL signatures. 2008 RFC 5246 “The Transport Layer Security (TLS) Protocol, Version 1.2”: “This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size

  • f the timing signal.”

2013 AlFardan–Paterson “Lucky Thirteen: breaking the TLS and DTLS record protocols”: exploit these timings; steal plaintext.

slide-82
SLIDE 82

Brumley–Tuveri: minutes to steal another machine’s OpenSSL ECDSA key. branch conditions influence timings. cryptographic software many more small-scale riations in timing: memcmp for IPsec MACs. more timing attacks: e.g. van de Pol–Smart–Yarom extracted Bitcoin secret keys 25 OpenSSL signatures. 2008 RFC 5246 “The Transport Layer Security (TLS) Protocol, Version 1.2”: “This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size

  • f the timing signal.”

2013 AlFardan–Paterson “Lucky Thirteen: breaking the TLS and DTLS record protocols”: exploit these timings; steal plaintext. Interesting All of this wonderful

slide-83
SLIDE 83

uveri: another enSSL ECDSA key. conditions timings. cryptographic software small-scale timing: IPsec MACs. timing attacks: e.g.

  • l–Smart–Yarom

Bitcoin secret keys enSSL signatures. 2008 RFC 5246 “The Transport Layer Security (TLS) Protocol, Version 1.2”: “This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size

  • f the timing signal.”

2013 AlFardan–Paterson “Lucky Thirteen: breaking the TLS and DTLS record protocols”: exploit these timings; steal plaintext. Interesting vs. boring All of this excitement wonderful for crypto

slide-84
SLIDE 84

ECDSA key. re Cs. attacks: e.g. arom eys signatures. 2008 RFC 5246 “The Transport Layer Security (TLS) Protocol, Version 1.2”: “This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size

  • f the timing signal.”

2013 AlFardan–Paterson “Lucky Thirteen: breaking the TLS and DTLS record protocols”: exploit these timings; steal plaintext. Interesting vs. boring crypto All of this excitement is wonderful for crypto researchers

slide-85
SLIDE 85

2008 RFC 5246 “The Transport Layer Security (TLS) Protocol, Version 1.2”: “This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size

  • f the timing signal.”

2013 AlFardan–Paterson “Lucky Thirteen: breaking the TLS and DTLS record protocols”: exploit these timings; steal plaintext. Interesting vs. boring crypto All of this excitement is wonderful for crypto researchers.

slide-86
SLIDE 86

2008 RFC 5246 “The Transport Layer Security (TLS) Protocol, Version 1.2”: “This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size

  • f the timing signal.”

2013 AlFardan–Paterson “Lucky Thirteen: breaking the TLS and DTLS record protocols”: exploit these timings; steal plaintext. Interesting vs. boring crypto All of this excitement is wonderful for crypto researchers. The only people suffering are the crypto users: continually forced to panic, vulnerable to attacks, uncertain what to do next.

slide-87
SLIDE 87

2008 RFC 5246 “The Transport Layer Security (TLS) Protocol, Version 1.2”: “This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size

  • f the timing signal.”

2013 AlFardan–Paterson “Lucky Thirteen: breaking the TLS and DTLS record protocols”: exploit these timings; steal plaintext. Interesting vs. boring crypto All of this excitement is wonderful for crypto researchers. The only people suffering are the crypto users: continually forced to panic, vulnerable to attacks, uncertain what to do next. The crypto users’ fantasy is boring crypto: crypto that simply works, solidly resists attacks, never needs any upgrades.

slide-88
SLIDE 88

RFC 5246 “The Transport Security (TLS) Protocol, ersion 1.2”: “This leaves a timing channel, since MAC rmance depends to some

  • n the size of the data

fragment, but it is not believed to rge enough to be exploitable, the large block size of existing MACs and the small size timing signal.” AlFardan–Paterson “Lucky Thirteen: breaking the TLS and record protocols”: exploit timings; steal plaintext. Interesting vs. boring crypto All of this excitement is wonderful for crypto researchers. The only people suffering are the crypto users: continually forced to panic, vulnerable to attacks, uncertain what to do next. The crypto users’ fantasy is boring crypto: crypto that simply works, solidly resists attacks, never needs any upgrades. What will the crypto some crypto actually

slide-89
SLIDE 89

“The Transport (TLS) Protocol, his leaves a channel, since MAC ends to some size of the data is not believed to to be exploitable, block size of and the small size signal.” rdan–Paterson “Lucky reaking the TLS and rotocols”: exploit steal plaintext. Interesting vs. boring crypto All of this excitement is wonderful for crypto researchers. The only people suffering are the crypto users: continually forced to panic, vulnerable to attacks, uncertain what to do next. The crypto users’ fantasy is boring crypto: crypto that simply works, solidly resists attacks, never needs any upgrades. What will happen the crypto users convince some crypto researchers actually create boring

slide-90
SLIDE 90

ransport Protocol, a since MAC some data elieved to exploitable,

  • f

all size “Lucky TLS and exploit plaintext. Interesting vs. boring crypto All of this excitement is wonderful for crypto researchers. The only people suffering are the crypto users: continually forced to panic, vulnerable to attacks, uncertain what to do next. The crypto users’ fantasy is boring crypto: crypto that simply works, solidly resists attacks, never needs any upgrades. What will happen if the crypto users convince some crypto researchers to actually create boring crypto?

slide-91
SLIDE 91

Interesting vs. boring crypto All of this excitement is wonderful for crypto researchers. The only people suffering are the crypto users: continually forced to panic, vulnerable to attacks, uncertain what to do next. The crypto users’ fantasy is boring crypto: crypto that simply works, solidly resists attacks, never needs any upgrades. What will happen if the crypto users convince some crypto researchers to actually create boring crypto?

slide-92
SLIDE 92

Interesting vs. boring crypto All of this excitement is wonderful for crypto researchers. The only people suffering are the crypto users: continually forced to panic, vulnerable to attacks, uncertain what to do next. The crypto users’ fantasy is boring crypto: crypto that simply works, solidly resists attacks, never needs any upgrades. What will happen if the crypto users convince some crypto researchers to actually create boring crypto? No more real-world attacks. No more emergency upgrades. Limited audience for any minor attack improvements and for replacement crypto.

slide-93
SLIDE 93

Interesting vs. boring crypto All of this excitement is wonderful for crypto researchers. The only people suffering are the crypto users: continually forced to panic, vulnerable to attacks, uncertain what to do next. The crypto users’ fantasy is boring crypto: crypto that simply works, solidly resists attacks, never needs any upgrades. What will happen if the crypto users convince some crypto researchers to actually create boring crypto? No more real-world attacks. No more emergency upgrades. Limited audience for any minor attack improvements and for replacement crypto. This is an existential threat against future crypto research.

slide-94
SLIDE 94

Interesting vs. boring crypto All of this excitement is wonderful for crypto researchers. The only people suffering are the crypto users: continually forced to panic, vulnerable to attacks, uncertain what to do next. The crypto users’ fantasy is boring crypto: crypto that simply works, solidly resists attacks, never needs any upgrades. What will happen if the crypto users convince some crypto researchers to actually create boring crypto? No more real-world attacks. No more emergency upgrades. Limited audience for any minor attack improvements and for replacement crypto. This is an existential threat against future crypto research. Is this the real life? Is this just fantasy?

slide-95
SLIDE 95

Interesting vs. boring crypto this excitement is

  • nderful for crypto researchers.
  • nly people suffering

the crypto users: continually forced to panic, vulnerable to attacks, uncertain what to do next. crypto users’ fantasy ring crypto: that simply works, resists attacks, needs any upgrades. What will happen if the crypto users convince some crypto researchers to actually create boring crypto? No more real-world attacks. No more emergency upgrades. Limited audience for any minor attack improvements and for replacement crypto. This is an existential threat against future crypto research. Is this the real life? Is this just fantasy? Crypto can Again consider Many interesting How do How can How can to influence affect timings?

slide-96
SLIDE 96
  • ring crypto

excitement is crypto researchers. suffering users: rced to panic, attacks, to do next. users’ fantasy : simply works, attacks, upgrades. What will happen if the crypto users convince some crypto researchers to actually create boring crypto? No more real-world attacks. No more emergency upgrades. Limited audience for any minor attack improvements and for replacement crypto. This is an existential threat against future crypto research. Is this the real life? Is this just fantasy? Crypto can be boring Again consider timing Many interesting questions: How do secrets affect How can attacker How can attacker to influence how secrets affect timings? Et

slide-97
SLIDE 97

crypto rchers. panic, next. What will happen if the crypto users convince some crypto researchers to actually create boring crypto? No more real-world attacks. No more emergency upgrades. Limited audience for any minor attack improvements and for replacement crypto. This is an existential threat against future crypto research. Is this the real life? Is this just fantasy? Crypto can be boring Again consider timing leaks. Many interesting questions: How do secrets affect timings? How can attacker see timings? How can attacker choose inpu to influence how secrets affect timings? Et cetera.

slide-98
SLIDE 98

What will happen if the crypto users convince some crypto researchers to actually create boring crypto? No more real-world attacks. No more emergency upgrades. Limited audience for any minor attack improvements and for replacement crypto. This is an existential threat against future crypto research. Is this the real life? Is this just fantasy? Crypto can be boring Again consider timing leaks. Many interesting questions: How do secrets affect timings? How can attacker see timings? How can attacker choose inputs to influence how secrets affect timings? Et cetera.

slide-99
SLIDE 99

What will happen if the crypto users convince some crypto researchers to actually create boring crypto? No more real-world attacks. No more emergency upgrades. Limited audience for any minor attack improvements and for replacement crypto. This is an existential threat against future crypto research. Is this the real life? Is this just fantasy? Crypto can be boring Again consider timing leaks. Many interesting questions: How do secrets affect timings? How can attacker see timings? How can attacker choose inputs to influence how secrets affect timings? Et cetera. The boring-crypto alternative: crypto software is built from instructions that have no data flow from inputs to timings. Obviously constant time.

slide-100
SLIDE 100

will happen if crypto users convince crypto researchers to actually create boring crypto? re real-world attacks. re emergency upgrades. Limited audience for any attack improvements r replacement crypto. an existential threat against future crypto research. the real life? just fantasy? Crypto can be boring Again consider timing leaks. Many interesting questions: How do secrets affect timings? How can attacker see timings? How can attacker choose inputs to influence how secrets affect timings? Et cetera. The boring-crypto alternative: crypto software is built from instructions that have no data flow from inputs to timings. Obviously constant time. Another “280 securit 280 mults about 222 Bluffdale:

slide-101
SLIDE 101

en if convince researchers to

  • ring crypto?

rld attacks. emergency upgrades. audience for any improvements replacement crypto. existential threat rypto research. life? fantasy? Crypto can be boring Again consider timing leaks. Many interesting questions: How do secrets affect timings? How can attacker see timings? How can attacker choose inputs to influence how secrets affect timings? Et cetera. The boring-crypto alternative: crypto software is built from instructions that have no data flow from inputs to timings. Obviously constant time. Another example: “280 security” is interesting. 280 mults on mass-ma about 222 watt-yea Bluffdale: 226 watts.

slide-102
SLIDE 102

crypto? attacks. upgrades. rovements crypto. threat rch. Crypto can be boring Again consider timing leaks. Many interesting questions: How do secrets affect timings? How can attacker see timings? How can attacker choose inputs to influence how secrets affect timings? Et cetera. The boring-crypto alternative: crypto software is built from instructions that have no data flow from inputs to timings. Obviously constant time. Another example: “280 security” is interesting. 280 mults on mass-market GPUs: about 222 watt-years. Bluffdale: 226 watts.

slide-103
SLIDE 103

Crypto can be boring Again consider timing leaks. Many interesting questions: How do secrets affect timings? How can attacker see timings? How can attacker choose inputs to influence how secrets affect timings? Et cetera. The boring-crypto alternative: crypto software is built from instructions that have no data flow from inputs to timings. Obviously constant time. Another example: “280 security” is interesting. 280 mults on mass-market GPUs: about 222 watt-years. Bluffdale: 226 watts.

slide-104
SLIDE 104

Crypto can be boring Again consider timing leaks. Many interesting questions: How do secrets affect timings? How can attacker see timings? How can attacker choose inputs to influence how secrets affect timings? Et cetera. The boring-crypto alternative: crypto software is built from instructions that have no data flow from inputs to timings. Obviously constant time. Another example: “280 security” is interesting. 280 mults on mass-market GPUs: about 222 watt-years. Bluffdale: 226 watts. Is “280 security” really 285? 275? Are the individual ops harder than single-precision mults? Easier? Can the attack cost be shared across targets, as in Logjam? Every speedup is important.

slide-105
SLIDE 105

Crypto can be boring Again consider timing leaks. Many interesting questions: How do secrets affect timings? How can attacker see timings? How can attacker choose inputs to influence how secrets affect timings? Et cetera. The boring-crypto alternative: crypto software is built from instructions that have no data flow from inputs to timings. Obviously constant time. Another example: “280 security” is interesting. 280 mults on mass-market GPUs: about 222 watt-years. Bluffdale: 226 watts. Is “280 security” really 285? 275? Are the individual ops harder than single-precision mults? Easier? Can the attack cost be shared across targets, as in Logjam? Every speedup is important. “2128 security” is boring.

slide-106
SLIDE 106

can be boring consider timing leaks. interesting questions: do secrets affect timings? can attacker see timings? can attacker choose inputs influence how secrets timings? Et cetera.

  • ring-crypto alternative:

software is built from instructions that have no data from inputs to timings. Obviously constant time. Another example: “280 security” is interesting. 280 mults on mass-market GPUs: about 222 watt-years. Bluffdale: 226 watts. Is “280 security” really 285? 275? Are the individual ops harder than single-precision mults? Easier? Can the attack cost be shared across targets, as in Logjam? Every speedup is important. “2128 security” is boring. NIST ECC see, e.g., in PS3 ECDSA Ed25519

slide-107
SLIDE 107
  • ring

timing leaks. questions: affect timings? er see timings? er choose inputs secrets Et cetera. ring-crypto alternative: is built from have no data to timings. constant time. Another example: “280 security” is interesting. 280 mults on mass-market GPUs: about 222 watt-years. Bluffdale: 226 watts. Is “280 security” really 285? 275? Are the individual ops harder than single-precision mults? Easier? Can the attack cost be shared across targets, as in Logjam? Every speedup is important. “2128 security” is boring. NIST ECC is interesting: see, e.g., how keys in PS3 ECDSA and Ed25519 and X25519:

slide-108
SLIDE 108

leaks. questions: timings? timings? inputs tive: from data timings. Another example: “280 security” is interesting. 280 mults on mass-market GPUs: about 222 watt-years. Bluffdale: 226 watts. Is “280 security” really 285? 275? Are the individual ops harder than single-precision mults? Easier? Can the attack cost be shared across targets, as in Logjam? Every speedup is important. “2128 security” is boring. NIST ECC is interesting: see, e.g., how keys were exposed in PS3 ECDSA and Java ECDH Ed25519 and X25519: boring.

slide-109
SLIDE 109

Another example: “280 security” is interesting. 280 mults on mass-market GPUs: about 222 watt-years. Bluffdale: 226 watts. Is “280 security” really 285? 275? Are the individual ops harder than single-precision mults? Easier? Can the attack cost be shared across targets, as in Logjam? Every speedup is important. “2128 security” is boring. NIST ECC is interesting: see, e.g., how keys were exposed in PS3 ECDSA and Java ECDH. Ed25519 and X25519: boring.

slide-110
SLIDE 110

Another example: “280 security” is interesting. 280 mults on mass-market GPUs: about 222 watt-years. Bluffdale: 226 watts. Is “280 security” really 285? 275? Are the individual ops harder than single-precision mults? Easier? Can the attack cost be shared across targets, as in Logjam? Every speedup is important. “2128 security” is boring. NIST ECC is interesting: see, e.g., how keys were exposed in PS3 ECDSA and Java ECDH. Ed25519 and X25519: boring. Crypto “agility” is interesting: expands the attack surface, complicates implementations, complicates security analysis. One True Cipher Suite: boring.

slide-111
SLIDE 111

Another example: “280 security” is interesting. 280 mults on mass-market GPUs: about 222 watt-years. Bluffdale: 226 watts. Is “280 security” really 285? 275? Are the individual ops harder than single-precision mults? Easier? Can the attack cost be shared across targets, as in Logjam? Every speedup is important. “2128 security” is boring. NIST ECC is interesting: see, e.g., how keys were exposed in PS3 ECDSA and Java ECDH. Ed25519 and X25519: boring. Crypto “agility” is interesting: expands the attack surface, complicates implementations, complicates security analysis. One True Cipher Suite: boring. Incorrect software: interesting. Correct software: boring. Can boring-crypto researchers actually ensure correctness?

slide-112
SLIDE 112

Another example: security” is interesting. mults on mass-market GPUs: 222 watt-years. Bluffdale: 226 watts. security” really 285? 275? the individual ops harder than single-precision mults? Easier? the attack cost be shared targets, as in Logjam? speedup is important. security” is boring. NIST ECC is interesting: see, e.g., how keys were exposed in PS3 ECDSA and Java ECDH. Ed25519 and X25519: boring. Crypto “agility” is interesting: expands the attack surface, complicates implementations, complicates security analysis. One True Cipher Suite: boring. Incorrect software: interesting. Correct software: boring. Can boring-crypto researchers actually ensure correctness? Bugs triggered usually a

slide-113
SLIDE 113

example: interesting. mass-market GPUs: att-years. atts. really 285? 275? individual ops harder than mults? Easier? cost be shared as in Logjam? is important. is boring. NIST ECC is interesting: see, e.g., how keys were exposed in PS3 ECDSA and Java ECDH. Ed25519 and X25519: boring. Crypto “agility” is interesting: expands the attack surface, complicates implementations, complicates security analysis. One True Cipher Suite: boring. Incorrect software: interesting. Correct software: boring. Can boring-crypto researchers actually ensure correctness? Bugs triggered by usually aren’t caught

slide-114
SLIDE 114

interesting. GPUs: ? 275? rder than Easier? shared jam? rtant. NIST ECC is interesting: see, e.g., how keys were exposed in PS3 ECDSA and Java ECDH. Ed25519 and X25519: boring. Crypto “agility” is interesting: expands the attack surface, complicates implementations, complicates security analysis. One True Cipher Suite: boring. Incorrect software: interesting. Correct software: boring. Can boring-crypto researchers actually ensure correctness? Bugs triggered by very rare inputs usually aren’t caught by testing.

slide-115
SLIDE 115

NIST ECC is interesting: see, e.g., how keys were exposed in PS3 ECDSA and Java ECDH. Ed25519 and X25519: boring. Crypto “agility” is interesting: expands the attack surface, complicates implementations, complicates security analysis. One True Cipher Suite: boring. Incorrect software: interesting. Correct software: boring. Can boring-crypto researchers actually ensure correctness? Bugs triggered by very rare inputs usually aren’t caught by testing.

slide-116
SLIDE 116

NIST ECC is interesting: see, e.g., how keys were exposed in PS3 ECDSA and Java ECDH. Ed25519 and X25519: boring. Crypto “agility” is interesting: expands the attack surface, complicates implementations, complicates security analysis. One True Cipher Suite: boring. Incorrect software: interesting. Correct software: boring. Can boring-crypto researchers actually ensure correctness? Bugs triggered by very rare inputs usually aren’t caught by testing. Block-cipher implementations typically have no such bugs.

slide-117
SLIDE 117

NIST ECC is interesting: see, e.g., how keys were exposed in PS3 ECDSA and Java ECDH. Ed25519 and X25519: boring. Crypto “agility” is interesting: expands the attack surface, complicates implementations, complicates security analysis. One True Cipher Suite: boring. Incorrect software: interesting. Correct software: boring. Can boring-crypto researchers actually ensure correctness? Bugs triggered by very rare inputs usually aren’t caught by testing. Block-cipher implementations typically have no such bugs. Much bigger issue for bigint

  • software. Integers are split into

“limbs” stored in CPU words; typical tests fail to find extreme values of limbs, fail to catch slight

  • verflows inside arithmetic.
slide-118
SLIDE 118

NIST ECC is interesting: see, e.g., how keys were exposed in PS3 ECDSA and Java ECDH. Ed25519 and X25519: boring. Crypto “agility” is interesting: expands the attack surface, complicates implementations, complicates security analysis. One True Cipher Suite: boring. Incorrect software: interesting. Correct software: boring. Can boring-crypto researchers actually ensure correctness? Bugs triggered by very rare inputs usually aren’t caught by testing. Block-cipher implementations typically have no such bugs. Much bigger issue for bigint

  • software. Integers are split into

“limbs” stored in CPU words; typical tests fail to find extreme values of limbs, fail to catch slight

  • verflows inside arithmetic.

2011 Brumley–Barbosa–Page– Vercauteren exploited a limb overflow in OpenSSL.

slide-119
SLIDE 119

ECC is interesting: e.g., how keys were exposed ECDSA and Java ECDH. Ed25519 and X25519: boring. “agility” is interesting: expands the attack surface, complicates implementations, complicates security analysis. rue Cipher Suite: boring. rrect software: interesting. rrect software: boring.

  • ring-crypto researchers

actually ensure correctness? Bugs triggered by very rare inputs usually aren’t caught by testing. Block-cipher implementations typically have no such bugs. Much bigger issue for bigint

  • software. Integers are split into

“limbs” stored in CPU words; typical tests fail to find extreme values of limbs, fail to catch slight

  • verflows inside arithmetic.

2011 Brumley–Barbosa–Page– Vercauteren exploited a limb overflow in OpenSSL. Typically are caugh Can this

slide-120
SLIDE 120

interesting: ys were exposed and Java ECDH. X25519: boring. is interesting: attack surface, lementations, ecurity analysis. Cipher Suite: boring. re: interesting. re: boring. ring-crypto researchers correctness? Bugs triggered by very rare inputs usually aren’t caught by testing. Block-cipher implementations typically have no such bugs. Much bigger issue for bigint

  • software. Integers are split into

“limbs” stored in CPU words; typical tests fail to find extreme values of limbs, fail to catch slight

  • verflows inside arithmetic.

2011 Brumley–Barbosa–Page– Vercauteren exploited a limb overflow in OpenSSL. Typically these limb are caught by care Can this be automated?

slide-121
SLIDE 121

xposed ECDH. ring. interesting: surface, mentations, analysis.

  • ring.

interesting. rchers rrectness? Bugs triggered by very rare inputs usually aren’t caught by testing. Block-cipher implementations typically have no such bugs. Much bigger issue for bigint

  • software. Integers are split into

“limbs” stored in CPU words; typical tests fail to find extreme values of limbs, fail to catch slight

  • verflows inside arithmetic.

2011 Brumley–Barbosa–Page– Vercauteren exploited a limb overflow in OpenSSL. Typically these limb overflows are caught by careful audits. Can this be automated?

slide-122
SLIDE 122

Bugs triggered by very rare inputs usually aren’t caught by testing. Block-cipher implementations typically have no such bugs. Much bigger issue for bigint

  • software. Integers are split into

“limbs” stored in CPU words; typical tests fail to find extreme values of limbs, fail to catch slight

  • verflows inside arithmetic.

2011 Brumley–Barbosa–Page– Vercauteren exploited a limb overflow in OpenSSL. Typically these limb overflows are caught by careful audits. Can this be automated?

slide-123
SLIDE 123

Bugs triggered by very rare inputs usually aren’t caught by testing. Block-cipher implementations typically have no such bugs. Much bigger issue for bigint

  • software. Integers are split into

“limbs” stored in CPU words; typical tests fail to find extreme values of limbs, fail to catch slight

  • verflows inside arithmetic.

2011 Brumley–Barbosa–Page– Vercauteren exploited a limb overflow in OpenSSL. Typically these limb overflows are caught by careful audits. Can this be automated? 2014 Chen–Hsu–Lin–Schwabe– Tsai–Wang–Yang–Yang “Verifying Curve25519 software”: proof of correctness of thousands of lines

  • f asm for X25519 main loop.
slide-124
SLIDE 124

Bugs triggered by very rare inputs usually aren’t caught by testing. Block-cipher implementations typically have no such bugs. Much bigger issue for bigint

  • software. Integers are split into

“limbs” stored in CPU words; typical tests fail to find extreme values of limbs, fail to catch slight

  • verflows inside arithmetic.

2011 Brumley–Barbosa–Page– Vercauteren exploited a limb overflow in OpenSSL. Typically these limb overflows are caught by careful audits. Can this be automated? 2014 Chen–Hsu–Lin–Schwabe– Tsai–Wang–Yang–Yang “Verifying Curve25519 software”: proof of correctness of thousands of lines

  • f asm for X25519 main loop.

Still very far from automatic: huge portion of proof was checked by computer but written by hand. Per proof: many hours of CPU time; many hours of human time.

slide-125
SLIDE 125

triggered by very rare inputs aren’t caught by testing. ck-cipher implementations ypically have no such bugs. bigger issue for bigint

  • re. Integers are split into

“limbs” stored in CPU words; ypical tests fail to find extreme

  • f limbs, fail to catch slight

ws inside arithmetic. Brumley–Barbosa–Page– ercauteren exploited a

  • verflow in OpenSSL.

Typically these limb overflows are caught by careful audits. Can this be automated? 2014 Chen–Hsu–Lin–Schwabe– Tsai–Wang–Yang–Yang “Verifying Curve25519 software”: proof of correctness of thousands of lines

  • f asm for X25519 main loop.

Still very far from automatic: huge portion of proof was checked by computer but written by hand. Per proof: many hours of CPU time; many hours of human time. 2015 Bernstein–Schw gfverif far less time Usable pa process fo Latest news: correctness implementation CPU time 141 seconds Human time annotations Working

slide-126
SLIDE 126

y very rare inputs caught by testing. implementations such bugs. issue for bigint Integers are split into in CPU words; to find extreme fail to catch slight arithmetic. Brumley–Barbosa–Page– exploited a OpenSSL. Typically these limb overflows are caught by careful audits. Can this be automated? 2014 Chen–Hsu–Lin–Schwabe– Tsai–Wang–Yang–Yang “Verifying Curve25519 software”: proof of correctness of thousands of lines

  • f asm for X25519 main loop.

Still very far from automatic: huge portion of proof was checked by computer but written by hand. Per proof: many hours of CPU time; many hours of human time. 2015 Bernstein–Schw gfverif, in progress: far less time per pro Usable part of development process for ECC soft Latest news: finished correctness for ref10 implementation of CPU time per proof: 141 seconds on my Human time per p annotations for each Working on automating

slide-127
SLIDE 127

re inputs sting. implementations bugs. bigint split into rds; extreme catch slight rithmetic. age– enSSL. Typically these limb overflows are caught by careful audits. Can this be automated? 2014 Chen–Hsu–Lin–Schwabe– Tsai–Wang–Yang–Yang “Verifying Curve25519 software”: proof of correctness of thousands of lines

  • f asm for X25519 main loop.

Still very far from automatic: huge portion of proof was checked by computer but written by hand. Per proof: many hours of CPU time; many hours of human time. 2015 Bernstein–Schwabe gfverif, in progress: far less time per proof. Usable part of development process for ECC software. Latest news: finished proving correctness for ref10 implementation of X25519. CPU time per proof: 141 seconds on my laptop. Human time per proof: annotations for each field op. Working on automating this.

slide-128
SLIDE 128

Typically these limb overflows are caught by careful audits. Can this be automated? 2014 Chen–Hsu–Lin–Schwabe– Tsai–Wang–Yang–Yang “Verifying Curve25519 software”: proof of correctness of thousands of lines

  • f asm for X25519 main loop.

Still very far from automatic: huge portion of proof was checked by computer but written by hand. Per proof: many hours of CPU time; many hours of human time. 2015 Bernstein–Schwabe gfverif, in progress: far less time per proof. Usable part of development process for ECC software. Latest news: finished proving correctness for ref10 implementation of X25519. CPU time per proof: 141 seconds on my laptop. Human time per proof: annotations for each field op. Working on automating this.