# Cost of upgrading to PQCrypto

We already have recommendations on what PQCrypto to use: PDF (page 11)

Symmetric encryption Thoroughly analyzed, 256-bit keys:

• AES-256
• Salsa20 with a 256-bit key

Symmetric authentication Information-theoretic MACs:

• GCM using a 96-bit nonce and a 128-bit authenticator
• Poly1305

Public-key encryption McEliece with binary Goppa codes:

• length n = 6960, dimension k = 5413, t = 119 errors

Public-key signatures Hash-based (minimal assumptions):

• XMSS with any of the parameters specified in CFRG draft
• SPHINCS-256

What would it cost to upgrade to those recommendations?

We assume that the recommendations will survive further scrutiny and that upgrading software is for free. In practice it will happen as part of a software upgrade that will happen anyway.

• Disk usage
• RAM usage
• CPU usage
• Bandwidth usage

for a normal user and for a normal website?

Since users mostly visit the same websites as they did the day before I am thinking that the key exchange may not be so scary after all. If the SSL certificate is only downloaded every few months, then it will be very little extra bandwidth.

• This entails some rather open-ended speculation about what post-quantum crypto will survive scrutiny. Some relevant references about trials and practical engineering concerns: imperialviolet.org/2018/04/11/pqconftls.html Notes on a second preliminary trial at Google: imperialviolet.org/2018/12/12/cecpq2.html – Squeamish Ossifrage Mar 7 '19 at 8:17
• Let's assume the current recommendation are safe to use. – Ole Tange Mar 7 '19 at 8:36
• So are you just looking for a table of the parameter choices and current cycle counts of all the NIST PQCRYPTO candidates, like you can find at bench.cr.yp.to? – Squeamish Ossifrage Mar 7 '19 at 8:40
• I am more after something a bit closer to what normal users will experience in their daily life, so thanks for the imperialviolet link. Are computers and bandwidths no longer a limiting factor for the adoption of PQCrypto? I still recall the time when https was visibly slower than http due to slow CPUs. That is no longer the case. – Ole Tange Mar 7 '19 at 11:57

As for McEliece, performance data suggests it needs about 2M cycles for decryption, which happens once during a TLS handshake, so about 1ms on a 2GHz CPU. However, the public key is 1.3MB which is usually transferred once per handshake. The actual ciphertext is only $$n$$ bits and so only a bit larger than a comparable RSA encryption. You may want to note though that modern TLS 1.3 doesn't support key transport (ie public-key encryption for key agreement) anymore.