Mctiny: Fast High-Confidence Post-Quantum Key Erasure for Tiny Network Servers Daniel J
Total Page：16
File Type：pdf, Size：1020Kb
McTiny: Fast High-Confidence Post-Quantum Key Erasure for Tiny Network Servers Daniel J. Bernstein, University of Illinois at Chicago, Ruhr University Bochum; Tanja Lange, Eindhoven University of Technology https://www.usenix.org/conference/usenixsecurity20/presentation/bernstein This paper is included in the Proceedings of the 29th USENIX Security Symposium. August 12–14, 2020 978-1-939133-17-5 Open access to the Proceedings of the 29th USENIX Security Symposium is sponsored by USENIX. ARTIFACT McTiny: EVALUATED Fast High-Confidence Post-Quantum Key Erasure for Tiny Network Servers PASSED Daniel J. Bernstein Tanja Lange University of Illinois at Chicago, Eindhoven University of Technology Ruhr University Bochum Abstract 1 Introduction TLS 1.3 highlights the importance of “forward secrecy” by Recent results have shown that some post-quantum cryp- switching completely to Diffie–Hellman-based cryptography tographic systems have encryption and decryption perfor- for confidentiality. The client initiates the connection and al- mance comparable to fast elliptic-curve cryptography (ECC) ready on the first message sends the preferred cipher suite and or even better. However, this performance metric is con- a public key. These systems are typically based on elliptic sidering only CPU time and ignoring bandwidth and stor- curves though some finite-field options remain. Elliptic-curve age. High-confidence post-quantum encryption systems have keys consume only 32–64 bytes and thus add very little over- much larger keys than ECC. For example, the code-based head to the packets and computation is very fast, even on cryptosystem recommended by the PQCRYPTO project uses small devices. public keys of 1MB. Unfortunately, if large quantum computers are built then Fast key erasure (to provide “forward secrecy”) requires Shor’s quantum algorithm [33] breaks ECC in polynomial new public keys to be constantly transmitted. Either the server time. In the two decades since Shor found this quantum needs to constantly generate, store, and transmit large keys, or speedup, research in cryptography has progressed to find sys- it needs to receive, store, and use large keys from the clients. tems that remain secure under attacks with quantum comput- This is not necessarily a problem for overall bandwidth, but it ers. There are several approaches to designing such post- is a problem for storage and computation time on tiny network quantum systems but the main categories for public-key servers. All straightforward approaches allow easy denial-of- encryption systems are based on codes, lattices, or—more service attacks. recently—isogenies between supersingular elliptic curves. Code-based cryptography [23] was invented by McEliece This paper describes a protocol, suitable for today’s net- in 1978 and is thus just one year younger than RSA and works and tiny servers, in which clients transmit their code- has held up much stronger against cryptanalysis than RSA. based one-time public keys to servers. Servers never store full Lattice-based cryptography started more than 15 years later client public keys but work on parts provided by the clients, and security estimates are still developing; see, e.g., the re- without having to maintain any per-client state. Intermediate cent paper [1] claiming a 400× speedup in lattice attacks. results are stored on the client side in the form of encrypted Isogenies in their current use started only in 2011 [17]. cookies and are eventually combined by the server to obtain In 2015, the European project PQCRYPTO issued recom- the ciphertext. Requirements on the server side are very small: mendations [2] for confidence-inspiring post-quantum sys- storage of one long-term private key, which is much smaller tems; for public-key encryption the only recommended sys- than a public key, and a few small symmetric cookie keys, tem was a code-based system which is closely related to which are updated regularly and erased after use. The proto- McEliece’s original proposal. However, when in 2016 Google col is highly parallel, requiring only a few round trips, and ran an experiment [8] deploying post-quantum cryptography involves total bandwidth not much larger than a single public to TLS connections between Chrome (Canary) browsers and key. The total number of packets sent by each side is 971, Google sites they did not choose a code-based system but a each fitting into one IPv6 packet of less than 1280 bytes. much more recent system based on lattices. The main issue The protocol makes use of the structure of encryption in with the high-confidence code-based system is that it requires code-based cryptography and benefits from small ciphertexts a much larger key size—1MB vs. 1kB—for the same esti- in code-based cryptography. mated level of security. Google piggybacked the lattice-based USENIX Association 29th USENIX Security Symposium 1731 system with ECC so that the security of the combined system number of connections to a server. These attacks fill up all would not be weaker than a pure ECC system. of the memory available on the server for keeping track of In April 2018, Google’s Langley reported [21] on another connections. The server is forced to stop serving some con- experiment with post-quantum cryptography, this time test- nections, including connections from legitimate clients. These ing no particular system but different key sizes. They tested attacks are usually much less expensive than comparably ef- initiation packets of sizes 400, 1100, and 10000 bytes, saying fective attacks that try to use all available network bandwidth that these are meant to represent systems based on isogenies or that try to consume all available CPU time. and based on different types of lattices. Langley justified their choice by writing “in some cases the public-key + cipher- text size was too large to be viable in the context of TLS”. 2.1 A Classic Example: SYN Flooding There were too many sites that dropped the largest size so it The “SYN flooding” denial-of-service attack [14] rose to was skipped from further experiments and replaced by 3300 prominence twenty years ago when it was used to disable an bytes. For these sizes they measured the increase in latency. ISP in New York, possibly in retaliation for anti-spam efforts; In a second experiment they measured round-trip times, this see [9]. “SYN cookies” [4] address SYN flooding, but from a time even skipping the 3300-byte size. These sizes are a far broader security perspective they are highly unsatisfactory, as cry from what is needed to transmit the 1MB keys of the we now explain. McEliece cryptosystem. See also the failure reported in [12] Recall that in a normal TCP connection, say an HTTP to handle 300KB keys in OpenSSL. connection, the client sends a TCP “SYN” packet to the server For the experiments it is reasonable to use new systems in containing a random 32-bit initial sequence number (ISN); combination with ECC; see [18–20] for a new lattice-plus- the server sends back a “SYNACK” packet acknowledging ECC experiment by Google and Cloudflare. However, this the client ISN and containing another random ISN; the client does not help with post-quantum security if lattices turn out sends an “ACK” packet acknowledging the server ISN. At this to be much weaker than currently assumed. This raises the point a TCP connection is established, and both sides are free question how network protocols could possibly use the high- to send data. The client sends an HTTP request (preferably as confidence McEliece cryptosystem. part of the ACK packet), and the server responds. Of course, the key could be chopped into pieces and sent in The server allocates memory to track SYN-SYNACK pairs, separate packets and the server could be instructed to buffer including IP addresses, port numbers, and ISNs. This is ex- the pieces and reassemble the pieces but this allows rogue actly the memory targeted by SYN flooding. A SYN-flooding clients to flood the RAM on the server. See Section2. attacker simply sends a stream of SYNs to the server with- This paper introduces McTiny, a new protocol that solves out responding to the resulting SYNACKs. Once the SYN- the problem of memory-flooding denial-of-service attacks SYNACK memory fills up, the server is forced to start throw- for code-based cryptography. McTiny handles the 1MB keys ing away some SYN-SYNACK pairs, and is no longer able to of the McEliece cryptosystem, having the same basic data handle the corresponding ACKs. The server can try to guess flow as TLS in which the client creates a fresh public key for which SYN-SYNACK pairs are more likely to be from le- each connection and sends it as the first step of the protocol. gitimate clients, and prioritize keeping those, but a sensible McTiny splits the public keys into pieces small enough to fit attacker will forge SYNs that look just like legitimate SYNs. into network packets. On the client side the overhead is small If the server has enough SYN-SYNACK memory for c con- compared to creating the key and sending 1MB. The server is nections, but is receiving 100c indistinguishable SYNs per not required to allocate any memory per client and only ever RTT, then a legitimate client’s ACK fails with probability at needs to process information that fits into one Internet packet, least 99%. making McTiny suitable for tiny network servers. SYN cookies store SYN-SYNACK pairs in the network Sections2 and3 motivate tiny network servers and review rather than in server memory. Specifically, the server encodes existing results. Section4 gives background in coding the- its SYN-SYNACK pair as an authenticated cookie inside the ory. Sections5 and6 explain our new McTiny protocol.