Cryptography in the next cycle - SEP304 - AWS re:Inforce 2019

© 2019,Amazon Web Services, Inc. or its affiliates. All rights reserved.
Cryptography in the next cycle
Matthew Campagna
Sr. Principal Engineer
AWS
S E P 3 0 4

Agenda
Classical cryptography
Post-quantum cryptography
Hybrid key exchange
Transport Layer Security (TLS)
Signal-to-noise (s2n)
Post-quantum s2n

Classical cryptography
Data integrity
• Hash functions
• SHA2, SHA3
• MACs
• HMAC
• GMAC/CMAC
• Signatures
• RSA/ECDSA
Confidentiality
• Encryption
• AES/ChaCha20
• Modes
• CTR, GCM
• CBC, XTS
• Key agreement
• Diffie–Hellman
• ECDH
Authenticity
• MACs
• HMAC
• GMAC/CMAC
• Signatures
• RSA/ECDSA
Non-repudiation
• Signatures
• RSA
• ECDSA
• Hash chains
Security application or protocol

Security of an algorithm
Ln[a, c]
O(2n)
𝑛
The computation complexity of the best known
attacks
• Defines the bit strength of an algorithm
• Bounds the algorithm security lifetime
How assured am I that better attacks are not coming?
• How long has this problem been studied?
• Who has studied it, and what is the published record of that
analysis?

Best known attacks
Invented Standardized Widely used
Best known attack
Year Attack
ECC 1985 1999 2000s 1978 Pollard rho 2 𝑛
FF 1976 1991 1990s 1990 NFS Ln[1/3, (64/9)1/3]
RSA 1978 1998 1990s 1990 NFS Ln[1/3, (64/9)1/3]
AES 1998 2001 2005 - Exhaust 2n
DES 1975 1977 1980s 1991 Differential cryptanalysis
SHA1 – 1995 1990s 2005 Collision < 2 𝑛
SHA2 2001 2002 2005 – Birthday attack 2 𝑛
SHA3 2008 2015 ? – Birthday attack 2 𝑛
ChaCha20 2008 2015 2018 – Exhaust 2n

Best known attacks
Invented Standardized Widely used
Best known attack
Year Attack
ECC 1985 1999 2000s 1978 Pollard rho 2 𝑛
FF 1976 1991 1990s 1990 NFS Ln[1/3, (64/9)1/3]
RSA 1978 1998 1990s 1990 NFS Ln[1/3, (64/9)1/3]
AES 1998 2001 2005 - Exhaust 2n
DES 1975 1977 1980s 1991 Differential cryptanalysis
SHA1 - 1995 1990s 2005 Collision < 2 𝑛
SHA2 2001 2002 2005 - Birthday attack 2 𝑛
SHA3 2008 2015 ? - Birthday attack 2 𝑛
ChaCha20 2008 2015 2018 - Exhaust 2n

Security strengths
Cryptographic
strength: O(2n)
Symmetric algorithm Hash algorithm Elliptic curve RSA and DH
80 bits 3DES (2 key) SHA-1 160 bits 1,024 bits
112 bits 3DES (3 key) SHA-224 224 bits 2,048 bits
128 bits AES-128 SHA-256 256 bits 3,072 bits

Publication record
<2001 2001–2005 2006–2010 2011–2015 2016+ Total
“Diffie Hellman” 3,197 8,420 15,100 16,300 16,500 59,517
“Elliptic curve cryptography” 503 3,050 7,900 12,600 9,200 33,253
“Rijndael” (AES) 419 3,930 6,620 9,050 4,950 24,969
“Discrete log problem” 2,125 3,450 6,030 8,080 4,940 24,625
“RSA encryption” 1,568 2,310 3,450 4,950 3,320 15,598
“SHA256” (SHA2) 0 165 1,180 3,670 6,300 11,315
“Keccak” (SHA3) 0 0 188 1,390 1,500 3,078
ChaCha20 0 0 2 82 393 477

Data confidentiality requirement

Here is what keeps me up at night
AWS Cloud
Client Internet
Record

AWS Cloud
Client Internet
Record
New
capabilities

AWS Cloud
Client Internet
Record
New
capabilities
and
harvest
Plaintext data

Quantum computing
A classical computer’s
information unit is
made of bits, where
each bit is 0 or 1
0
1
A quantum computer’s information unit is made of
qubits; a qubit in superposition holds both 0 and 1
ۧ|0
ۧ|0 + ۧ|1
√2
ۧ|1

Quantum computing
1
0
• n classical bits can hold 1 of 2n possible
values at any given time
• n qubits can hold all 2n possible values at
the same time
• But, if we attempt to retrieve the value, it
collapses to a single value
Quantum algorithms can be constructed to compute on 2n possible values at
the same time—but only some are amenable to extracting the desired output

Impact of quantum computing on cryptography
Shor’s algorithm (1994): Can solve the discrete log problem (breaking Diffie–
Hellman and elliptic curve cryptography) and factor composite numbers (breaking
RSA)
Grover’s algorithm (1996): Can search an unsorted database of N items in Ο( 𝑁 )
time (reducing the security of symmetric ciphers and pre-image search for hash
functions)

Security against best known attacks
Invented Standardized Widely used Best known attack Security
ECC 1985 1999 2000s Shor’s poly(log(n))
FF 1976 1991 1990s Shor’s poly(log(n))
RSA 1978 1998 1990s Shor’s poly(log(n))
AES 1998 2001 2005 Grover’s 2 𝑛
SHA2 2001 2002 2005 Birthday attack/Grover’s 2 𝑛
SHA3 2008 2015 ? Birthday attack/Grover’s 2 𝑛
ChaCha20 2007 2015* 2018 Grover’s 2 𝑛

Quantum computing
Current public-key cryptography is vulnerable given a large-scale fault-tolerant
quantum computer
Eventual loss of confidentiality of the data that we are protecting today
Future forgeability of things we sign today
What is the impact?
Confidential data encrypted today via TLS/SSH/IPSec is discoverable in the future
In the future, someone can forge signatures

Quantum computing
Current state of the art—no large-scale quantum computing
Steady (but slow) progress toward scalable, fault-tolerant quantum computing
Quantum decoherence (loss of superposition state)
Factoring RSA-2048 requires tens of millions of qubits
Quantum computing is not expected to replace commodity computing
It initially will operate as co-processors in HPC tasks
Simulation of quantum physics, with applications in material science, pharma, and energy

Timeline for quantum computing

Post-quantum or quantum-safe cryptography
Develop new cryptographic algorithms for classical computing systems that are
secure against a quantum adversary
• Key establishment schemes
• Digital signature schemes
Start now—it takes a decade to analyze, standardize, and deploy

NIST standardization process
2015: NSA changes Suite B algorithms to prepare for post-quantum
2016: NIST issues a call for proposals for post-quantum schemes
2017: Round 1—69 initial complete packages
2019: Round 2—17 key encapsulation mechanisms, 9 signature schemes
Jan.
2017
Nov.
2017
April
2018
Aug.
2019
2022–
2023
Jan.
2019

What have we been doing?
2013: Initial ETSI IQC Quantum Safe Cryptography Workshop
2014: Started ETSI QSC Industry Specification Group
2016: ETSI QSC became a technical committee to produce standards
2017: Contributed two submissions to the NIST call for proposals
2018: Participated in the Open Quantum Safe development team
Released an open-source implementation of quantum-safe SSH
2019: Active in three drafts on post-quantum specifications
Rapporteur for ETSI Technical Specification on Hybrid Key Exchanges
Editors of two Internet Engineering Task Force (IETF) drafts for hybrid TLS
Integrated hybrid key exchanges into s2n

NIST submissions with AWS
BIKE – Bit Flipping Key Exchange SIKE – Supersingular Isogeny Key Exchange
Two post-quantum key encapsulation mechanisms (PQ KEM)

Alice Bob
sk
pk

Alice Bob
sk
pk
ssct

Alice Bob
sk
pk
ssct
ss = Decap(sk, ct )

NIST PQ KEM Round 2 submissions
5,000 bytes
1,000 bytes
10,000 bytes
20,000 bytes
300,000 bytes
1M 10M 100M 1B100K
2,500 bytes

Publication record
<2001 2001–2005 2006–2010 2011–2015 2016+ Total
“Diffie Hellman” 3,197 8,420 15,100 16,300 16,500 59,517
“Elliptic curve cryptography” 503 3,050 7,900 12,600 9,200 33,253
“Rijndael” (AES) 419 3,930 6,620 9,050 4,950 24,969
“Discrete log problem” 2,125 3,450 6,030 8,080 4,940 24,625
“Code-based” cryptography 372 669 1,770 3,640 3,410 9,861
“Elliptic curve” isogeny 1,600 1,110 1,630 2,100 1,820 8,260
“Lattice-based” cryptography 208 468 1,070 2,900 3,520 8,166
“Keccak” (SHA3) 0 0 188 1,390 1,500 3,078
ChaCha20 0 0 2 82 393 477

Quantum-safe cryptography: Recap
We can’t solely rely on new algorithms until we have more assurance
We want to test them to understand the impact that they have on applications and
protocols that we use today
We do both: Perform hybrid key exchanges
One classical, like elliptic curve Diffie–Hellman
One quantum-safe, like BIKE or SIKE
Combine them in a cryptographically non-lossy way

Hybrid key agreements
BobAlice
Generate (a, A)
K = KDF(aB)
Generate (b, B)
K = KDF(bA)
A
B

BobAlice
Generate (a, A)
Generate (b, B)A
B
( sk, pk ) = Gen( ) , pk

BobAlice
Generate (a, A)
Generate (b, B)A
B
( sk, pk ) = Gen( ) , pk
(ss, ct) = Encaps(pk)
, ct

BobAlice
Generate (a, A)
Generate (b, B)A
B
( sk, pk ) = Gen( ) , pk
, ctss = Decaps(sk, ct)
K = KDF(aB || ss) K = KDF(bA || ss)

TLS protocol
Widely used for protecting Internet traffic over TCP/IP
Designed to authenticate endpoints (commonly only one: the server)
Securely negotiate a shared secret
Use this shared secret to protect application data
TLS protects the confidentiality of AWS API requests

Sketch of TLS 1.2
Client Server (Cert(d, N), e)
ClientHello
This is a sketch of a TLS_ECDHE_RSA_* negotiated cipher suite connection

Sketch of TLS 1.2
ClientHello
Certificate (Cert(d, N))
ServerKeyExchange (A, sig))
Generate ECDHE (a, A)
sig = Sign(A…, e)

Sketch of TLS 1.2
ClientHello
sig = Sign(A…, e)
Verify(sig, A…, (d, N))
Generate ECDHE (b, B)
keys = derive keys (bA, …)
ClientKeyExchange (B)

Sketch of TLS 1.2
ClientHello
sig = Sign(A…, e)
Verify(sig, A…, (d, N))
keys = derive keys (bA, …)
ClientKeyExchange (B)
keys = derive keys (aB, …)
ApplicationData

s2n
s2n is an AWSLabs open-source library for TLS
Designed to be small and fast with simplicity as a priority
Removes a lot of cruft that has built up in libssl
Currently handles all of the Amazon S3 traffic
libssl
libcrypto

s2n
libssl
libcrypto
s2n
s2n is an AWSLabs open-source library for TLS
Designed to be small and fast with simplicity as a priority
Removes a lot of cruft that has built up in libssl
Currently handles all of the Amazon S3 traffic

Provable security in s2n
Proof process
1. Write the algorithm specification in Cryptol (e.g., RFC, whitepaper): https://cryptol.net/
2. Use the Software Analysis Workbench to prove equivalence with specification: https://saw.galois.com/
3. Integrate proofs into Travis CI so that code is reproved on every pull request
Guarantees
1. No LLVM undefined behavior, e.g., no memory errors
2. Code and spec have equivalent input-output behavior
Target modules in s2n: HMAC, DRBG, TLS handshake

PQ-TLS 1.2: Hybrid key exchange
ClientHello
ServerKeyExchange (A, pk, sig))
sig = Sign(A, pk…, e)
Verify(sig, A, pk…, (d, N))
keys = derive keys (bA, ss …)
ClientKeyExchange (B, ct)
keys = derive keys (aB, ss…)
ApplicationData
This is a sketch of a TLS_ECDHE_SIKE_RSA_* negotiated cipher suite connection

ClientHello
ApplicationData
(sk, pk) = KeyGen( )

ClientHello
ApplicationData

ClientHello
ApplicationData
ss = Decaps(sk, ct )

Published hybrid key exchange for TLS draft within the IETF
Added SIKE and BIKE reference code into the s2n code base
Add hybrid key exchange cipher suites into s2n
TLS_ECDHE_BIKE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_SIKE_RSA_WITH_AES_256_GCM_SHA384
Apply the same rigor to this new code as we do to s2n!

BIKE and SIKE proofs
Targets
• BIKE-1 Level 1
• SIKEp503
Current result: No memory errors in BIKE/SIKE s2n code
Next step: Equivalent IO behavior for specification and code
Proofs are complete for SIKE and BIKE
Proofs are open-sourced and contained in the AWSLabs GitHub repository

PQ-TLS 1.2: Bandwidth usage (bytes)
ClientHello ServerKeyExchange ClientKeyExchange Handshake Total
ECDHE 139 329 66 2363
ECDHE-BIKE Hybrid 151 2950 2685 7384
ECDHE-SIKE Hybrid 151 786 545 3157

PQ s2n performance numbers: P50 (ms)
Local host us-west-2 us-west-1 eu-west-2 ap-south-1
Ping 0.08 0.69 21 133 22
ECDHE 1.2 2.6 43 278 434
ECDHE-BIKE Hybrid 25 27 67 302 458
ECDHE-SIKE Hybrid 155 156 197 431 588

PQ s2n performance numbers: P99 (ms)
Local host us-west-2 us-west-1 eu-west-2 ap-south-1
Ping 0.08 0.69 21 133 22
ECDHE 2.2 3.5 47 284 454
ECDHE-BIKE Hybrid 26 27 71 309 478
ECDHE-SIKE Hybrid 156 157 201 438 607

What comes next?
Increase performance (10x): Move from reference code to optimized code
Add a lattice-based KEM into PQ s2n
Move from the Round 1 candidates to Round 2
In time, we will integrate PQ s2n into AWS SDKs and deploy PQ-hybrid into service
endpoints
Move from TLS 1.2 to TLS 1.3, and consider alternatives to PQ-hybrid

Double-hulled TLS
AWS Cloud
Client
FIPS-certified
ECDHE & TLS-AES256-GCM-SHA384

Double-hulled TLS
AWS Cloud
Client
PQ-KEM & TLS-CHACHA20-POLY1305-SHA3-384
FIPS-certified
ECDHE & TLS-AES256-GCM-SHA384

Additional topics
Post-quantum OpenSSH on liboqs
https://github.com/open-quantum-safe/openssh-portable
Post-quantum VPN
66% of IPSec configurations are using DH-1024 < recommended
PQCrypto-VPN project
https://github.com/Microsoft/PQCrypto-VPN
Derived-key encryption modes (KMS-derived key mode, AES-GCM-SIV)
Wide-block ciphers to encrypt at cloud scale; additional diversity
Cryptographic computing models
How do we compute over encrypted data?
Privacy-preserving machine learning

7th ETSI/IQC Quantum Safe Cryptography Workshop
When: November 5–7, 2019
Where: Amazon Headquarters in Seattle, US
Who: Admission is open to all
Executive track: CTO/CISO/executives and government decision makers looking to
understand current trends in quantum-safe or post-quantum cryptography
Technical track: Technologists and standards participants looking to increase their
knowledge in the state-of-the-art developments in quantum-safe cryptography

Additional details
NIST: https://csrc.nist.gov/Projects/Post-Quantum-Cryptography
ETSI: https://www.etsi.org/events/1607-etsi-iqc-quantum-safe-cryptography-
workshop-2019
IETF: https://tools.ietf.org/html/draft-campagna-tls-bike-sike-hybrid-01
and https://tools.ietf.org/html/draft-stebila-tls-hybrid-design-00
AWSLabs: https://github.com/awslabs/s2n
Open Quantum Safe: https://openquantumsafe.org/

Thank you!
Matthew Campagna
campagna@amazon.com
Nicholas Allen
Eric Crockett
Mike Dodds (Galois)
Nir Drucker
Shay Gueron
Andrew Hopkins
Colm MacCarthaigh
Douglas Stebila (liboqs)
Alex Weibel

Cryptography in the next cycle - SEP304 - AWS re:Inforce 2019

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Cryptography in the next cycle - SEP304 - AWS re:Inforce 2019

Similar to Cryptography in the next cycle - SEP304 - AWS re:Inforce 2019 (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Cryptography in the next cycle - SEP304 - AWS re:Inforce 2019