Post Quantum Cryptography Team Presenter: Lily Chen National Institute of Standards and Technology (NIST)
Quantum computing will break many public-key cryptographic algorithms/schemes ◦ Key agreement (e.g. DH and MQV) ◦ Digital signatures (e.g. RSA and DSA) ◦ Encryption (e.g. RSA)

These algorithms have been used to protect Internet protocols (e.g. IPsec) and applications (e.g.TLS)

NIST is studying “quantum-safe” replacements

This talk will focus on practical aspects ◦ For security, see Yi-Kai Liu’s talk later today ◦ Key establishment: ephemeral Diffie-Hellman ◦ Authentication: signature or pre-shared key
Key establishment through RSA, DHE, or DH Client Server ◦ RSA – Client encrypts pre- master secret using server’s Client RSA public key Hello Server Hello Certificate* ◦ DHE – Ephemeral Diffie- ServerKeyExchange* Hellman CertificateRequest* ◦ DH – Client generates an ServerHelloDone ephemeral DH public value. Certificate* ClientKeyExchange* Pre-master secret is generated CertificateVerify* using server static public key {ChangeCipherSpec} Finished
Server authentication {ChangeCipherSpec} ◦ RSA – implicit (by key Finished confirmation) ◦ DHE - signature Application data Application Data ◦ DH – implicit (by key confirmation)
IKE ◦ A replacement of ephemeral Diffie-Hellman key agreement should have a fast key pair generation scheme ◦ If signatures are used for authentication, both signing and verifying need to be equally efficient

TLS ◦ RSA - encryption replacement needs to have a fast encryption ◦ DHE – fast key pair generation and efficient signature verification ◦ DH – fast key pair generation
Which are most important in practice? ◦ Public and private key sizes ◦ Key pair generation time ◦ Ciphertext size ◦ Encryption/Decryption speed ◦ Signature size ◦ Signature generation/verification time

Not a lot of benchmarks in this area
Lattice-based ◦ NTRU Encryption and NTRU Signature ◦ (Ring-based) Learning with Errors
Code-based ◦ McEliece encryption and CFS signatures
Multivariate ◦ HFE, psFlash , Quartz (a variant of HFE),
Many more…. ◦ hash-based signatures ◦ isogeny-based schemes ◦ etc...

All have their pros and cons Algorithm KeyGen Decrypt Encrypt Public Private Ciphertext Time* Key* Time Time Time Key Key Size Size Scaling Scaling (RSA (RSA (RSA Size (bits) (((bits)(bits) sign=1) sign=1) sign=1) (bits) NTRUEncrypt 10 0.1 0.1 ~3000 ~4000 ~3000 k2 k McEliece 5 1 0.02 651264 1098256 1660 k2 k2 QuasiQuasi----CyclicCyclic 5 1 0.02 4801 9602 9602 k2 k McEliece

RSA 50 1 0.02 1024 1024 1024 k6 k3 DHDHDH 0.5 0.5 0.5 1024 160 1024 k4 k3 ECC 0.1 0.1 0.1 320 160 320 k2 k

• Disclaimer – these are rough estimates for comparison purposes only, not benchmarks. Numbers are for 80 bits of security. * Time and key scaling ignore log k factors Algorithm KeyGen Sign Verify Limited Public Private Key Signature Time* Key *** Time Time Time Lifetime Key Size Size Size (bits) Scaling Scaling (RSA (((RSA(RSA (RSA ??? sign=1) sign=1) sign=1)

WinternitzWinternitz----MerkleMerkle 200 1 0.2 220 368 15200 17024 k2 k2 signatures 10000 1 0.2 230 368 22304 18624 500000 2 0.2 240 368 29344 20224 GLP ssignaturesignatures 0.01 0.5 0.02 11800 1620 8950 k2 k (lattice(lattice----based)based) CFS signature 5 2000 0.02 9437184 ~15000000 144 exp(o(k)) exp(o(k)) (code based) Psflash signature 50 1 0.1 576992 44400 296 k3 k3 (multivariate) Quartz signature 100 2 0.05 126000 11500 80 k3 k3 (((multivariate)(multivariate)

RSA 50 1 0.02 1024 1024 1024 k6 k3 DSA 0.5 0.5 0.5 1024 160 320 k4 k3 ECDSA 0.1 0.1 0.1 320 160 320 k2 k

• Disclaimer – these are rough estimates for comparison purposes only, not benchmarks. Numbers are for 80 bits of security. * Time and key scaling ignore log k factors
For the most of the potential PQC replacements, the times needed for encryption, decryption, signing, verification are acceptable
Some key sizes are significantly larger than RSA and DL families with the current required security strength ◦ If the public keys do not need to be exchanged, it may not be a problem ◦ But long certificates have been considered as an implementation pitfall for TLS handshake
Some ciphertext size and signature size are not quite plausible ◦ It may become a show stopper for the bandwidth/space limited environment
Key pair generation time for the encryption schemes is not bad at all ◦ One-time encryption can be used to replace ephemeral DH for “perfect forward secrecy”
No easy “drop-in” replacements ◦ Many factors need to be considered
We need more time to study
Would be nice to have more benchmarks
We would like more input

Questions? Comments? [email protected]

NIST PQC Team: Lily Chen, Stephen Jorden, Yi-Kai Liu, Dustin Moody, Rene Peralta, Ray Perlner, Daniel Smith