Towards Post-Quantum TLS ECC 2019 Kris Kwiatkowski DECEMBER 2, - - PowerPoint PPT Presentation

DECEMBER 2, 2019

Towards Post-Quantum TLS

ECC 2019 Kris Kwiatkowski

OVERVIEW

• OUR APPROACH TO REAL WORLD CRYPTOGRAPHY
• DESIGNING THE EXPERIMENT
• RESULTS
• QUESTIONS

@_henrycase

Kris Kwiatkowski

@grittygrease

Nick Sullivan

@DistributedDave

Dave Levin

@amislove

Alan Mislove

INTRODUCTION: TEAM

@lukevalenta

Luke Valenta

=

@agl__

Adam Langley

Our Approach to Real World Cryptography

MOTIVATION

How best to contribute to the PQC standardization process? Pick an ecosystem and explore the upgrade path.

MOTIVATION

The cryptographic system should be widely deployed and relied on by millions of people for important communications.

Meaningful deployment and impact

Deployments with many different dependencies and complex moving parts are trickier to upgrade. Pick a project that helps uncover potential stumbling blocks.

Non-trivial complexity

There should be well-established requirements and norms for upgrading the ecosystem based on previous upgrades.

Methodology for migration established

MOTIVATION

HTTPS in browsers

The cryptographic system should be widely deployed and relied on by millions of people for important communications.

Meaningful deployment and impact

Deployments with many different dependencies and complex moving parts are trickier to upgrade. Pick a project that helps uncover potential stumbling blocks.

Non-trivial complexity

There should be well-established requirements and norms for upgrading the ecosystem based on previous upgrades.

Methodology for migration established

MOTIVATION

Online life is encrypted Web traffic is 75% HTTPS This includes almost all banking, eCommerce, social media, search, webmail, video streaming, news, and other

• nline activity in a browser or mobile app

Cloudflare well positioned as a CDN

Meaningful deployment and impact

• Variety of browser implementations

○ OS, vendor, devices

• SSL Libraries

○ BoringSSL, NSS, CommonCrypto, sChannel…

• Compatibility
• Embedded app browsing
• HTTPS API clients
• Old (archaic) browsers

Browser complexity

• Anti-virus proxies
• TCP proxies of other types
• National Firewalls
• Forward Proxies (with SNI-filtering)

Other “hidden” participants

• Possibility of DDoS
• Slow updates that require downtime
• Hardware-accelerated TLS offloaders
• Library dependencies: OpenSSL etc.
• TLS terminator boxes/cloud services

Server complexity

Non-trivial complexity

• HTTPS is HTTP with TLS/SSL
• Requirements clearly defined in a form of RFC
• Tooling & methodology for measurements in place

Methodology for migration established

STICKER

Rule of thumb

Breakage rate should be comfortably below 1%

DEPLOYABLE PROTOCOLS

Publish the specification Use test population Detect various breakages

Measure

2012-13 2008 2012

Specify Deploy

Fix bad servers and middleboxes until breakage is low enough Insecure fallback

Adjust

2012-2014

Rule of thumb

Breakage rate should be comfortably below 1%

DEPLOYABLE PROTOCOLS

Develop draft specifications Use test population Detect various breakages

2016-2018 2014-2018 2016-2018

Change the specification to adjust for the reality of the world

2016-2018

Measure Specify Deploy Adjust

Designing the experiment

CPU Usage

DESIGNING THE EXPERIMENT

Protocol Shape Latency Key Size

DESIGNING THE EXPERIMENT

1-RTT The client initiates with its key share, the server responds with its key share, signature and potentially initial data. Post-quantum KEMs fit nicely into this model. No client challenge There is no current requirement for a proof-of-work to be done on the client side. Expensive key exchange is a DoS risk.

Protocol Shape

DESIGNING THE EXPERIMENT

Higher latency If an algorithm takes clock time on the order of network time (10ms+), it may noticeably delay the connection.

CPU Usage

Power consumption Mobile and lightweight devices optimize for battery life. Expensive computations hurt this. Asymmetry risk If an attacker can cause a lot of work using only a small amount of work, it is an amplification attack vector.

Hard-coded sizes in legacy systems Network congestion causes latency Unknowns

Key Size

DESIGNING THE EXPERIMENT

Post-quantum confidentiality for TLS

Previous work

2018 experiment by Adam Langley to measure impact of key size on latency. Implemented “dummy” extension to simulate larger key sizes. Control group: no extension sent Supersingular isogenies (SI): 400 bytes Structured lattices (SL): 1 100 bytes Unstructured lattice standing (ULS): 3 300 bytes https://www.imperialviolet.org/2018/04/11/pqconftls.html

Our experiment

HRSS-SXY (NTRU) SIKE (Isogeny)

OUR EXPERIMENT

Implement and deploy two realistic key agreement ciphers

CECPQ2

NTRU (Round 2)

• NIST level 1
• 1138 byte public key/ciphertext
• Fast Encaps, Decaps, Acceptable KeyGen
• 76000, 22000, 4000/s on Skylake (<1ms)
• 33287, 13605, 2057/s on ARM Cortex-A75
• No decryption errors

CECPQ2b

SIKE/p434 (Round 2)

• NIST level 1
• 330 byte public key, 346 byte ciphertext
• Slow KeyGen, Encaps, Decaps
• 420, 265, 245/s on Skylake (~5ms)
• 269, 165, 155/s on ARM Cortex-A75
• SIDH as a “drop-in” replacement of DH in TLS

OUR EXPERIMENT

Integrate two PQ KEMs into TLS and deploy at scale

Characteristics

• Latency
• Key sizes
• CPU utilization
• Use of existing hardware capabilities for fast implementation

No SHA-3

SHA-256 instead of SHAKE for KEM

Combined mode with X25519

Concatenate and combine with HKDF

OUR EXPERIMENT

Some tweaks

Code available

SIKE : https://github.com/post-quantum-cryptography/c-sike NTRU: https://github.com/google/boringssl/tree/master/crypto/hrss

• TLSv1.3 only: sends

algorithm ID and public keys in TLS ClientHello

• Based on

draft-kiefer-tls-ecdhe-sidh

• Both client and server use

ephemeral keys

• Shared secret is a

concatenation of X25519 and KEM secrets

TLS integration

OUR EXPERIMENT

Ensuring results quality

• Client browsers splitted into 3 groups

○ CONTROL: using X25519 for key exchange ○ CECPQ2: using NTRU combined with X25519 ○ CECPQ2b: using SIKE combined with X25519

• “PQ signal” - TLS extension

exchanged between client and server to indicate participation in the experiment

OUR EXPERIMENT

You could be using post-quantum cryptography

DEPLOYMENT

Cloudflare edge Over 20 million Internet properties Both suites supported Located “close” to users Note: SIKE not cleared for Google servers due to DoS risk

Deployment

Chrome Canary A diverse group of beta testers usually using Intel-based desktop computers and ARM-based mobile devices

Biases of the population

• 64-bit x86 and ARM CPUs only

○ population significantly biased towards powerful CPUs

• “Chrome Canary and Dev Chrome users tend to have worse

networks than the Chrome user population as a whole”, A. Langley https://www.imperialviolet.org/2019/10/30/pqsivssl.html

• Biases result in favoring isogenies over lattices in terms of

performance

S

Duration

• August & September 2019
• 53 days in total

Data

• 10 millions of data samples collected
• represents 5% of TLS connections

sampled

Collected data

SERVER-SIDE RESULTS

NTRU SIKE NTRU SIKE

SERVER-SIDE RESULTS

NTRU SIKE NTRU SIKE

SERVER-SIDE RESULTS

Configuration Additional latency over control group w/ 95% confidence intervals (ms) X25519 NTRU SIKE Latency Difference Mobile, 50th [133,135] [138, 140] [196, 198] 29.44% Mobile, 95th [774, 818] [1001, 1060] [978, 1026] 2.77% Mobile, 99th [2783, 3097] [4057, 4478] [3276, 3646] 18.90% Desktop, 50th [55, 55] [58, 58] [74, 76] 22.67% Desktop, 95th [350, 354] [417, 421] [421, 425] 0.95% Desktop, 99th [1226 1246] [1481, 1509] [1344, 1368] 9.30%

SERVER-SIDE RESULTS

Maritz-Jarrett estimators

• Pre-production performance testing

○ Send hardcoded ClientHello and drop connection just after ○ Distribute injectors on multiple machines

Challenges: pre-production testing

SIKE NTRU

NTRU

• Lattice vs Isogeny based key exchange:

○ NTRU looks like better candidate for TLS ○ High-performance isogeny-based public key crypto less developed than lattice based

• At 50th percentile, the CPU cost dominates handshake

latency

• However, key size plays a factor at 99th percentile

○ Root cause not found

SIKE NTRU

Conclusion

Questions?