NaCl: a new crypto library AES-128, RSA-2048, etc. are widely - - PowerPoint PPT Presentation

NaCl: a new crypto library

• D. J. Bernstein, U. Illinois Chicago

& T. U. Eindhoven Tanja Lange, T. U. Eindhoven Joint work with: Peter Schwabe, R. U. Nijmegen 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.

NaCl: a new crypto library

• D. J. Bernstein, U. Illinois Chicago

& T. U. Eindhoven Tanja Lange, T. U. Eindhoven Joint work with: Peter Schwabe, R. U. Nijmegen 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.

a new crypto library Bernstein, U. Illinois Chicago

• U. Eindhoven

Lange, T. U. Eindhoven

• rk with:

Schwabe, R. U. Nijmegen 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

crypto library

• U. Illinois Chicago

Eindhoven

• U. Eindhoven
• R. U. Nijmegen

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

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. Related p Various p language github.com/jedisct1/libsodium TweetNaCl:

• n the path

Bernstein, Lange, Schw tweetnacl.cr.yp.to twitter.com/tweetnacl Benchma implementations bench.cr.yp.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. Related projects Various ports, repack language bindings, github.com/jedisct1/libsodium TweetNaCl: NaCl

• n the path towards

Bernstein, van Gas Lange, Schwabe, S tweetnacl.cr.yp.to twitter.com/tweetnacl Benchmarking of > implementations using bench.cr.yp.to

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. Related projects Various ports, repackaging, language bindings, etc.: e.g., github.com/jedisct1/libsodium TweetNaCl: NaCl in 100 tweets;

• n the path towards full audit.

Bernstein, van Gastel, Janssen, Lange, Schwabe, Smetsers. tweetnacl.cr.yp.to twitter.com/tweetnacl Benchmarking of >1000 crypto implementations using same bench.cr.yp.to

“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. Related projects Various ports, repackaging, language bindings, etc.: e.g., github.com/jedisct1/libsodium TweetNaCl: NaCl in 100 tweets;

• n the path towards full audit.

Bernstein, van Gastel, Janssen, Lange, Schwabe, Smetsers. tweetnacl.cr.yp.to twitter.com/tweetnacl Benchmarking of >1000 crypto implementations using same API: bench.cr.yp.to

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. Related projects Various ports, repackaging, language bindings, etc.: e.g., github.com/jedisct1/libsodium TweetNaCl: NaCl in 100 tweets;

• n the path towards full audit.

Bernstein, van Gastel, Janssen, Lange, Schwabe, Smetsers. tweetnacl.cr.yp.to twitter.com/tweetnacl Benchmarking of >1000 crypto implementations using same API: bench.cr.yp.to 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

• simple!

applications need more?” applications crypto_box: DNSCrypt, authenticated DNS queries; enDNS. TLS replacement. Ethos OS, lacement. encrypted-chat app. Related projects Various ports, repackaging, language bindings, etc.: e.g., github.com/jedisct1/libsodium TweetNaCl: NaCl in 100 tweets;

• n the path towards full audit.

Bernstein, van Gastel, Janssen, Lange, Schwabe, Smetsers. tweetnacl.cr.yp.to twitter.com/tweetnacl Benchmarking of >1000 crypto implementations using same API: bench.cr.yp.to 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

more?” : DNSCrypt, authenticated queries; replacement. app. Related projects Various ports, repackaging, language bindings, etc.: e.g., github.com/jedisct1/libsodium TweetNaCl: NaCl in 100 tweets;

• n the path towards full audit.

Bernstein, van Gastel, Janssen, Lange, Schwabe, Smetsers. tweetnacl.cr.yp.to twitter.com/tweetnacl Benchmarking of >1000 crypto implementations using same API: bench.cr.yp.to 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−

Related projects Various ports, repackaging, language bindings, etc.: e.g., github.com/jedisct1/libsodium TweetNaCl: NaCl in 100 tweets;

• n the path towards full audit.

Bernstein, van Gastel, Janssen, Lange, Schwabe, Smetsers. tweetnacl.cr.yp.to twitter.com/tweetnacl Benchmarking of >1000 crypto implementations using same API: bench.cr.yp.to 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.

Related projects rious ports, repackaging, language bindings, etc.: e.g., github.com/jedisct1/libsodium eetNaCl: NaCl in 100 tweets; path towards full audit. Bernstein, van Gastel, Janssen, Lange, Schwabe, Smetsers. tweetnacl.cr.yp.to twitter.com/tweetnacl Benchmarking of >1000 crypto implementations using same API: bench.cr.yp.to 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

repackaging, bindings, etc.: e.g., github.com/jedisct1/libsodium NaCl in 100 tweets; ards full audit. Gastel, Janssen, e, Smetsers. tweetnacl.cr.yp.to twitter.com/tweetnacl

• f >1000 crypto

using same API: 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.

aging, .g., github.com/jedisct1/libsodium tweets; audit. Janssen, etsers. crypto same API: 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. Timing attack+defense tutorial: Schwabe talk tomorrow 11:00.

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. Timing attack+defense tutorial: Schwabe talk tomorrow 11:00. 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. Timing attack+defense tutorial: Schwabe talk tomorrow 11:00. 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. Timing attack+defense tutorial: Schwabe talk tomorrow 11:00. 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. Timing attack+defense tutorial: Schwabe talk tomorrow 11:00. 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. Timing attack+defense tutorial: Schwabe talk tomorrow 11:00. 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. Timing attack+defense tutorial: abe talk tomorrow 11:00. 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. attack+defense tutorial: tomorrow 11:00. 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. tutorial: 11:00. 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 see, e.g.,

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 see, e.g., 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, e.g., Lucky 13 and 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, e.g., Lucky 13 and 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, e.g., Lucky 13 and POODLE. 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, e.g., Lucky 13 and POODLE. 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, e.g., Lucky 13 and POODLE. 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, e.g., Lucky 13 and POODLE. 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, e.g., Lucky 13 and POODLE. 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, e.g., Lucky 13 and POODLE. 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: e.g., Lucky 13 and POODLE. 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: 13 and POODLE. 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. POODLE. 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 bench.cr.yp.to.

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 bench.cr.yp.to. 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 bench.cr.yp.to. 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 bench.cr.yp.to. 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 bench.cr.yp.to. 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 bench.cr.yp.to. 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 bench.cr.yp.to. 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 bench.cr.yp.to. 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 . 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 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 uses 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 uses secret AES load 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 on ARM uses 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

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 on ARM uses 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 on ARM uses 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 on ARM uses 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 on ARM uses 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 on ARM uses 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 on ARM uses 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 on ARM uses 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 on ARM 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 on ARM 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 ARM 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. Also fast “NEON

• n 1GHz

498349 cycles + 7.78 cycles/b for box; 624846 cycles

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. Also fast on small “NEON crypto” (CHES

• n 1GHz ARM Cortex-A8

498349 cycles (2000/second) + 7.78 cycles/byte for box; and for verify 624846 cycles (1600/second).

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. Also fast on small devices. “NEON crypto” (CHES 2012)

• n 1GHz ARM Cortex-A8 co

498349 cycles (2000/second) + 7.78 cycles/byte (1 Gbps) for box; and for verify: 624846 cycles (1600/second).

• 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. Also fast on small devices. “NEON crypto” (CHES 2012)

• n 1GHz ARM Cortex-A8 core:

498349 cycles (2000/second) + 7.78 cycles/byte (1 Gbps) for box; and for verify: 624846 cycles (1600/second).

• 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. Also fast on small devices. “NEON crypto” (CHES 2012)

• n 1GHz ARM Cortex-A8 core:

498349 cycles (2000/second) + 7.78 cycles/byte (1 Gbps) for box; and for verify: 624846 cycles (1600/second). 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).

• 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. Also fast on small devices. “NEON crypto” (CHES 2012)

• n 1GHz ARM Cortex-A8 core:

498349 cycles (2000/second) + 7.78 cycles/byte (1 Gbps) for box; and for verify: 624846 cycles (1600/second). 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.

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. Also fast on small devices. “NEON crypto” (CHES 2012)

• n 1GHz ARM Cortex-A8 core:

498349 cycles (2000/second) + 7.78 cycles/byte (1 Gbps) for box; and for verify: 624846 cycles (1600/second). 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. 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

rejection ets public keys:

• n decryption.

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

• f

crypto_sign_open signatures. Also fast on small devices. “NEON crypto” (CHES 2012)

• n 1GHz ARM Cortex-A8 core:

498349 cycles (2000/second) + 7.78 cycles/byte (1 Gbps) for box; and for verify: 624846 cycles (1600/second). 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. 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

decryption. eys, service Also fast on small devices. “NEON crypto” (CHES 2012)

• n 1GHz ARM Cortex-A8 core:

498349 cycles (2000/second) + 7.78 cycles/byte (1 Gbps) for box; and for verify: 624846 cycles (1600/second). 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. 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.

Also fast on small devices. “NEON crypto” (CHES 2012)

• n 1GHz ARM Cortex-A8 core:

498349 cycles (2000/second) + 7.78 cycles/byte (1 Gbps) for box; and for verify: 624846 cycles (1600/second). 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. 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.

fast on small devices. “NEON crypto” (CHES 2012) 1GHz ARM Cortex-A8 core: 498349 cycles (2000/second) cycles/byte (1 Gbps) ; and for verify: 624846 cycles (1600/second). 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. 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. 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

small devices. (CHES 2012) Cortex-A8 core: (2000/second) yte (1 Gbps) verify: (1600/second). was high-end in 2010: e.g., Exynos 3110 (Galaxy S); (Motorola Droid ad 1/iPhone 4). A13, $5 in bulk. 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. 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.

devices. 2012) core: (2000/second) Gbps) (1600/second). high-end e.g., (Galaxy S); Droid 1/iPhone 4). in bulk. 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. 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.

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. 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.

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. 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

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. 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.

did: security. record. NSA/NIST safecurves.cr.yp.to rgin. security. 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.