The security impact AES-128, RSA-2048, etc. of a new cryptographic - - PowerPoint PPT Presentation

The security impact

• f a new cryptographic library
• D. J. Bernstein, U. Illinois Chicago

& T. U. Eindhoven Tanja Lange, T. U. Eindhoven Joint work with: Peter Schwabe, R. U. Nijmegen http://xkcd.com/538/ AES-128, RSA-2048, etc. are widely accepted standards. Obviously infeasible to break by best attacks in literature. Implementations are available in public cryptographic libraries such as OpenSSL. Common security practice is to use those implementations.

The security impact

• f a new cryptographic library
• D. J. Bernstein, U. Illinois Chicago

& T. U. Eindhoven Tanja Lange, T. U. Eindhoven Joint work with: Peter Schwabe, R. U. Nijmegen http://xkcd.com/538/ AES-128, RSA-2048, etc. are widely accepted standards. Obviously infeasible to break by best attacks in literature. Implementations are available in public cryptographic libraries such as OpenSSL. Common security practice is to use those implementations. But cryptography is still a disaster! Complete failures

• f confidentiality and integrity.

security impact new cryptographic library Bernstein, U. Illinois Chicago

• U. Eindhoven

Lange, T. U. Eindhoven

• rk with:

Schwabe, R. U. Nijmegen http://xkcd.com/538/ AES-128, RSA-2048, etc. are widely accepted standards. Obviously infeasible to break by best attacks in literature. Implementations are available in public cryptographic libraries such as OpenSSL. Common security practice is to use those implementations. But cryptography is still a disaster! Complete failures

• f confidentiality and integrity.

We have a new cryptographic NaCl (“salt”), the underlying nacl.cr.yp.to and extensive Acknowledgments: code contributions Matthew Media), Emilia K Adam Langley Bo-Yin Y

impact cryptographic library

• U. Illinois Chicago

Eindhoven

• U. Eindhoven
• R. U. Nijmegen

http://xkcd.com/538/ AES-128, RSA-2048, etc. are widely accepted standards. Obviously infeasible to break by best attacks in literature. Implementations are available in public cryptographic libraries such as OpenSSL. Common security practice is to use those implementations. But cryptography is still a disaster! Complete failures

• f confidentiality and integrity.

We have designed+implemented a new cryptographic NaCl (“salt”), to address the underlying problems. nacl.cr.yp.to: source and extensive docum Acknowledgments: code contributions Matthew Dempsky Media), Niels Duif Emilia K¨ asper (Leuven), Adam Langley (Go Bo-Yin Yang (Academia

rary Chicago

• ven

egen AES-128, RSA-2048, etc. are widely accepted standards. Obviously infeasible to break by best attacks in literature. Implementations are available in public cryptographic libraries such as OpenSSL. Common security practice is to use those implementations. But cryptography is still a disaster! Complete failures

• f confidentiality and integrity.

We have designed+implemented a new cryptographic library, NaCl (“salt”), to address the underlying problems. nacl.cr.yp.to: source and extensive documentation Acknowledgments: code contributions from Matthew Dempsky (Mochi Media), Niels Duif (Eindhoven), Emilia K¨ asper (Leuven), Adam Langley (Google), Bo-Yin Yang (Academia Sinica).

AES-128, RSA-2048, etc. are widely accepted standards. Obviously infeasible to break by best attacks in literature. Implementations are available in public cryptographic libraries such as OpenSSL. Common security practice is to use those implementations. But cryptography is still a disaster! Complete failures

• f confidentiality and integrity.

We have designed+implemented a new cryptographic library, NaCl (“salt”), to address the underlying problems. nacl.cr.yp.to: source and extensive documentation. Acknowledgments: code contributions from Matthew Dempsky (Mochi Media), Niels Duif (Eindhoven), Emilia K¨ asper (Leuven), Adam Langley (Google), Bo-Yin Yang (Academia Sinica).

AES-128, RSA-2048, etc. widely accepted standards. Obviously infeasible to break est attacks in literature. Implementations are available public cryptographic libraries as OpenSSL. Common security practice is those implementations. cryptography is still disaster! Complete failures confidentiality and integrity. We have designed+implemented a new cryptographic library, NaCl (“salt”), to address the underlying problems. nacl.cr.yp.to: source and extensive documentation. Acknowledgments: code contributions from Matthew Dempsky (Mochi Media), Niels Duif (Eindhoven), Emilia K¨ asper (Leuven), Adam Langley (Google), Bo-Yin Yang (Academia Sinica). Most of is cryptographically Primary Main task: authenticated Alice has Uses Bob’s Alice’s sec authenticated Sends c Bob uses and Bob’s to verify

RSA-2048, etc. accepted standards. infeasible to break in literature. are available cryptographic libraries enSSL. y practice is implementations. cryptography is still Complete failures and integrity. We have designed+implemented a new cryptographic library, NaCl (“salt”), to address the underlying problems. nacl.cr.yp.to: source and extensive documentation. Acknowledgments: code contributions from Matthew Dempsky (Mochi Media), Niels Duif (Eindhoven), Emilia K¨ asper (Leuven), Adam Langley (Google), Bo-Yin Yang (Academia Sinica). Most of the Internet is cryptographically Primary goal of NaCl: Main task: public-k authenticated encryption Alice has a message Uses Bob’s public Alice’s secret key to authenticated ciphertext Sends c to Bob. Bob uses Alice’s public and Bob’s secret k to verify and recover

standards. reak literature. available raries is implementations. failures integrity. We have designed+implemented a new cryptographic library, NaCl (“salt”), to address the underlying problems. nacl.cr.yp.to: source and extensive documentation. Acknowledgments: code contributions from Matthew Dempsky (Mochi Media), Niels Duif (Eindhoven), Emilia K¨ asper (Leuven), Adam Langley (Google), Bo-Yin Yang (Academia Sinica). Most of the Internet is cryptographically unprotected. Primary goal of NaCl: Fix this. Main task: public-key authenticated encryption. Alice has a message m for Bob. Uses Bob’s public key and Alice’s secret key to compute authenticated ciphertext c. Sends c to Bob. Bob uses Alice’s public key and Bob’s secret key to verify and recover m.

We have designed+implemented a new cryptographic library, NaCl (“salt”), to address the underlying problems. nacl.cr.yp.to: source and extensive documentation. Acknowledgments: code contributions from Matthew Dempsky (Mochi Media), Niels Duif (Eindhoven), Emilia K¨ asper (Leuven), Adam Langley (Google), Bo-Yin Yang (Academia Sinica). Most of the Internet is cryptographically unprotected. Primary goal of NaCl: Fix this. Main task: public-key authenticated encryption. Alice has a message m for Bob. Uses Bob’s public key and Alice’s secret key to compute authenticated ciphertext c. Sends c to Bob. Bob uses Alice’s public key and Bob’s secret key to verify and recover m.

ve designed+implemented cryptographic library, (“salt”), to address underlying problems. nacl.cr.yp.to: source extensive documentation. wledgments: contributions from Matthew Dempsky (Mochi Media), Niels Duif (Eindhoven), K¨ asper (Leuven), Langley (Google), Yang (Academia Sinica). Most of the Internet is cryptographically unprotected. Primary goal of NaCl: Fix this. Main task: public-key authenticated encryption. Alice has a message m for Bob. Uses Bob’s public key and Alice’s secret key to compute authenticated ciphertext c. Sends c to Bob. Bob uses Alice’s public key and Bob’s secret key to verify and recover m. Alice using typical cryptogra Generate Use AES Hash encrypted Read RSA Use key Read Bob’s Use key Convert Plus more allocate handle erro

designed+implemented cryptographic library, to address roblems. : source cumentation. wledgments: contributions from ky (Mochi Duif (Eindhoven), (Leuven), (Google), (Academia Sinica). Most of the Internet is cryptographically unprotected. Primary goal of NaCl: Fix this. Main task: public-key authenticated encryption. Alice has a message m for Bob. Uses Bob’s public key and Alice’s secret key to compute authenticated ciphertext c. Sends c to Bob. Bob uses Alice’s public key and Bob’s secret key to verify and recover m. Alice using a typical cryptographic Generate random AES Use AES key to encrypt Hash encrypted pack Read RSA key from Use key to sign hash. Read Bob’s key from Use key to encrypt Convert to wire format. Plus more code: allocate storage, handle errors, etc.

designed+implemented ry, ion. chi (Eindhoven), Sinica). Most of the Internet is cryptographically unprotected. Primary goal of NaCl: Fix this. Main task: public-key authenticated encryption. Alice has a message m for Bob. Uses Bob’s public key and Alice’s secret key to compute authenticated ciphertext c. Sends c to Bob. Bob uses Alice’s public key and Bob’s secret key to verify and recover m. Alice using a typical cryptographic library: Generate random AES key. Use AES key to encrypt pack Hash encrypted packet. Read RSA key from wire format. Use key to sign hash. Read Bob’s key from wire fo Use key to encrypt signature Convert to wire format. Plus more code: allocate storage, handle errors, etc.

Most of the Internet is cryptographically unprotected. Primary goal of NaCl: Fix this. Main task: public-key authenticated encryption. Alice has a message m for Bob. Uses Bob’s public key and Alice’s secret key to compute authenticated ciphertext c. Sends c to Bob. Bob uses Alice’s public key and Bob’s secret key to verify and recover m. Alice using a typical cryptographic library: Generate random AES key. Use AES key to encrypt packet. Hash encrypted packet. Read RSA key from wire format. Use key to sign hash. Read Bob’s key from wire format. Use key to encrypt signature etc. Convert to wire format. Plus more code: allocate storage, handle errors, etc.

• f the Internet

cryptographically unprotected. ry goal of NaCl: Fix this. task: public-key authenticated encryption. has a message m for Bob. Bob’s public key and secret key to compute authenticated ciphertext c. c to Bob. uses Alice’s public key Bob’s secret key verify and recover m. Alice using a typical cryptographic library: Generate random AES key. Use AES key to encrypt packet. Hash encrypted packet. Read RSA key from wire format. Use key to sign hash. Read Bob’s key from wire format. Use key to encrypt signature etc. Convert to wire format. Plus more code: allocate storage, handle errors, etc. Alice using c = crypto_box(m,n,pk,sk)

Internet cryptographically unprotected. NaCl: Fix this. public-key encryption. message m for Bob. public key and ey to compute ciphertext c. public key ecret key recover m. Alice using a typical cryptographic library: Generate random AES key. Use AES key to encrypt packet. Hash encrypted packet. Read RSA key from wire format. Use key to sign hash. Read Bob’s key from wire format. Use key to encrypt signature etc. Convert to wire format. Plus more code: allocate storage, handle errors, etc. Alice using NaCl: c = crypto_box(m,n,pk,sk)

rotected. this. encryption. Bob. compute . y Alice using a typical cryptographic library: Generate random AES key. Use AES key to encrypt packet. Hash encrypted packet. Read RSA key from wire format. Use key to sign hash. Read Bob’s key from wire format. Use key to encrypt signature etc. Convert to wire format. Plus more code: allocate storage, handle errors, etc. Alice using NaCl: c = crypto_box(m,n,pk,sk)

Alice using a typical cryptographic library: Generate random AES key. Use AES key to encrypt packet. Hash encrypted packet. Read RSA key from wire format. Use key to sign hash. Read Bob’s key from wire format. Use key to encrypt signature etc. Convert to wire format. Plus more code: allocate storage, handle errors, etc. Alice using NaCl: c = crypto_box(m,n,pk,sk)

Alice using a typical cryptographic library: Generate random AES key. Use AES key to encrypt packet. Hash encrypted packet. Read RSA key from wire format. Use key to sign hash. Read Bob’s key from wire format. Use key to encrypt signature etc. Convert to wire format. Plus more code: allocate storage, handle errors, etc. Alice using NaCl: c = crypto_box(m,n,pk,sk) 32-byte secret key sk. 32-byte public key pk. 24-byte nonce n. c is 16 bytes longer than m. All objects are C++ std::string variables represented in wire format, ready for storage/transmission. C NaCl: similar, using pointers; no memory allocation, no failures.

using a ypical cryptographic library: Generate random AES key. AES key to encrypt packet. encrypted packet. RSA key from wire format. ey to sign hash. Bob’s key from wire format. ey to encrypt signature etc. Convert to wire format. more code: cate storage, errors, etc. Alice using NaCl: c = crypto_box(m,n,pk,sk) 32-byte secret key sk. 32-byte public key pk. 24-byte nonce n. c is 16 bytes longer than m. All objects are C++ std::string variables represented in wire format, ready for storage/transmission. C NaCl: similar, using pointers; no memory allocation, no failures. Bob verifying, m=crypto_box_open(c,n,pk,sk) Initial key pk = crypto_box_keypair(&sk)

phic library: AES key. encrypt packet. packet. from wire format. hash. from wire format. encrypt signature etc. format. etc. Alice using NaCl: c = crypto_box(m,n,pk,sk) 32-byte secret key sk. 32-byte public key pk. 24-byte nonce n. c is 16 bytes longer than m. All objects are C++ std::string variables represented in wire format, ready for storage/transmission. C NaCl: similar, using pointers; no memory allocation, no failures. Bob verifying, decryptin m=crypto_box_open(c,n,pk,sk) Initial key generation: pk = crypto_box_keypair(&sk)

ry: . packet. format. format. signature etc. Alice using NaCl: c = crypto_box(m,n,pk,sk) 32-byte secret key sk. 32-byte public key pk. 24-byte nonce n. c is 16 bytes longer than m. All objects are C++ std::string variables represented in wire format, ready for storage/transmission. C NaCl: similar, using pointers; no memory allocation, no failures. Bob verifying, decrypting: m=crypto_box_open(c,n,pk,sk) Initial key generation: pk = crypto_box_keypair(&sk)

Alice using NaCl: c = crypto_box(m,n,pk,sk) 32-byte secret key sk. 32-byte public key pk. 24-byte nonce n. c is 16 bytes longer than m. All objects are C++ std::string variables represented in wire format, ready for storage/transmission. C NaCl: similar, using pointers; no memory allocation, no failures. Bob verifying, decrypting: m=crypto_box_open(c,n,pk,sk) Initial key generation: pk = crypto_box_keypair(&sk)

Alice using NaCl: c = crypto_box(m,n,pk,sk) 32-byte secret key sk. 32-byte public key pk. 24-byte nonce n. c is 16 bytes longer than m. All objects are C++ std::string variables represented in wire format, ready for storage/transmission. C NaCl: similar, using pointers; no memory allocation, no failures. Bob verifying, decrypting: m=crypto_box_open(c,n,pk,sk) Initial key generation: pk = crypto_box_keypair(&sk) Can instead use signatures for public messages: pk = crypto_sign_keypair(&sk) 64-byte secret key, 32-byte public key. sm = crypto_sign(m,sk) 64 bytes overhead. m = crypto_sign_open(sm,pk)

using NaCl: crypto_box(m,n,pk,sk) yte secret key sk. yte public key pk. yte nonce n. bytes longer than m.

• bjects are C++

std::string variables resented in wire format, for storage/transmission. NaCl: similar, using pointers; memory allocation, no failures. Bob verifying, decrypting: m=crypto_box_open(c,n,pk,sk) Initial key generation: pk = crypto_box_keypair(&sk) Can instead use signatures for public messages: pk = crypto_sign_keypair(&sk) 64-byte secret key, 32-byte public key. sm = crypto_sign(m,sk) 64 bytes overhead. m = crypto_sign_open(sm,pk) “This sounds Don’t applications

NaCl: crypto_box(m,n,pk,sk) ey sk. ey pk. . longer than m. C++ riables wire format, rage/transmission. using pointers; cation, no failures. Bob verifying, decrypting: m=crypto_box_open(c,n,pk,sk) Initial key generation: pk = crypto_box_keypair(&sk) Can instead use signatures for public messages: pk = crypto_sign_keypair(&sk) 64-byte secret key, 32-byte public key. sm = crypto_sign(m,sk) 64 bytes overhead. m = crypto_sign_open(sm,pk) “This sounds too simple! Don’t applications

crypto_box(m,n,pk,sk) . rmat, rage/transmission.

• inters;

failures. Bob verifying, decrypting: m=crypto_box_open(c,n,pk,sk) Initial key generation: pk = crypto_box_keypair(&sk) Can instead use signatures for public messages: pk = crypto_sign_keypair(&sk) 64-byte secret key, 32-byte public key. sm = crypto_sign(m,sk) 64 bytes overhead. m = crypto_sign_open(sm,pk) “This sounds too simple! Don’t applications need more?”

Bob verifying, decrypting: m=crypto_box_open(c,n,pk,sk) Initial key generation: pk = crypto_box_keypair(&sk) Can instead use signatures for public messages: pk = crypto_sign_keypair(&sk) 64-byte secret key, 32-byte public key. sm = crypto_sign(m,sk) 64 bytes overhead. m = crypto_sign_open(sm,pk) “This sounds too simple! Don’t applications need more?”

Bob verifying, decrypting: m=crypto_box_open(c,n,pk,sk) Initial key generation: pk = crypto_box_keypair(&sk) Can instead use signatures for public messages: pk = crypto_sign_keypair(&sk) 64-byte secret key, 32-byte public key. sm = crypto_sign(m,sk) 64 bytes overhead. m = crypto_sign_open(sm,pk) “This sounds too simple! Don’t applications need more?” Examples of applications using NaCl’s crypto_box: DNSCurve and DNSCrypt, high-security authenticated encryption for DNS queries; deployed by OpenDNS. QUIC, Google’s TLS replacement. MinimaLT in Ethos OS, faster TLS replacement. Threema, encrypted-chat app.

verifying, decrypting: m=crypto_box_open(c,n,pk,sk) key generation: crypto_box_keypair(&sk) instead use signatures public messages: crypto_sign_keypair(&sk) yte secret key, yte public key. crypto_sign(m,sk) ytes overhead. crypto_sign_open(sm,pk) “This sounds too simple! Don’t applications need more?” Examples of applications using NaCl’s crypto_box: DNSCurve and DNSCrypt, high-security authenticated encryption for DNS queries; deployed by OpenDNS. QUIC, Google’s TLS replacement. MinimaLT in Ethos OS, faster TLS replacement. Threema, encrypted-chat app. No secre 2005 Osvik–Shamir–T 65ms to used for Attack p but without Almost all use fast Kernel’s influences influencing influencing

• f the attack

65ms to

ecrypting: m=crypto_box_open(c,n,pk,sk) generation: crypto_box_keypair(&sk) signatures messages: crypto_sign_keypair(&sk) ey, ey. crypto_sign(m,sk)

• verhead.

crypto_sign_open(sm,pk) “This sounds too simple! Don’t applications need more?” Examples of applications using NaCl’s crypto_box: DNSCurve and DNSCrypt, high-security authenticated encryption for DNS queries; deployed by OpenDNS. QUIC, Google’s TLS replacement. MinimaLT in Ethos OS, faster TLS replacement. Threema, encrypted-chat app. No secret load addresses 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

• f the attack process.

65ms to compute influence

m=crypto_box_open(c,n,pk,sk) crypto_box_keypair(&sk) signatures crypto_sign_keypair(&sk) crypto_sign_open(sm,pk) “This sounds too simple! Don’t applications need more?” Examples of applications using NaCl’s crypto_box: DNSCurve and DNSCrypt, high-security authenticated encryption for DNS queries; deployed by OpenDNS. QUIC, Google’s TLS replacement. MinimaLT in Ethos OS, faster TLS replacement. Threema, encrypted-chat app. No secret load addresses 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

• f the attack process.

65ms to compute influence−

“This sounds too simple! Don’t applications need more?” Examples of applications using NaCl’s crypto_box: DNSCurve and DNSCrypt, high-security authenticated encryption for DNS queries; deployed by OpenDNS. QUIC, Google’s TLS replacement. MinimaLT in Ethos OS, faster TLS replacement. Threema, encrypted-chat app. No secret load addresses 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

• f the attack process.

65ms to compute influence−1.

sounds too simple! applications need more?” Examples of applications NaCl’s crypto_box: DNSCurve and DNSCrypt, high-security authenticated encryption for DNS queries; ed by OpenDNS. Google’s TLS replacement. MinimaLT in Ethos OS, TLS replacement. Threema, encrypted-chat app. No secret load addresses 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

• f the attack process.

65ms to compute influence−1. Most cryptographic still use secret but add intended upon the Not confidence- likely to

• simple!

applications need more?” applications crypto_box: DNSCrypt, authenticated DNS queries; enDNS. TLS replacement. Ethos OS, lacement. encrypted-chat app. No secret load addresses 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

• f the attack process.

65ms to compute influence−1. Most cryptographic still use secret load but add “countermeasures” intended to obscure upon the CPU cache Not confidence-ins likely to be breakable.

more?” : DNSCrypt, authenticated queries; replacement. app. No secret load addresses 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

• f the attack process.

65ms to compute influence−1. Most cryptographic libraries still use secret load addresses but add “countermeasures” intended to obscure influence upon the CPU cache state. Not confidence-inspiring; likely to be breakable.

No secret load addresses 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

• f the attack process.

65ms to compute influence−1. Most cryptographic libraries still use secret load addresses but add “countermeasures” intended to obscure influence upon the CPU cache state. Not confidence-inspiring; likely to be breakable.

No secret load addresses 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

• f the attack process.

65ms to compute influence−1. Most cryptographic libraries still use secret load addresses but add “countermeasures” intended to obscure influence upon the CPU cache state. Not confidence-inspiring; likely to be breakable. NaCl systematically avoids all loads from addresses that depend on secret data. Eliminates this type of disaster. 2010 Langley ctgrind: verify this automatically.

ret load addresses 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. Most cryptographic libraries still use secret load addresses but add “countermeasures” intended to obscure influence upon the CPU cache state. Not confidence-inspiring; likely to be breakable. NaCl systematically avoids all loads from addresses that depend on secret data. Eliminates this type of disaster. 2010 Langley ctgrind: verify this automatically. No secre 2011 Brumley–T minutes machine’s Secret branch influence Most cryptographic has many variations e.g., memcmp

addresses Osvik–Shamir–Tromer: Linux AES key rd-disk encryption.

• n same CPU

rivileges. implementations tables. AES key table-load addresses, cache state, measurable timings cess. compute influence−1. Most cryptographic libraries still use secret load addresses but add “countermeasures” intended to obscure influence upon the CPU cache state. Not confidence-inspiring; likely to be breakable. NaCl systematically avoids all loads from addresses that depend on secret data. Eliminates this type of disaster. 2010 Langley ctgrind: verify this automatically. No secret branch conditions 2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL Secret branch conditions influence timings. Most cryptographic has many more small-scale variations in timing: e.g., memcmp for IPsec

romer: ey encryption. CPU implementations addresses, state, timings influence−1. Most cryptographic libraries still use secret load addresses but add “countermeasures” intended to obscure influence upon the CPU cache state. Not confidence-inspiring; likely to be breakable. NaCl systematically avoids all loads from addresses that depend on secret data. Eliminates this type of disaster. 2010 Langley ctgrind: verify this automatically. No secret branch conditions 2011 Brumley–Tuveri: minutes to steal another machine’s OpenSSL ECDSA Secret branch conditions influence timings. Most cryptographic software has many more small-scale variations in timing: e.g., memcmp for IPsec MACs.

Most cryptographic libraries still use secret load addresses but add “countermeasures” intended to obscure influence upon the CPU cache state. Not confidence-inspiring; likely to be breakable. NaCl systematically avoids all loads from addresses that depend on secret data. Eliminates this type of disaster. 2010 Langley ctgrind: verify this automatically. No secret branch conditions 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.

Most cryptographic libraries still use secret load addresses but add “countermeasures” intended to obscure influence upon the CPU cache state. Not confidence-inspiring; likely to be breakable. NaCl systematically avoids all loads from addresses that depend on secret data. Eliminates this type of disaster. 2010 Langley ctgrind: verify this automatically. No secret branch conditions 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. NaCl systematically avoids all branch conditions that depend on secret data. Eliminates this type of disaster.

cryptographic libraries use secret load addresses add “countermeasures” intended to obscure influence the CPU cache state. confidence-inspiring; to be breakable. systematically avoids loads from addresses depend on secret data. Eliminates this type of disaster. Langley ctgrind: this automatically. No secret branch conditions 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. NaCl systematically avoids all branch conditions that depend on secret data. Eliminates this type of disaster. No padding 1998 Bleichenbacher: Decrypt by observing to ≈106 SSL first then checks (which many Subsequent more serious Server resp pattern of pattern reveals

cryptographic libraries load addresses rmeasures”

• bscure influence

cache state. inspiring; reakable. ally avoids addresses secret data. ype of disaster. ctgrind: automatically. No secret branch conditions 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. NaCl systematically avoids all branch conditions that depend on secret data. Eliminates this type of disaster. No padding oracles 1998 Bleichenbacher: Decrypt SSL RSA by observing server to ≈106 variants of SSL first inverts RSA, then checks for “PK (which many forgeries Subsequent processing more serious integrit Server responses re pattern of PKCS fo pattern reveals plaintext.

ries addresses rmeasures” influence state. data. disaster. No secret branch conditions 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. NaCl systematically avoids all branch conditions that depend on secret data. Eliminates this type of disaster. No padding oracles 1998 Bleichenbacher: Decrypt SSL RSA ciphertext by observing server responses to ≈106 variants of ciphertext. SSL first inverts RSA, then checks for “PKCS padding” (which many forgeries have). Subsequent processing applies more serious integrity checks. Server responses reveal pattern of PKCS forgeries; pattern reveals plaintext.

No secret branch conditions 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. NaCl systematically avoids all branch conditions that depend on secret data. Eliminates this type of disaster. No padding oracles 1998 Bleichenbacher: Decrypt SSL RSA ciphertext by observing server responses to ≈106 variants of ciphertext. SSL first inverts RSA, then checks for “PKCS padding” (which many forgeries have). Subsequent processing applies more serious integrity checks. Server responses reveal pattern of PKCS forgeries; pattern reveals plaintext.

ret branch conditions 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. systematically avoids ranch conditions depend on secret data. Eliminates this type of disaster. No padding oracles 1998 Bleichenbacher: Decrypt SSL RSA ciphertext by observing server responses to ≈106 variants of ciphertext. SSL first inverts RSA, then checks for “PKCS padding” (which many forgeries have). Subsequent processing applies more serious integrity checks. Server responses reveal pattern of PKCS forgeries; pattern reveals plaintext. Typical defense try to hide between subsequent But hard BEAST,

conditions uveri: another enSSL ECDSA key. conditions timings. cryptographic software small-scale timing: IPsec MACs. ally avoids conditions secret data. ype of disaster. No padding oracles 1998 Bleichenbacher: Decrypt SSL RSA ciphertext by observing server responses to ≈106 variants of ciphertext. SSL first inverts RSA, then checks for “PKCS padding” (which many forgeries have). Subsequent processing applies more serious integrity checks. Server responses reveal pattern of PKCS forgeries; pattern reveals plaintext. Typical defense strategy: try to hide differences between padding checks subsequent integrit But hard to get this BEAST, Lucky 13,

conditions ECDSA key. re Cs. data. disaster. No padding oracles 1998 Bleichenbacher: Decrypt SSL RSA ciphertext by observing server responses to ≈106 variants of ciphertext. SSL first inverts RSA, then checks for “PKCS padding” (which many forgeries have). Subsequent processing applies more serious integrity checks. Server responses reveal pattern of PKCS forgeries; pattern reveals plaintext. Typical defense strategy: try to hide differences between padding checks and subsequent integrity checks. But hard to get this right: see BEAST, Lucky 13, POODLE,

No padding oracles 1998 Bleichenbacher: Decrypt SSL RSA ciphertext by observing server responses to ≈106 variants of ciphertext. SSL first inverts RSA, then checks for “PKCS padding” (which many forgeries have). Subsequent processing applies more serious integrity checks. Server responses reveal pattern of PKCS forgeries; pattern reveals plaintext. Typical defense strategy: try to hide differences between padding checks and subsequent integrity checks. But hard to get this right: see BEAST, Lucky 13, POODLE, etc.

No padding oracles 1998 Bleichenbacher: Decrypt SSL RSA ciphertext by observing server responses to ≈106 variants of ciphertext. SSL first inverts RSA, then checks for “PKCS padding” (which many forgeries have). Subsequent processing applies more serious integrity checks. Server responses reveal pattern of PKCS forgeries; pattern reveals plaintext. Typical defense strategy: try to hide differences between padding checks and subsequent integrity checks. But hard to get this right: see BEAST, Lucky 13, POODLE, etc. NaCl does not decrypt unless message is authenticated. Verification procedure rejects all forgeries in constant time. Attacks are further constrained by per-nonce key separation and standard nonce handling.

padding oracles Bleichenbacher: Decrypt SSL RSA ciphertext

• bserving server responses

106 variants of ciphertext. first inverts RSA, checks for “PKCS padding” many forgeries have). Subsequent processing applies serious integrity checks. responses reveal pattern of PKCS forgeries; pattern reveals plaintext. Typical defense strategy: try to hide differences between padding checks and subsequent integrity checks. But hard to get this right: see BEAST, Lucky 13, POODLE, etc. NaCl does not decrypt unless message is authenticated. Verification procedure rejects all forgeries in constant time. Attacks are further constrained by per-nonce key separation and standard nonce handling. Centralizing 2008 Bello: OpenSSL had only Debian develop a subtle randomness-generating

racles Bleichenbacher: RSA ciphertext server responses riants of ciphertext. RSA, “PKCS padding” rgeries have). cessing applies integrity checks. reveal forgeries; plaintext. Typical defense strategy: try to hide differences between padding checks and subsequent integrity checks. But hard to get this right: see BEAST, Lucky 13, POODLE, etc. NaCl does not decrypt unless message is authenticated. Verification procedure rejects all forgeries in constant time. Attacks are further constrained by per-nonce key separation and standard nonce handling. Centralizing randomness 2008 Bello: Debian/Ubuntu OpenSSL keys for had only 15 bits of Debian developer had a subtle line of Op randomness-generating

ciphertext

• nses

ciphertext. padding” have). applies hecks. rgeries; Typical defense strategy: try to hide differences between padding checks and subsequent integrity checks. But hard to get this right: see BEAST, Lucky 13, POODLE, etc. NaCl does not decrypt unless message is authenticated. Verification procedure rejects all forgeries in constant time. Attacks are further constrained by per-nonce key separation and standard nonce handling. Centralizing randomness 2008 Bello: Debian/Ubuntu OpenSSL keys for 1.5 years had only 15 bits of entropy. Debian developer had removed a subtle line of OpenSSL randomness-generating code.

Typical defense strategy: try to hide differences between padding checks and subsequent integrity checks. But hard to get this right: see BEAST, Lucky 13, POODLE, etc. NaCl does not decrypt unless message is authenticated. Verification procedure rejects all forgeries in constant time. Attacks are further constrained by per-nonce key separation and standard nonce handling. Centralizing randomness 2008 Bello: Debian/Ubuntu OpenSSL keys for 1.5 years had only 15 bits of entropy. Debian developer had removed a subtle line of OpenSSL randomness-generating code.

Typical defense strategy: try to hide differences between padding checks and subsequent integrity checks. But hard to get this right: see BEAST, Lucky 13, POODLE, etc. NaCl does not decrypt unless message is authenticated. Verification procedure rejects all forgeries in constant time. Attacks are further constrained by per-nonce key separation and standard nonce handling. Centralizing randomness 2008 Bello: Debian/Ubuntu OpenSSL keys for 1.5 years had only 15 bits of entropy. Debian developer had removed a subtle line of OpenSSL randomness-generating code. NaCl uses /dev/urandom, the OS random-number generator. Reviewing this kernel code is much more tractable than reviewing separate RNG code in every security library.

ypical defense strategy: hide differences een padding checks and subsequent integrity checks. rd to get this right: see BEAST, Lucky 13, POODLE, etc. does not decrypt message is authenticated. erification procedure rejects rgeries in constant time. ttacks are further constrained er-nonce key separation standard nonce handling. Centralizing randomness 2008 Bello: Debian/Ubuntu OpenSSL keys for 1.5 years had only 15 bits of entropy. Debian developer had removed a subtle line of OpenSSL randomness-generating code. NaCl uses /dev/urandom, the OS random-number generator. Reviewing this kernel code is much more tractable than reviewing separate RNG code in every security library. Centralization merge many pool feeding Merging auditable. bad/failing/malicious if there is

strategy: differences checks and integrity checks. this right: see 3, POODLE, etc. decrypt is authenticated. edure rejects constant time. further constrained ey separation nonce handling. Centralizing randomness 2008 Bello: Debian/Ubuntu OpenSSL keys for 1.5 years had only 15 bits of entropy. Debian developer had removed a subtle line of OpenSSL randomness-generating code. NaCl uses /dev/urandom, the OS random-number generator. Reviewing this kernel code is much more tractable than reviewing separate RNG code in every security library. Centralization allows merge many entrop pool feeding many Merging is deterministic

• auditable. Can survive

bad/failing/malicious if there is one good

and checks. see POODLE, etc. authenticated. rejects time. constrained ration handling. Centralizing randomness 2008 Bello: Debian/Ubuntu OpenSSL keys for 1.5 years had only 15 bits of entropy. Debian developer had removed a subtle line of OpenSSL randomness-generating code. NaCl uses /dev/urandom, the OS random-number generator. Reviewing this kernel code is much more tractable than reviewing separate RNG code in every security library. Centralization allows OS to merge many entropy sources pool feeding many applications. Merging is deterministic and

• auditable. Can survive many

bad/failing/malicious sources if there is one good source.

Centralizing randomness 2008 Bello: Debian/Ubuntu OpenSSL keys for 1.5 years had only 15 bits of entropy. Debian developer had removed a subtle line of OpenSSL randomness-generating code. NaCl uses /dev/urandom, the OS random-number generator. Reviewing this kernel code is much more tractable than reviewing separate RNG code in every security library. Centralization allows OS to merge many entropy sources into pool feeding many applications. Merging is deterministic and

• auditable. Can survive many

bad/failing/malicious sources if there is one good source.

Centralizing randomness 2008 Bello: Debian/Ubuntu OpenSSL keys for 1.5 years had only 15 bits of entropy. Debian developer had removed a subtle line of OpenSSL randomness-generating code. NaCl uses /dev/urandom, the OS random-number generator. Reviewing this kernel code is much more tractable than reviewing separate RNG code in every security library. Centralization allows OS to merge many entropy sources into pool feeding many applications. Merging is deterministic and

• auditable. Can survive many

bad/failing/malicious sources if there is one good source. Huge step backwards: Intel’s RDRAND in applications. Single entropy source; no backup; likely to be poorly cloned; backdoorable (CHES 2013); non-auditable. Not used in NaCl.

Centralizing randomness Bello: Debian/Ubuntu enSSL keys for 1.5 years

• nly 15 bits of entropy.

developer had removed subtle line of OpenSSL randomness-generating code. uses /dev/urandom, random-number generator. Reviewing this kernel code much more tractable than reviewing separate RNG code every security library. Centralization allows OS to merge many entropy sources into pool feeding many applications. Merging is deterministic and

• auditable. Can survive many

bad/failing/malicious sources if there is one good source. Huge step backwards: Intel’s RDRAND in applications. Single entropy source; no backup; likely to be poorly cloned; backdoorable (CHES 2013); non-auditable. Not used in NaCl. Avoiding 2010 Bushing–Ma Sven: Sony requirement for each leaked PS3

randomness Debian/Ubuntu for 1.5 years

• f entropy.

er had removed OpenSSL randomness-generating code. /dev/urandom, random-number generator. ernel code tractable than rate RNG code library. Centralization allows OS to merge many entropy sources into pool feeding many applications. Merging is deterministic and

• auditable. Can survive many

bad/failing/malicious sources if there is one good source. Huge step backwards: Intel’s RDRAND in applications. Single entropy source; no backup; likely to be poorly cloned; backdoorable (CHES 2013); non-auditable. Not used in NaCl. Avoiding unnecessa 2010 Bushing–Marcan–Segher– Sven: Sony ignored requirement of new for each signature. leaked PS3 code-signing

Debian/Ubuntu rs y. removed de. , generator. than code Centralization allows OS to merge many entropy sources into pool feeding many applications. Merging is deterministic and

• auditable. Can survive many

bad/failing/malicious sources if there is one good source. Huge step backwards: Intel’s RDRAND in applications. Single entropy source; no backup; likely to be poorly cloned; backdoorable (CHES 2013); non-auditable. Not used in NaCl. Avoiding unnecessary randomness 2010 Bushing–Marcan–Segher– Sven: Sony ignored ECDSA requirement of new randomness for each signature. ⇒ Signatures leaked PS3 code-signing key.

Centralization allows OS to merge many entropy sources into pool feeding many applications. Merging is deterministic and

• auditable. Can survive many

bad/failing/malicious sources if there is one good source. Huge step backwards: Intel’s RDRAND in applications. Single entropy source; no backup; likely to be poorly cloned; backdoorable (CHES 2013); non-auditable. Not used in NaCl. Avoiding unnecessary randomness 2010 Bushing–Marcan–Segher– Sven: Sony ignored ECDSA requirement of new randomness for each signature. ⇒ Signatures leaked PS3 code-signing key.

Centralization allows OS to merge many entropy sources into pool feeding many applications. Merging is deterministic and

• auditable. Can survive many

bad/failing/malicious sources if there is one good source. Huge step backwards: Intel’s RDRAND in applications. Single entropy source; no backup; likely to be poorly cloned; backdoorable (CHES 2013); non-auditable. Not used in NaCl. Avoiding unnecessary randomness 2010 Bushing–Marcan–Segher– Sven: Sony ignored ECDSA requirement of new randomness for each signature. ⇒ Signatures leaked PS3 code-signing key. NaCl has deterministic crypto_box and crypto_sign. Randomness only for keypair. Eliminates this type of disaster. Also simplifies testing. NaCl uses automated test battery from eBACS (ECRYPT Benchmarking

• f Cryptographic Systems).

Centralization allows OS to many entropy sources into feeding many applications. Merging is deterministic and

• auditable. Can survive many

bad/failing/malicious sources there is one good source. step backwards: RDRAND in applications. entropy source; no backup; to be poorly cloned; backdoorable (CHES 2013); non-auditable. Not used in NaCl. Avoiding unnecessary randomness 2010 Bushing–Marcan–Segher– Sven: Sony ignored ECDSA requirement of new randomness for each signature. ⇒ Signatures leaked PS3 code-signing key. NaCl has deterministic crypto_box and crypto_sign. Randomness only for keypair. Eliminates this type of disaster. Also simplifies testing. NaCl uses automated test battery from eBACS (ECRYPT Benchmarking

• f Cryptographic Systems).

Avoiding 2008 Stevens–Sotirov– Appelbaum–Lenstra–Molna Osvik–de MD5 ⇒

allows OS to entropy sources into many applications. deterministic and survive many bad/failing/malicious sources

• d source.

ards: in applications. source; no backup; rly cloned; (CHES 2013); Not used in NaCl. Avoiding unnecessary randomness 2010 Bushing–Marcan–Segher– Sven: Sony ignored ECDSA requirement of new randomness for each signature. ⇒ Signatures leaked PS3 code-signing key. NaCl has deterministic crypto_box and crypto_sign. Randomness only for keypair. Eliminates this type of disaster. Also simplifies testing. NaCl uses automated test battery from eBACS (ECRYPT Benchmarking

• f Cryptographic Systems).

Avoiding pure crypto 2008 Stevens–Sotirov– Appelbaum–Lenstra–Molna Osvik–de Weger exploited MD5 ⇒ rogue CA

to sources into applications. and many sources source. applications. backup; 2013); in NaCl. Avoiding unnecessary randomness 2010 Bushing–Marcan–Segher– Sven: Sony ignored ECDSA requirement of new randomness for each signature. ⇒ Signatures leaked PS3 code-signing key. NaCl has deterministic crypto_box and crypto_sign. Randomness only for keypair. Eliminates this type of disaster. Also simplifies testing. NaCl uses automated test battery from eBACS (ECRYPT Benchmarking

• f Cryptographic Systems).

Avoiding pure crypto failures 2008 Stevens–Sotirov– Appelbaum–Lenstra–Molnar– Osvik–de Weger exploited MD5 ⇒ rogue CA cert.

Avoiding unnecessary randomness 2010 Bushing–Marcan–Segher– Sven: Sony ignored ECDSA requirement of new randomness for each signature. ⇒ Signatures leaked PS3 code-signing key. NaCl has deterministic crypto_box and crypto_sign. Randomness only for keypair. Eliminates this type of disaster. Also simplifies testing. NaCl uses automated test battery from eBACS (ECRYPT Benchmarking

• f Cryptographic Systems).

Avoiding pure crypto failures 2008 Stevens–Sotirov– Appelbaum–Lenstra–Molnar– Osvik–de Weger exploited MD5 ⇒ rogue CA cert.

Avoiding unnecessary randomness 2010 Bushing–Marcan–Segher– Sven: Sony ignored ECDSA requirement of new randomness for each signature. ⇒ Signatures leaked PS3 code-signing key. NaCl has deterministic crypto_box and crypto_sign. Randomness only for keypair. Eliminates this type of disaster. Also simplifies testing. NaCl uses automated test battery from eBACS (ECRYPT Benchmarking

• f Cryptographic Systems).

Avoiding pure crypto failures 2008 Stevens–Sotirov– Appelbaum–Lenstra–Molnar– Osvik–de Weger exploited MD5 ⇒ rogue CA cert. 2012 Flame: new MD5 attack.

Avoiding unnecessary randomness 2010 Bushing–Marcan–Segher– Sven: Sony ignored ECDSA requirement of new randomness for each signature. ⇒ Signatures leaked PS3 code-signing key. NaCl has deterministic crypto_box and crypto_sign. Randomness only for keypair. Eliminates this type of disaster. Also simplifies testing. NaCl uses automated test battery from eBACS (ECRYPT Benchmarking

• f Cryptographic Systems).

Avoiding pure crypto failures 2008 Stevens–Sotirov– Appelbaum–Lenstra–Molnar– Osvik–de Weger exploited MD5 ⇒ rogue CA cert. 2012 Flame: new MD5 attack. Fact: By 1996, a few years after the introduction of MD5, Preneel and Dobbertin were calling for MD5 to be scrapped. NaCl pays attention to cryptanalysis and makes very conservative choices

• f cryptographic primitives.

Avoiding unnecessary randomness Bushing–Marcan–Segher– Sony ignored ECDSA requirement of new randomness h signature. ⇒ Signatures PS3 code-signing key. has deterministic crypto_box and crypto_sign. Randomness only for keypair. Eliminates this type of disaster. simplifies testing. NaCl uses automated test battery from (ECRYPT Benchmarking Cryptographic Systems). Avoiding pure crypto failures 2008 Stevens–Sotirov– Appelbaum–Lenstra–Molnar– Osvik–de Weger exploited MD5 ⇒ rogue CA cert. 2012 Flame: new MD5 attack. Fact: By 1996, a few years after the introduction of MD5, Preneel and Dobbertin were calling for MD5 to be scrapped. NaCl pays attention to cryptanalysis and makes very conservative choices

• f cryptographic primitives.

Speed Crypto p

• ften lead

cryptographic

• r give up

Example used RSA-1024 Security Analyses that RSA-1024 e.g., 2003 estimated RSA Labs Move to

unnecessary randomness Bushing–Marcan–Segher– red ECDSA new randomness

• signature. ⇒ Signatures

de-signing key. deterministic and crypto_sign.

• nly for keypair.

ype of disaster.

• testing. NaCl uses

battery from CRYPT Benchmarking Systems). Avoiding pure crypto failures 2008 Stevens–Sotirov– Appelbaum–Lenstra–Molnar– Osvik–de Weger exploited MD5 ⇒ rogue CA cert. 2012 Flame: new MD5 attack. Fact: By 1996, a few years after the introduction of MD5, Preneel and Dobbertin were calling for MD5 to be scrapped. NaCl pays attention to cryptanalysis and makes very conservative choices

• f cryptographic primitives.

Speed Crypto performance

• ften lead users to

cryptographic securit

• r give up on cryptography

Example 1: Google used RSA-1024 until Security note: Analyses in 2003 concluded that RSA-1024 was e.g., 2003 Shamir–T estimated 1 year, ≈ RSA Labs and NIST Move to RSA-2048

randomness rcan–Segher– ECDSA randomness Signatures ey. crypto_sign. keypair. disaster. NaCl uses from Benchmarking ms). Avoiding pure crypto failures 2008 Stevens–Sotirov– Appelbaum–Lenstra–Molnar– Osvik–de Weger exploited MD5 ⇒ rogue CA cert. 2012 Flame: new MD5 attack. Fact: By 1996, a few years after the introduction of MD5, Preneel and Dobbertin were calling for MD5 to be scrapped. NaCl pays attention to cryptanalysis and makes very conservative choices

• f cryptographic primitives.

Speed Crypto performance problems

• ften lead users to reduce

cryptographic security levels

• r give up on cryptography.

Example 1: Google SSL used RSA-1024 until 2013. Security note: Analyses in 2003 concluded that RSA-1024 was breakable; e.g., 2003 Shamir–Tromer estimated 1 year, ≈107 USD. RSA Labs and NIST response: Move to RSA-2048 by 2010.

Avoiding pure crypto failures 2008 Stevens–Sotirov– Appelbaum–Lenstra–Molnar– Osvik–de Weger exploited MD5 ⇒ rogue CA cert. 2012 Flame: new MD5 attack. Fact: By 1996, a few years after the introduction of MD5, Preneel and Dobbertin were calling for MD5 to be scrapped. NaCl pays attention to cryptanalysis and makes very conservative choices

• f cryptographic primitives.

Speed Crypto performance problems

• ften lead users to reduce

cryptographic security levels

• r give up on cryptography.

Example 1: Google SSL used RSA-1024 until 2013. Security note: Analyses in 2003 concluded that RSA-1024 was breakable; e.g., 2003 Shamir–Tromer estimated 1 year, ≈107 USD. RSA Labs and NIST response: Move to RSA-2048 by 2010.

Avoiding pure crypto failures Stevens–Sotirov– elbaum–Lenstra–Molnar– Osvik–de Weger exploited ⇒ rogue CA cert. Flame: new MD5 attack. By 1996, a few years the introduction of MD5, Preneel and Dobbertin were for MD5 to be scrapped. pays attention to cryptanalysis and makes conservative choices cryptographic primitives. Speed Crypto performance problems

• ften lead users to reduce

cryptographic security levels

• r give up on cryptography.

Example 1: Google SSL used RSA-1024 until 2013. Security note: Analyses in 2003 concluded that RSA-1024 was breakable; e.g., 2003 Shamir–Tromer estimated 1 year, ≈107 USD. RSA Labs and NIST response: Move to RSA-2048 by 2010. Example until 2013 Example 1024: “tradeoff risk of key performance Example to use secret Example

https://sourceforge.net/account

is protected

https://sourceforge.net/develop

turns off

http://sourceforge.net/develop

crypto failures Stevens–Sotirov– elbaum–Lenstra–Molnar– exploited CA cert. new MD5 attack. a few years duction of MD5, Dobbertin were to be scrapped. attention to and makes conservative choices primitives. Speed Crypto performance problems

• ften lead users to reduce

cryptographic security levels

• r give up on cryptography.

Example 1: Google SSL used RSA-1024 until 2013. Security note: Analyses in 2003 concluded that RSA-1024 was breakable; e.g., 2003 Shamir–Tromer estimated 1 year, ≈107 USD. RSA Labs and NIST response: Move to RSA-2048 by 2010. Example 2: Tor use until 2013 switch to Example 3: DNSSEC 1024: “tradeoff bet risk of key compromise performance: : : ” Example 4: OpenSSL to use secret AES Example 5:

https://sourceforge.net/account

is protected by SSL

https://sourceforge.net/develop

turns off crypto: redirects

http://sourceforge.net/develop

failures elbaum–Lenstra–Molnar– attack. rs MD5, ere pped. rimitives. Speed Crypto performance problems

• ften lead users to reduce

cryptographic security levels

• r give up on cryptography.

Example 1: Google SSL used RSA-1024 until 2013. Security note: Analyses in 2003 concluded that RSA-1024 was breakable; e.g., 2003 Shamir–Tromer estimated 1 year, ≈107 USD. RSA Labs and NIST response: Move to RSA-2048 by 2010. Example 2: Tor used RSA-1024 until 2013 switch to Curve25519. Example 3: DNSSEC uses RSA- 1024: “tradeoff between the risk of key compromise and performance: : : ” Example 4: OpenSSL continues to use secret AES load addre Example 5:

https://sourceforge.net/account

is protected by SSL but

https://sourceforge.net/develop

turns off crypto: redirects to

http://sourceforge.net/develop

Speed Crypto performance problems

• ften lead users to reduce

cryptographic security levels

• r give up on cryptography.

Example 1: Google SSL used RSA-1024 until 2013. Security note: Analyses in 2003 concluded that RSA-1024 was breakable; e.g., 2003 Shamir–Tromer estimated 1 year, ≈107 USD. RSA Labs and NIST response: Move to RSA-2048 by 2010. Example 2: Tor used RSA-1024 until 2013 switch to Curve25519. Example 3: DNSSEC uses RSA- 1024: “tradeoff between the risk of key compromise and performance: : : ” Example 4: OpenSSL continues to use secret AES load addresses. Example 5:

https://sourceforge.net/account

is protected by SSL but

https://sourceforge.net/develop

turns off crypto: redirects to

http://sourceforge.net/develop.

performance problems lead users to reduce cryptographic security levels up on cryptography. Example 1: Google SSL RSA-1024 until 2013. Security note: Analyses in 2003 concluded RSA-1024 was breakable; 2003 Shamir–Tromer estimated 1 year, ≈107 USD. Labs and NIST response: to RSA-2048 by 2010. Example 2: Tor used RSA-1024 until 2013 switch to Curve25519. Example 3: DNSSEC uses RSA- 1024: “tradeoff between the risk of key compromise and performance: : : ” Example 4: OpenSSL continues to use secret AES load addresses. Example 5:

https://sourceforge.net/account

is protected by SSL but

https://sourceforge.net/develop

turns off crypto: redirects to

http://sourceforge.net/develop.

NaCl has e.g. crypto_box encrypts e.g. no RSA-1024; not

rmance problems to reduce security levels cryptography.

• gle SSL

until 2013. concluded was breakable; Shamir–Tromer r, ≈107 USD. NIST response: RSA-2048 by 2010. Example 2: Tor used RSA-1024 until 2013 switch to Curve25519. Example 3: DNSSEC uses RSA- 1024: “tradeoff between the risk of key compromise and performance: : : ” Example 4: OpenSSL continues to use secret AES load addresses. Example 5:

https://sourceforge.net/account

is protected by SSL but

https://sourceforge.net/develop

turns off crypto: redirects to

http://sourceforge.net/develop.

NaCl has no low-securit e.g. crypto_box alw encrypts and e.g. no RSA-1024; not even RSA-2048.

roblems levels cryptography. 2013. concluded ble; USD.

• nse:

2010. Example 2: Tor used RSA-1024 until 2013 switch to Curve25519. Example 3: DNSSEC uses RSA- 1024: “tradeoff between the risk of key compromise and performance: : : ” Example 4: OpenSSL continues to use secret AES load addresses. Example 5:

https://sourceforge.net/account

is protected by SSL but

https://sourceforge.net/develop

turns off crypto: redirects to

http://sourceforge.net/develop.

NaCl has no low-security options. e.g. crypto_box always encrypts and authenticates. e.g. no RSA-1024; not even RSA-2048.

Example 2: Tor used RSA-1024 until 2013 switch to Curve25519. Example 3: DNSSEC uses RSA- 1024: “tradeoff between the risk of key compromise and performance: : : ” Example 4: OpenSSL continues to use secret AES load addresses. Example 5:

https://sourceforge.net/account

is protected by SSL but

https://sourceforge.net/develop

turns off crypto: redirects to

http://sourceforge.net/develop.

NaCl has no low-security options. e.g. crypto_box always encrypts and authenticates. e.g. no RSA-1024; not even RSA-2048.

Example 2: Tor used RSA-1024 until 2013 switch to Curve25519. Example 3: DNSSEC uses RSA- 1024: “tradeoff between the risk of key compromise and performance: : : ” Example 4: OpenSSL continues to use secret AES load addresses. Example 5:

https://sourceforge.net/account

is protected by SSL but

https://sourceforge.net/develop

turns off crypto: redirects to

http://sourceforge.net/develop.

NaCl has no low-security options. e.g. crypto_box always encrypts and authenticates. e.g. no RSA-1024; not even RSA-2048. Remaining risk: Users find NaCl too slow ⇒ switch to low-security libraries

• r disable crypto entirely.

Example 2: Tor used RSA-1024 until 2013 switch to Curve25519. Example 3: DNSSEC uses RSA- 1024: “tradeoff between the risk of key compromise and performance: : : ” Example 4: OpenSSL continues to use secret AES load addresses. Example 5:

https://sourceforge.net/account

is protected by SSL but

https://sourceforge.net/develop

turns off crypto: redirects to

http://sourceforge.net/develop.

NaCl has no low-security options. e.g. crypto_box always encrypts and authenticates. e.g. no RSA-1024; not even RSA-2048. Remaining risk: Users find NaCl too slow ⇒ switch to low-security libraries

• r disable crypto entirely.

How NaCl avoids this risk: NaCl is exceptionally fast. Much faster than other libraries. Keeps up with the network.

Example 2: Tor used RSA-1024 2013 switch to Curve25519. Example 3: DNSSEC uses RSA- “tradeoff between the key compromise and rmance: : : ” Example 4: OpenSSL continues secret AES load addresses. Example 5:

https://sourceforge.net/account

rotected by SSL but

https://sourceforge.net/develop

• ff crypto: redirects to

http://sourceforge.net/develop.

NaCl has no low-security options. e.g. crypto_box always encrypts and authenticates. e.g. no RSA-1024; not even RSA-2048. Remaining risk: Users find NaCl too slow ⇒ switch to low-security libraries

• r disable crypto entirely.

How NaCl avoids this risk: NaCl is exceptionally fast. Much faster than other libraries. Keeps up with the network. NaCl operations for any common using AMD CPU ($190 crypto_box crypto_box_open crypto_sign_open crypto_sign

used RSA-1024 switch to Curve25519. DNSSEC uses RSA- between the romise and enSSL continues AES load addresses.

https://sourceforge.net/account

SSL but

https://sourceforge.net/develop

redirects to

http://sourceforge.net/develop.

NaCl has no low-security options. e.g. crypto_box always encrypts and authenticates. e.g. no RSA-1024; not even RSA-2048. Remaining risk: Users find NaCl too slow ⇒ switch to low-security libraries

• r disable crypto entirely.

How NaCl avoids this risk: NaCl is exceptionally fast. Much faster than other libraries. Keeps up with the network. NaCl operations per for any common pack using AMD Phenom CPU ($190 in 2011): crypto_box: >80000. crypto_box_open crypto_sign_open crypto_sign: >180000.

RSA-1024 Curve25519. RSA- the and continues addresses.

https://sourceforge.net/account https://sourceforge.net/develop

to

http://sourceforge.net/develop.

NaCl has no low-security options. e.g. crypto_box always encrypts and authenticates. e.g. no RSA-1024; not even RSA-2048. Remaining risk: Users find NaCl too slow ⇒ switch to low-security libraries

• r disable crypto entirely.

How NaCl avoids this risk: NaCl is exceptionally fast. Much faster than other libraries. Keeps up with the network. NaCl operations per second for any common packet size, using AMD Phenom II X6 1100T CPU ($190 in 2011): crypto_box: >80000. crypto_box_open: >80000. crypto_sign_open: >70000. crypto_sign: >180000.

NaCl has no low-security options. e.g. crypto_box always encrypts and authenticates. e.g. no RSA-1024; not even RSA-2048. Remaining risk: Users find NaCl too slow ⇒ switch to low-security libraries

• r disable crypto entirely.

How NaCl avoids this risk: NaCl is exceptionally fast. Much faster than other libraries. Keeps up with the network. NaCl operations per second for any common packet size, using AMD Phenom II X6 1100T CPU ($190 in 2011): crypto_box: >80000. crypto_box_open: >80000. crypto_sign_open: >70000. crypto_sign: >180000.

NaCl has no low-security options. e.g. crypto_box always encrypts and authenticates. e.g. no RSA-1024; not even RSA-2048. Remaining risk: Users find NaCl too slow ⇒ switch to low-security libraries

• r disable crypto entirely.

How NaCl avoids this risk: NaCl is exceptionally fast. Much faster than other libraries. Keeps up with the network. NaCl operations per second for any common packet size, using AMD Phenom II X6 1100T CPU ($190 in 2011): crypto_box: >80000. crypto_box_open: >80000. crypto_sign_open: >70000. crypto_sign: >180000. Handles arbitrary packet floods up to ≈30 Mbps per CPU, depending on protocol details.

has no low-security options. crypto_box always encrypts and authenticates. no RSA-1024; not even RSA-2048. Remaining risk: find NaCl too slow ⇒ to low-security libraries ble crypto entirely. NaCl avoids this risk: is exceptionally fast. faster than other libraries. up with the network. NaCl operations per second for any common packet size, using AMD Phenom II X6 1100T CPU ($190 in 2011): crypto_box: >80000. crypto_box_open: >80000. crypto_sign_open: >70000. crypto_sign: >180000. Handles arbitrary packet floods up to ≈30 Mbps per CPU, depending on protocol details. But wait

• 1. Pure

for any pack 80000 1500-b fill up a

• 2. Pure

for many from same if application crypto_box crypto_box_beforenm crypto_box_afternm

w-security options. always and authenticates. RSA-1024; RSA-2048. too slow ⇒ w-security libraries entirely. avoids this risk: exceptionally fast. than other libraries. the network. NaCl operations per second for any common packet size, using AMD Phenom II X6 1100T CPU ($190 in 2011): crypto_box: >80000. crypto_box_open: >80000. crypto_sign_open: >70000. crypto_sign: >180000. Handles arbitrary packet floods up to ≈30 Mbps per CPU, depending on protocol details. But wait, it’s even

• 1. Pure secret-key

for any packet size: 80000 1500-byte pack fill up a 1 Gbps link.

• 2. Pure secret-key

for many packets from same public k if application splits crypto_box into crypto_box_beforenm crypto_box_afternm

• ptions.

authenticates. ⇒ ries risk: raries. rk. NaCl operations per second for any common packet size, using AMD Phenom II X6 1100T CPU ($190 in 2011): crypto_box: >80000. crypto_box_open: >80000. crypto_sign_open: >70000. crypto_sign: >180000. Handles arbitrary packet floods up to ≈30 Mbps per CPU, depending on protocol details. But wait, it’s even faster!

• 1. Pure secret-key crypto

for any packet size: 80000 1500-byte packets/second fill up a 1 Gbps link.

• 2. Pure secret-key crypto

for many packets from same public key, if application splits crypto_box into crypto_box_beforenm and crypto_box_afternm.

NaCl operations per second for any common packet size, using AMD Phenom II X6 1100T CPU ($190 in 2011): crypto_box: >80000. crypto_box_open: >80000. crypto_sign_open: >70000. crypto_sign: >180000. Handles arbitrary packet floods up to ≈30 Mbps per CPU, depending on protocol details. But wait, it’s even faster!

• 1. Pure secret-key crypto

for any packet size: 80000 1500-byte packets/second fill up a 1 Gbps link.

• 2. Pure secret-key crypto

for many packets from same public key, if application splits crypto_box into crypto_box_beforenm and crypto_box_afternm.

• perations per second

any common packet size, AMD Phenom II X6 1100T ($190 in 2011): crypto_box: >80000. crypto_box_open: >80000. crypto_sign_open: >70000. crypto_sign: >180000. Handles arbitrary packet floods ≈30 Mbps per CPU, ending on protocol details. But wait, it’s even faster!

• 1. Pure secret-key crypto

for any packet size: 80000 1500-byte packets/second fill up a 1 Gbps link.

• 2. Pure secret-key crypto

for many packets from same public key, if application splits crypto_box into crypto_box_beforenm and crypto_box_afternm.

• 3. Very
• f forged

under kno no time (This do for forgeries but flooded continue to known

• 4. Fast batch

doubling crypto_sign_open for valid

per second packet size, Phenom II X6 1100T 2011): 80000. crypto_box_open: >80000. crypto_sign_open: >70000. 180000. ry packet floods Mbps per CPU,

• tocol details.

But wait, it’s even faster!

• 1. Pure secret-key crypto

for any packet size: 80000 1500-byte packets/second fill up a 1 Gbps link.

• 2. Pure secret-key crypto

for many packets from same public key, if application splits crypto_box into crypto_box_beforenm and crypto_box_afternm.

• 3. Very fast rejection
• f forged packets

under known public no time spent on decryption. (This doesn’t help for forgeries under but flooded server continue providing to known keys.)

• 4. Fast batch verification,

doubling speed of crypto_sign_open for valid signatures.

• nd

size, 1100T 80000. 70000. floods CPU, details. But wait, it’s even faster!

• 1. Pure secret-key crypto

for any packet size: 80000 1500-byte packets/second fill up a 1 Gbps link.

• 2. Pure secret-key crypto

for many packets from same public key, if application splits crypto_box into crypto_box_beforenm and crypto_box_afternm.

• 3. Very fast rejection
• f forged packets

under known public keys: no time spent on decryption. (This doesn’t help much for forgeries under new keys, but flooded server can continue providing fast service to known keys.)

• 4. Fast batch verification,

doubling speed of crypto_sign_open for valid signatures.

But wait, it’s even faster!

• 1. Pure secret-key crypto

for any packet size: 80000 1500-byte packets/second fill up a 1 Gbps link.

• 2. Pure secret-key crypto

for many packets from same public key, if application splits crypto_box into crypto_box_beforenm and crypto_box_afternm.

• 3. Very fast rejection
• f forged packets

under known public keys: no time spent on decryption. (This doesn’t help much for forgeries under new keys, but flooded server can continue providing fast service to known keys.)

• 4. Fast batch verification,

doubling speed of crypto_sign_open for valid signatures.

ait, it’s even faster! Pure secret-key crypto any packet size: 1500-byte packets/second a 1 Gbps link. Pure secret-key crypto any packets same public key, application splits crypto_box into crypto_box_beforenm and crypto_box_afternm.

• 3. Very fast rejection
• f forged packets

under known public keys: no time spent on decryption. (This doesn’t help much for forgeries under new keys, but flooded server can continue providing fast service to known keys.)

• 4. Fast batch verification,

doubling speed of crypto_sign_open for valid signatures. Cryptographic The main achieve very without ECC, not much stronger Curve25519, curves: safecurves.cr.yp.to Salsa20, much larger Poly1305, information-theo EdDSA, collision-resilience

even faster! ey crypto size: packets/second link. ey crypto ets public key, splits into crypto_box_beforenm and crypto_box_afternm.

• 3. Very fast rejection
• f forged packets

under known public keys: no time spent on decryption. (This doesn’t help much for forgeries under new keys, but flooded server can continue providing fast service to known keys.)

• 4. Fast batch verification,

doubling speed of crypto_sign_open for valid signatures. Cryptographic details The main NaCl wo achieve very high sp without compromising ECC, not RSA: much stronger securit Curve25519, not NSA/NIST curves: safecurves.cr.yp.to Salsa20, not AES: much larger securit Poly1305, not HMA information-theoretic EdDSA, not ECDSA: collision-resilience

ets/second and

• 3. Very fast rejection
• f forged packets

under known public keys: no time spent on decryption. (This doesn’t help much for forgeries under new keys, but flooded server can continue providing fast service to known keys.)

• 4. Fast batch verification,

doubling speed of crypto_sign_open for valid signatures. Cryptographic details The main NaCl work we did: achieve very high speeds without compromising securit ECC, not RSA: much stronger security record. Curve25519, not NSA/NIST curves: safecurves.cr.yp.to Salsa20, not AES: much larger security margin. Poly1305, not HMAC: information-theoretic security EdDSA, not ECDSA: collision-resilience et al.

• 3. Very fast rejection
• f forged packets

under known public keys: no time spent on decryption. (This doesn’t help much for forgeries under new keys, but flooded server can continue providing fast service to known keys.)

• 4. Fast batch verification,

doubling speed of crypto_sign_open for valid signatures. Cryptographic details The main NaCl work we did: achieve very high speeds without compromising security. ECC, not RSA: much stronger security record. Curve25519, not NSA/NIST curves: safecurves.cr.yp.to Salsa20, not AES: much larger security margin. Poly1305, not HMAC: information-theoretic security. EdDSA, not ECDSA: collision-resilience et al.

ery fast rejection rged packets known public keys: time spent on decryption. doesn’t help much rgeries under new keys,

• ded server can

continue providing fast service wn keys.) ast batch verification, doubling speed of crypto_sign_open lid signatures. Cryptographic details The main NaCl work we did: achieve very high speeds without compromising security. ECC, not RSA: much stronger security record. Curve25519, not NSA/NIST curves: safecurves.cr.yp.to Salsa20, not AES: much larger security margin. Poly1305, not HMAC: information-theoretic security. EdDSA, not ECDSA: collision-resilience et al. Speed education Oops, there’s users complet

• f how fast

rejection ets public keys:

• n decryption.

help much under new keys, server can ing fast service verification,

• f

crypto_sign_open signatures. Cryptographic details The main NaCl work we did: achieve very high speeds without compromising security. ECC, not RSA: much stronger security record. Curve25519, not NSA/NIST curves: safecurves.cr.yp.to Salsa20, not AES: much larger security margin. Poly1305, not HMAC: information-theoretic security. EdDSA, not ECDSA: collision-resilience et al. Speed education Oops, there’s another users completely una

• f how fast crypto

decryption. eys, service Cryptographic details The main NaCl work we did: achieve very high speeds without compromising security. ECC, not RSA: much stronger security record. Curve25519, not NSA/NIST curves: safecurves.cr.yp.to Salsa20, not AES: much larger security margin. Poly1305, not HMAC: information-theoretic security. EdDSA, not ECDSA: collision-resilience et al. Speed education Oops, there’s another risk: users completely unaware

• f how fast crypto can be.

Cryptographic details The main NaCl work we did: achieve very high speeds without compromising security. ECC, not RSA: much stronger security record. Curve25519, not NSA/NIST curves: safecurves.cr.yp.to Salsa20, not AES: much larger security margin. Poly1305, not HMAC: information-theoretic security. EdDSA, not ECDSA: collision-resilience et al. Speed education Oops, there’s another risk: users completely unaware

• f how fast crypto can be.

Cryptographic details The main NaCl work we did: achieve very high speeds without compromising security. ECC, not RSA: much stronger security record. Curve25519, not NSA/NIST curves: safecurves.cr.yp.to Salsa20, not AES: much larger security margin. Poly1305, not HMAC: information-theoretic security. EdDSA, not ECDSA: collision-resilience et al. Speed education Oops, there’s another risk: users completely unaware

• f how fast crypto can be.

Example: “PRESERVE contributes to the security and privacy of future vehicle-to-vehicle and vehicle- to-infrastructure communication systems by addressing critical issues like performance, scalability, and deployability of V2X security systems.” preserve-project.eu

Cryptographic details main NaCl work we did: achieve very high speeds without compromising security. not RSA: stronger security record. Curve25519, not NSA/NIST curves: safecurves.cr.yp.to Salsa20, not AES: larger security margin.

• ly1305, not HMAC:

rmation-theoretic security. EdDSA, not ECDSA: collision-resilience et al. Speed education Oops, there’s another risk: users completely unaware

• f how fast crypto can be.

Example: “PRESERVE contributes to the security and privacy of future vehicle-to-vehicle and vehicle- to-infrastructure communication systems by addressing critical issues like performance, scalability, and deployability of V2X security systems.” preserve-project.eu “[In] most the pack 750 pack maximum goes wel (2,265 pack Processing second and ms can ha hardware. a Pentium needs ab a verification cryptographic likely to

details work we did: high speeds romising security. security record. NSA/NIST safecurves.cr.yp.to S: security margin. HMAC: retic security. ECDSA: collision-resilience et al. Speed education Oops, there’s another risk: users completely unaware

• f how fast crypto can be.

Example: “PRESERVE contributes to the security and privacy of future vehicle-to-vehicle and vehicle- to-infrastructure communication systems by addressing critical issues like performance, scalability, and deployability of V2X security systems.” preserve-project.eu “[In] most driving the packet rates do 750 packets per second. maximum highway goes well beyond this (2,265 packets per Processing 1,000 pack second and processing ms can hardly be met

• hardware. As discussed

a Pentium D 3.4 GHz needs about 5 times a verification : : : a cryptographic co-p likely to be necessa

did: security. record. NSA/NIST safecurves.cr.yp.to rgin. security. Speed education Oops, there’s another risk: users completely unaware

• f how fast crypto can be.

Example: “PRESERVE contributes to the security and privacy of future vehicle-to-vehicle and vehicle- to-infrastructure communication systems by addressing critical issues like performance, scalability, and deployability of V2X security systems.” preserve-project.eu “[In] most driving situations the packet rates do not exceed 750 packets per second. Only maximum highway scenario : goes well beyond this value (2,265 packets per second). Processing 1,000 packets per second and processing each in ms can hardly be met by current

• hardware. As discussed in [32]

a Pentium D 3.4 GHz processo needs about 5 times as long a verification : : : a dedicated cryptographic co-processor is likely to be necessary.”

Speed education Oops, there’s another risk: users completely unaware

• f how fast crypto can be.

Example: “PRESERVE contributes to the security and privacy of future vehicle-to-vehicle and vehicle- to-infrastructure communication systems by addressing critical issues like performance, scalability, and deployability of V2X security systems.” preserve-project.eu “[In] most driving situations : : : the packet rates do not exceed 750 packets per second. Only the maximum highway scenario : : : goes well beyond this value (2,265 packets per second). : : : Processing 1,000 packets per second and processing each in 1 ms can hardly be met by current

• hardware. As discussed in [32],

a Pentium D 3.4 GHz processor needs about 5 times as long for a verification : : : a dedicated cryptographic co-processor is likely to be necessary.”

education there’s another risk: completely unaware fast crypto can be. Example: PRESERVE contributes to the security and privacy of future vehicle-to-vehicle and vehicle- to-infrastructure communication systems by addressing critical like performance, scalability, deployability of V2X security systems.” preserve-project.eu “[In] most driving situations : : : the packet rates do not exceed 750 packets per second. Only the maximum highway scenario : : : goes well beyond this value (2,265 packets per second). : : : Processing 1,000 packets per second and processing each in 1 ms can hardly be met by current

• hardware. As discussed in [32],

a Pentium D 3.4 GHz processor needs about 5 times as long for a verification : : : a dedicated cryptographic co-processor is likely to be necessary.” “NEON

• n 1GHz

5.48 cycles/ 2.30 cycles/ for Salsa20, 498349 cycles 624846 cycles for Curve25519

another risk: unaware crypto can be. contributes to the rivacy of future vehicle-to-vehicle and vehicle- communication addressing critical rmance, scalability, y of V2X security preserve-project.eu “[In] most driving situations : : : the packet rates do not exceed 750 packets per second. Only the maximum highway scenario : : : goes well beyond this value (2,265 packets per second). : : : Processing 1,000 packets per second and processing each in 1 ms can hardly be met by current

• hardware. As discussed in [32],

a Pentium D 3.4 GHz processor needs about 5 times as long for a verification : : : a dedicated cryptographic co-processor is likely to be necessary.” “NEON crypto” (CHES

• n 1GHz Cortex-A8

5.48 cycles/byte (1.4 2.30 cycles/byte (3.4 for Salsa20, Poly1305. 498349 cycles (2000/second), 624846 cycles (1600/second) for Curve25519 DH,

risk: e. to the future vehicle- communication critical scalability, security “[In] most driving situations : : : the packet rates do not exceed 750 packets per second. Only the maximum highway scenario : : : goes well beyond this value (2,265 packets per second). : : : Processing 1,000 packets per second and processing each in 1 ms can hardly be met by current

• hardware. As discussed in [32],

a Pentium D 3.4 GHz processor needs about 5 times as long for a verification : : : a dedicated cryptographic co-processor is likely to be necessary.” “NEON crypto” (CHES 2012)

• n 1GHz Cortex-A8 core:

5.48 cycles/byte (1.4 Gbps), 2.30 cycles/byte (3.4 Gbps) for Salsa20, Poly1305. 498349 cycles (2000/second), 624846 cycles (1600/second) for Curve25519 DH, verify.

“[In] most driving situations : : : the packet rates do not exceed 750 packets per second. Only the maximum highway scenario : : : goes well beyond this value (2,265 packets per second). : : : Processing 1,000 packets per second and processing each in 1 ms can hardly be met by current

• hardware. As discussed in [32],

a Pentium D 3.4 GHz processor needs about 5 times as long for a verification : : : a dedicated cryptographic co-processor is likely to be necessary.” “NEON crypto” (CHES 2012)

• n 1GHz Cortex-A8 core:

5.48 cycles/byte (1.4 Gbps), 2.30 cycles/byte (3.4 Gbps) for Salsa20, Poly1305. 498349 cycles (2000/second), 624846 cycles (1600/second) for Curve25519 DH, verify.

“[In] most driving situations : : : the packet rates do not exceed 750 packets per second. Only the maximum highway scenario : : : goes well beyond this value (2,265 packets per second). : : : Processing 1,000 packets per second and processing each in 1 ms can hardly be met by current

• hardware. As discussed in [32],

a Pentium D 3.4 GHz processor needs about 5 times as long for a verification : : : a dedicated cryptographic co-processor is likely to be necessary.” “NEON crypto” (CHES 2012)

• n 1GHz Cortex-A8 core:

5.48 cycles/byte (1.4 Gbps), 2.30 cycles/byte (3.4 Gbps) for Salsa20, Poly1305. 498349 cycles (2000/second), 624846 cycles (1600/second) for Curve25519 DH, verify. 1GHz Cortex-A8 was high-end smartphone core in 2010: e.g., Samsung Exynos 3110 (Galaxy S); TI OMAP3630 (Motorola Droid X); Apple A4 (iPad 1/iPhone 4).

“[In] most driving situations : : : the packet rates do not exceed 750 packets per second. Only the maximum highway scenario : : : goes well beyond this value (2,265 packets per second). : : : Processing 1,000 packets per second and processing each in 1 ms can hardly be met by current

• hardware. As discussed in [32],

a Pentium D 3.4 GHz processor needs about 5 times as long for a verification : : : a dedicated cryptographic co-processor is likely to be necessary.” “NEON crypto” (CHES 2012)

• n 1GHz Cortex-A8 core:

5.48 cycles/byte (1.4 Gbps), 2.30 cycles/byte (3.4 Gbps) for Salsa20, Poly1305. 498349 cycles (2000/second), 624846 cycles (1600/second) for Curve25519 DH, verify. 1GHz Cortex-A8 was high-end smartphone core in 2010: e.g., Samsung Exynos 3110 (Galaxy S); TI OMAP3630 (Motorola Droid X); Apple A4 (iPad 1/iPhone 4). 2013: Allwinner A13, $5 in bulk.

most driving situations : : : packet rates do not exceed packets per second. Only the maximum highway scenario : : : ell beyond this value packets per second). : : : cessing 1,000 packets per and processing each in 1 can hardly be met by current

• are. As discussed in [32],

entium D 3.4 GHz processor about 5 times as long for verification : : : a dedicated cryptographic co-processor is to be necessary.” “NEON crypto” (CHES 2012)

• n 1GHz Cortex-A8 core:

5.48 cycles/byte (1.4 Gbps), 2.30 cycles/byte (3.4 Gbps) for Salsa20, Poly1305. 498349 cycles (2000/second), 624846 cycles (1600/second) for Curve25519 DH, verify. 1GHz Cortex-A8 was high-end smartphone core in 2010: e.g., Samsung Exynos 3110 (Galaxy S); TI OMAP3630 (Motorola Droid X); Apple A4 (iPad 1/iPhone 4). 2013: Allwinner A13, $5 in bulk. Case study: 1985 ElGamal (R; S) is if BH(M) and R; S Here q is B is standa A is signer’s H(M) is Signer generates as secret easily solves

driving situations : : : do not exceed

• second. Only the

ay scenario : : :

• nd this value

er second). : : : 1,000 packets per cessing each in 1 e met by current discussed in [32], GHz processor times as long for a dedicated co-processor is necessary.” “NEON crypto” (CHES 2012)

• n 1GHz Cortex-A8 core:

5.48 cycles/byte (1.4 Gbps), 2.30 cycles/byte (3.4 Gbps) for Salsa20, Poly1305. 498349 cycles (2000/second), 624846 cycles (1600/second) for Curve25519 DH, verify. 1GHz Cortex-A8 was high-end smartphone core in 2010: e.g., Samsung Exynos 3110 (Galaxy S); TI OMAP3630 (Motorola Droid X); Apple A4 (iPad 1/iPhone 4). 2013: Allwinner A13, $5 in bulk. Case study: EdDSA 1985 ElGamal signatur (R; S) is signature if BH(M) ≡ ARRS and R; S ∈ {0; 1; : Here q is standard B is standard base, A is signer’s public H(M) is hash of message. Signer generates A as secret powers of easily solves for S.

situations : : : exceed Only the rio : : : value second). : : : per each in 1 current [32], cessor long for dedicated r is “NEON crypto” (CHES 2012)

• n 1GHz Cortex-A8 core:

5.48 cycles/byte (1.4 Gbps), 2.30 cycles/byte (3.4 Gbps) for Salsa20, Poly1305. 498349 cycles (2000/second), 624846 cycles (1600/second) for Curve25519 DH, verify. 1GHz Cortex-A8 was high-end smartphone core in 2010: e.g., Samsung Exynos 3110 (Galaxy S); TI OMAP3630 (Motorola Droid X); Apple A4 (iPad 1/iPhone 4). 2013: Allwinner A13, $5 in bulk. Case study: EdDSA 1985 ElGamal signatures: (R; S) is signature of M if BH(M) ≡ ARRS (mod q) and R; S ∈ {0; 1; : : : ; q − 2} Here q is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Signer generates A and R as secret powers of B; easily solves for S.

“NEON crypto” (CHES 2012)

• n 1GHz Cortex-A8 core:

5.48 cycles/byte (1.4 Gbps), 2.30 cycles/byte (3.4 Gbps) for Salsa20, Poly1305. 498349 cycles (2000/second), 624846 cycles (1600/second) for Curve25519 DH, verify. 1GHz Cortex-A8 was high-end smartphone core in 2010: e.g., Samsung Exynos 3110 (Galaxy S); TI OMAP3630 (Motorola Droid X); Apple A4 (iPad 1/iPhone 4). 2013: Allwinner A13, $5 in bulk. Case study: EdDSA 1985 ElGamal signatures: (R; S) is signature of M if BH(M) ≡ ARRS (mod q) and R; S ∈ {0; 1; : : : ; q − 2}. Here q is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Signer generates A and R as secret powers of B; easily solves for S.

“NEON crypto” (CHES 2012) 1GHz Cortex-A8 core: cycles/byte (1.4 Gbps), cycles/byte (3.4 Gbps) Salsa20, Poly1305. 498349 cycles (2000/second), 624846 cycles (1600/second) Curve25519 DH, verify. Cortex-A8 was high-end rtphone core in 2010: e.g., Samsung Exynos 3110 (Galaxy S); OMAP3630 (Motorola Droid Apple A4 (iPad 1/iPhone 4). Allwinner A13, $5 in bulk. Case study: EdDSA 1985 ElGamal signatures: (R; S) is signature of M if BH(M) ≡ ARRS (mod q) and R; S ∈ {0; 1; : : : ; q − 2}. Here q is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Signer generates A and R as secret powers of B; easily solves for S. 1990 Schno

• 1. Hash

BH(M) ≡ Reduces

• 2. Replace

with two BH(M)=H Saves time

• 3. Simplify

BH(M)=H Saves time

• 4. Merge

BH(R;M) ⇒ Resilient

(CHES 2012) rtex-A8 core: (1.4 Gbps), (3.4 Gbps)

• ly1305.

(2000/second), (1600/second) DH, verify. was high-end in 2010: e.g., Exynos 3110 (Galaxy S); (Motorola Droid ad 1/iPhone 4). A13, $5 in bulk. Case study: EdDSA 1985 ElGamal signatures: (R; S) is signature of M if BH(M) ≡ ARRS (mod q) and R; S ∈ {0; 1; : : : ; q − 2}. Here q is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Signer generates A and R as secret powers of B; easily solves for S. 1990 Schnorr improvements:

• 1. Hash R in the exp

BH(M) ≡ AH(R)RS Reduces attacker control.

• 2. Replace three exp

with two exponents: BH(M)=H(R) ≡ AR Saves time in verification.

• 3. Simplify by relab

BH(M)=H(R) ≡ AR Saves time in verification.

• 4. Merge the hashes:

BH(R;M) ≡ ARS. ⇒ Resilient to H collisions.

2012) Gbps), Gbps) (2000/second), (1600/second) . high-end e.g., (Galaxy S); Droid 1/iPhone 4). in bulk. Case study: EdDSA 1985 ElGamal signatures: (R; S) is signature of M if BH(M) ≡ ARRS (mod q) and R; S ∈ {0; 1; : : : ; q − 2}. Here q is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Signer generates A and R as secret powers of B; easily solves for S. 1990 Schnorr improvements:

• 1. Hash R in the exponent:

BH(M) ≡ AH(R)RS. Reduces attacker control.

• 2. Replace three exponents

with two exponents: BH(M)=H(R) ≡ ARS=H(R). Saves time in verification.

• 3. Simplify by relabeling S:

BH(M)=H(R) ≡ ARS. Saves time in verification.

• 4. Merge the hashes:

BH(R;M) ≡ ARS. ⇒ Resilient to H collisions.

Case study: EdDSA 1985 ElGamal signatures: (R; S) is signature of M if BH(M) ≡ ARRS (mod q) and R; S ∈ {0; 1; : : : ; q − 2}. Here q is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Signer generates A and R as secret powers of B; easily solves for S. 1990 Schnorr improvements:

• 1. Hash R in the exponent:

BH(M) ≡ AH(R)RS. Reduces attacker control.

• 2. Replace three exponents

with two exponents: BH(M)=H(R) ≡ ARS=H(R). Saves time in verification.

• 3. Simplify by relabeling S:

BH(M)=H(R) ≡ ARS. Saves time in verification.

• 4. Merge the hashes:

BH(R;M) ≡ ARS. ⇒ Resilient to H collisions.

study: EdDSA ElGamal signatures: is signature of M

) ≡ ARRS

(mod q) ; S ∈ {0; 1; : : : ; q − 2}. is standard prime, standard base, signer’s public key, is hash of message. generates A and R secret powers of B; solves for S. 1990 Schnorr improvements:

• 1. Hash R in the exponent:

BH(M) ≡ AH(R)RS. Reduces attacker control.

• 2. Replace three exponents

with two exponents: BH(M)=H(R) ≡ ARS=H(R). Saves time in verification.

• 3. Simplify by relabeling S:

BH(M)=H(R) ≡ ARS. Saves time in verification.

• 4. Merge the hashes:

BH(R;M) ≡ ARS. ⇒ Resilient to H collisions.

• 5. Eliminate

BS ≡ RA Simpler,

• 6. Comp

Saves space

• 7. Use half-size

Saves space

EdDSA signatures: signature of M

S

(mod q) ; : : : ; q − 2}. rd prime, base, public key, message. A and R

• f B;

S. 1990 Schnorr improvements:

• 1. Hash R in the exponent:

BH(M) ≡ AH(R)RS. Reduces attacker control.

• 2. Replace three exponents

with two exponents: BH(M)=H(R) ≡ ARS=H(R). Saves time in verification.

• 3. Simplify by relabeling S:

BH(M)=H(R) ≡ ARS. Saves time in verification.

• 4. Merge the hashes:

BH(R;M) ≡ ARS. ⇒ Resilient to H collisions.

• 5. Eliminate inversions

BS ≡ RAH(R;M). Simpler, faster.

• 6. Compress R to

Saves space in signatures.

• 7. Use half-size H

Saves space in signatures.

q) 2}. 1990 Schnorr improvements:

• 1. Hash R in the exponent:

BH(M) ≡ AH(R)RS. Reduces attacker control.

• 2. Replace three exponents

with two exponents: BH(M)=H(R) ≡ ARS=H(R). Saves time in verification.

• 3. Simplify by relabeling S:

BH(M)=H(R) ≡ ARS. Saves time in verification.

• 4. Merge the hashes:

BH(R;M) ≡ ARS. ⇒ Resilient to H collisions.

• 5. Eliminate inversions for signer:

BS ≡ RAH(R;M). Simpler, faster.

• 6. Compress R to H(R; M).

Saves space in signatures.

• 7. Use half-size H output.

Saves space in signatures.

1990 Schnorr improvements:

• 1. Hash R in the exponent:

BH(M) ≡ AH(R)RS. Reduces attacker control.

• 2. Replace three exponents

with two exponents: BH(M)=H(R) ≡ ARS=H(R). Saves time in verification.

• 3. Simplify by relabeling S:

BH(M)=H(R) ≡ ARS. Saves time in verification.

• 4. Merge the hashes:

BH(R;M) ≡ ARS. ⇒ Resilient to H collisions.

• 5. Eliminate inversions for signer:

BS ≡ RAH(R;M). Simpler, faster.

• 6. Compress R to H(R; M).

Saves space in signatures.

• 7. Use half-size H output.

Saves space in signatures.

1990 Schnorr improvements:

• 1. Hash R in the exponent:

BH(M) ≡ AH(R)RS. Reduces attacker control.

• 2. Replace three exponents

with two exponents: BH(M)=H(R) ≡ ARS=H(R). Saves time in verification.

• 3. Simplify by relabeling S:

BH(M)=H(R) ≡ ARS. Saves time in verification.

• 4. Merge the hashes:

BH(R;M) ≡ ARS. ⇒ Resilient to H collisions.

• 5. Eliminate inversions for signer:

BS ≡ RAH(R;M). Simpler, faster.

• 6. Compress R to H(R; M).

Saves space in signatures.

• 7. Use half-size H output.

Saves space in signatures. Subsequent research: extensive theoretical study of security of Schnorr’s system.

1990 Schnorr improvements:

• 1. Hash R in the exponent:

BH(M) ≡ AH(R)RS. Reduces attacker control.

• 2. Replace three exponents

with two exponents: BH(M)=H(R) ≡ ARS=H(R). Saves time in verification.

• 3. Simplify by relabeling S:

BH(M)=H(R) ≡ ARS. Saves time in verification.

• 4. Merge the hashes:

BH(R;M) ≡ ARS. ⇒ Resilient to H collisions.

• 5. Eliminate inversions for signer:

BS ≡ RAH(R;M). Simpler, faster.

• 6. Compress R to H(R; M).

Saves space in signatures.

• 7. Use half-size H output.

Saves space in signatures. Subsequent research: extensive theoretical study of security of Schnorr’s system. But patented. ⇒ DSA, ECDSA avoided most improvements.

1990 Schnorr improvements:

• 1. Hash R in the exponent:

BH(M) ≡ AH(R)RS. Reduces attacker control.

• 2. Replace three exponents

with two exponents: BH(M)=H(R) ≡ ARS=H(R). Saves time in verification.

• 3. Simplify by relabeling S:

BH(M)=H(R) ≡ ARS. Saves time in verification.

• 4. Merge the hashes:

BH(R;M) ≡ ARS. ⇒ Resilient to H collisions.

• 5. Eliminate inversions for signer:

BS ≡ RAH(R;M). Simpler, faster.

• 6. Compress R to H(R; M).

Saves space in signatures.

• 7. Use half-size H output.

Saves space in signatures. Subsequent research: extensive theoretical study of security of Schnorr’s system. But patented. ⇒ DSA, ECDSA avoided most improvements. Patent expired in 2008.

Schnorr improvements: Hash R in the exponent: ≡ AH(R)RS. Reduces attacker control. Replace three exponents wo exponents:

=H(R) ≡ ARS=H(R).

time in verification. Simplify by relabeling S:

=H(R) ≡ ARS.

time in verification. Merge the hashes:

) ≡ ARS.

Resilient to H collisions.

• 5. Eliminate inversions for signer:

BS ≡ RAH(R;M). Simpler, faster.

• 6. Compress R to H(R; M).

Saves space in signatures.

• 7. Use half-size H output.

Saves space in signatures. Subsequent research: extensive theoretical study of security of Schnorr’s system. But patented. ⇒ DSA, ECDSA avoided most improvements. Patent expired in 2008. EdDSA (CHES Duif–Lange–Schw Use elliptic −1-twisted ⇒ very high natural side-channel no exceptional Skip signature Support Use double-size and include Generate as a secret ⇒ Avoid

improvements: the exponent: RS. er control. exponents

• nents:

ARS=H(R). verification. relabeling S: ARS. verification. hashes: . collisions.

• 5. Eliminate inversions for signer:

BS ≡ RAH(R;M). Simpler, faster.

• 6. Compress R to H(R; M).

Saves space in signatures.

• 7. Use half-size H output.

Saves space in signatures. Subsequent research: extensive theoretical study of security of Schnorr’s system. But patented. ⇒ DSA, ECDSA avoided most improvements. Patent expired in 2008. EdDSA (CHES 2011 Duif–Lange–Schwab Use elliptic curves −1-twisted Edwards” ⇒ very high speed, natural side-channel no exceptional cases. Skip signature comp Support batch verific Use double-size H and include A as input. Generate R deterministically as a secret hash of ⇒ Avoid PlayStation

rovements:

• nent:
• nents

: collisions.

• 5. Eliminate inversions for signer:

BS ≡ RAH(R;M). Simpler, faster.

• 6. Compress R to H(R; M).

Saves space in signatures.

• 7. Use half-size H output.

Saves space in signatures. Subsequent research: extensive theoretical study of security of Schnorr’s system. But patented. ⇒ DSA, ECDSA avoided most improvements. Patent expired in 2008. EdDSA (CHES 2011 Bernstein– Duif–Lange–Schwabe–Yang): Use elliptic curves in “complete −1-twisted Edwards” form. ⇒ very high speed, natural side-channel protection, no exceptional cases. Skip signature compression. Support batch verification. Use double-size H output, and include A as input. Generate R deterministically as a secret hash of M. ⇒ Avoid PlayStation disaster.

• 5. Eliminate inversions for signer:

BS ≡ RAH(R;M). Simpler, faster.

• 6. Compress R to H(R; M).

Saves space in signatures.

• 7. Use half-size H output.

Saves space in signatures. Subsequent research: extensive theoretical study of security of Schnorr’s system. But patented. ⇒ DSA, ECDSA avoided most improvements. Patent expired in 2008. EdDSA (CHES 2011 Bernstein– Duif–Lange–Schwabe–Yang): Use elliptic curves in “complete −1-twisted Edwards” form. ⇒ very high speed, natural side-channel protection, no exceptional cases. Skip signature compression. Support batch verification. Use double-size H output, and include A as input. Generate R deterministically as a secret hash of M. ⇒ Avoid PlayStation disaster.

Eliminate inversions for signer: RAH(R;M). Simpler, faster. Compress R to H(R; M). space in signatures. half-size H output. space in signatures. Subsequent research: extensive retical study of security of rr’s system.

• patented. ⇒ DSA, ECDSA

avoided most improvements. expired in 2008. EdDSA (CHES 2011 Bernstein– Duif–Lange–Schwabe–Yang): Use elliptic curves in “complete −1-twisted Edwards” form. ⇒ very high speed, natural side-channel protection, no exceptional cases. Skip signature compression. Support batch verification. Use double-size H output, and include A as input. Generate R deterministically as a secret hash of M. ⇒ Avoid PlayStation disaster. A higher-securit OpenSSL security least secure 2.1 million

• n Cortex-A8.

Our new security 1.8 million

• n Cortex-A8.

inversions for signer: . to H(R; M). signatures. H output. signatures. research: extensive

• f security of

stem. DSA, ECDSA improvements. in 2008. EdDSA (CHES 2011 Bernstein– Duif–Lange–Schwabe–Yang): Use elliptic curves in “complete −1-twisted Edwards” form. ⇒ very high speed, natural side-channel protection, no exceptional cases. Skip signature compression. Support batch verification. Use double-size H output, and include A as input. Generate R deterministically as a secret hash of M. ⇒ Avoid PlayStation disaster. A higher-security curve OpenSSL secp160-r1 security level only least secure ECC option: 2.1 million cycles

• n Cortex-A8.

Our new Curve41417, security level above 1.8 million cycles

• n Cortex-A8.

signer: ).

• utput.

extensive security of ECDSA rovements. EdDSA (CHES 2011 Bernstein– Duif–Lange–Schwabe–Yang): Use elliptic curves in “complete −1-twisted Edwards” form. ⇒ very high speed, natural side-channel protection, no exceptional cases. Skip signature compression. Support batch verification. Use double-size H output, and include A as input. Generate R deterministically as a secret hash of M. ⇒ Avoid PlayStation disaster. A higher-security curve OpenSSL secp160-r1, security level only 280, least secure ECC option: 2.1 million cycles

• n Cortex-A8.

Our new Curve41417, security level above 2200: 1.8 million cycles

• n Cortex-A8.

EdDSA (CHES 2011 Bernstein– Duif–Lange–Schwabe–Yang): Use elliptic curves in “complete −1-twisted Edwards” form. ⇒ very high speed, natural side-channel protection, no exceptional cases. Skip signature compression. Support batch verification. Use double-size H output, and include A as input. Generate R deterministically as a secret hash of M. ⇒ Avoid PlayStation disaster. A higher-security curve OpenSSL secp160-r1, security level only 280, least secure ECC option: 2.1 million cycles

• n Cortex-A8.

Our new Curve41417, security level above 2200: 1.8 million cycles

• n Cortex-A8.