EverCrypt: A Fast, Verified, Cross-Platform Cryptographic Provider Jonathan Protzenko∗, Bryan Parnoz, Aymeric Fromherzz, Chris Hawblitzel∗, Marina Polubelovay, Karthikeyan Bhargavany Benjamin Beurdouchey, Joonwon Choi∗x, Antoine Delignat-Lavaud∗,Cedric´ Fournet∗, Natalia Kulatovay, Tahina Ramananandro∗, Aseem Rastogi∗, Nikhil Swamy∗, Christoph M. Wintersteiger∗, Santiago Zanella-Beguelin∗ ∗Microsoft Research zCarnegie Mellon University yInria xMIT Abstract—We present EverCrypt: a comprehensive collection prone (due in part to Intel and AMD reporting CPU features of verified, high-performance cryptographic functionalities avail- inconsistently [78]), with various cryptographic providers able via a carefully designed API. The API provably supports invoking illegal instructions on specific platforms [74], leading agility (choosing between multiple algorithms for the same functionality) and multiplexing (choosing between multiple im- to killed processes and even crashing kernels. plementations of the same algorithm). Through abstraction and Since a cryptographic provider is the linchpin of most zero-cost generic programming, we show how agility can simplify security-sensitive applications, its correctness and security are verification without sacrificing performance, and we demonstrate crucial. However, for most applications (e.g., TLS, cryptocur- how C and assembly can be composed and verified against rencies, or disk encryption), the provider is also on the critical shared specifications. We substantiate the effectiveness of these techniques with new verified implementations (including hashes, path of the application’s performance. Historically, it has been Curve25519, and AES-GCM) whose performance matches or notoriously difficult to produce cryptographic code that is fast, exceeds the best unverified implementations. We validate the correct, and secure (e.g., free of leaks via side channels). For API design with two high-performance verified case studies built instance, OpenSSL’s libcrypto reported 24 vulnerabilities atop EverCrypt, resulting in line-rate performance for a secure between January 1, 2016 and May 1, 2019 (Figure 15). network protocol and a Merkle-tree library, used in a production blockchain, that supports 2.7 million insertions/sec. Altogether, Such critical, complex code is a natural candidate for formal EverCrypt consists of over 124K verified lines of specs, code, verification, which can mathematically guarantee correctness and proofs, and it produces over 29K lines of C and 14K lines and security even for complex low-level implementations. of assembly code. Indeed, in recent years, multiple research groups have produced exciting examples of verified cryptographic code. I. INTRODUCTION However, as we discuss in detail in xII, previous work has Application developers seldom write their own cryptographic not produced a verified cryptographic provider comparable to code; instead they rely on a cryptographic provider, such the unverified providers in use today. Instead, some papers as OpenSSL’s libcrypto [65], Windows Cryptography verify a single algorithm [14, 17, 80], or even just a portion API [58], or libsodium [7]. Developers expect their provider thereof [26, 67, 75]. Others focus on many variants of a to be comprehensive in supplying all of the functionalities they single functionality, with elliptic curves being a popular need (asymmetric and symmetric encryption, signing, hashing, choice [36, 81]. Finally, a few works include several classes of key derivation, . ) for all the platforms they support. functionality (e.g., hashing and encryption) but either in small Further, a modern cryptographic provider should be agile; number for specific platforms [25, 39], or with speeds below that is, it should provide multiple algorithms (e.g., ChaCha-Poly those of state-of-the-art providers [10, 44, 73, 82]. All of these and AES-GCM) for the same functionality (e.g., authenticated works contribute important techniques and insights into how to encryption) and all algorithms should employ a single unified best verify cryptographic code, but they all fall short of what API, to make it simple to change algorithms if one is broken. application developers want from a cryptographic provider. A modern cryptographic provider should also support multi- Building on previous algorithm verification efforts [25, plexing, that is, the ability to choose between multiple imple- 39, 82], we present EverCrypt, a comprehensive, provably mentations of the same algorithm. This allows the provider to correct and secure, cryptographic provider that supports agility, employ high-performance implementations on popular hardware multiplexing, and auto-configuration. EverCrypt’s agility means platforms (OpenSSL, for example, supports dozens), while that multiple algorithms provably provide the same API to still providing a fallback implementation that will work on clients, and its multiplexing demonstrates multiple disparate any platform. Ideally, these disparate implementations should implementations (almost all entirely new, including several be exposed to the developer via a single unified API, so platform-specific implementations that beat state-of-the-art that she need not change her code when a new optimized unverified libraries) verifying against the same cryptographic version is deployed, and so that the provider can automatically specification. The API is carefully designed to be usable by choose the optimal implementation, rather than force the both verified and unverified (e.g., C) clients. To support the developer to do so. Historically, this process has been error former, we show that multiple layers of abstraction, both in the implementation and (more surprisingly) in the specification of In summary, this paper makes the following contributions: cryptographic algorithms, naturally leads to agile code while 1) EverCrypt, a comprehensive, verified cryptographic also improving verification efficiency. We also demonstrate provider that offers agility, multiplexing, and speed; how the judicious use of generic programming can enhance 2) the design of a principled, abstract, agile API, usable by developer productivity and simplify specifications by cleanly verified (F?) and unverified (C) clients alike; extracting commonality from related algorithms. 3) its multiplexing implementation, coupled with verified To illustrate the benefits of multiplexing, and as part of our zero-cost generic programming techniques to streamline efforts to ensure state-of-the-art performance for EverCrypt, the verification of cryptographic algorithms without sacri- we present new verified implementations of a large variety of ficing performance; algorithms (Figure4). These include, e.g., Curve25519 [ 18], 4) a new approach based on dependently typed generic hash functions, and authenticated encryption with additional programming [12] to prove the safety and correctness data (AEAD) that transparently multiplex between a generic C of fine-grained interoperation between C and assembly; implementation and a hand-tuned x64 assembly implementation. 5) new verified cryptographic implementations (including When run on x64, they match or exceed the performance of the hashes, Curve25519, and AES-GCM) whose performance best unverified code, while the C implementations provide matches or exceeds the best unverified implementations; support across all other platforms (and offer performance 6) case studies on real applications of Merkle trees and QUIC competitive with unverified C code as well). transport security to demonstrate the utility of EverCrypt’s To illustrate the utility of EverCrypt’s API, we develop API and the performance it enables. two applications atop it. First, a new Merkle-tree [56] library The specifications, proofs, and code of EverCrypt are all leverages EverCrypt’s agile hashing API. The Merkle trees available as open source (xIX). support high-performance secure logging, providing over 2.7M transactions/s. They also come with comprehensive safety, II. BACKGROUND AND RELATED WORK correctness, and cryptographic security properties, illustrating Multiple research projects have contributed to our understand- EverCrypt’s value when building formally-verified applications. ing of how to produce verified cryptographic code, but none Second, we build a verified transport security layer for the QUIC provide the performance, comprehensiveness, and convenience network protocol [45] and, by connecting it to unverified QUIC that developers expect from a cryptographic provider, and none implementations, show that it supports line-rate performance. investigate the challenges of agility or automatic multiplexing. 1 All EverCrypt code is proven safe and functionally correct. Some work verifies parts of individual algorithms, particu- Safety means the code respects memory abstractions (e.g., never larly portions of Curve25519. For example, Chen et al. [26] reading outside the bounds of an array) and does not perform verify the correctness of a Montgomery ladder using Coq [72] illegal operations (e.g., divide by zero). Functional correctness and an SMT solver, while Tsai et al. [75] and Polyakov et means the code’s computational behavior is precisely described al. [67] do so using an SMT solver and a computer algebra by a pure mathematical function. Further, all EverCrypt code system. All three focus on implementations written in assembly- is proven side-channel resistant; specifically, the sequence of like languages. Almeida et al. [10], in contrast, use a domain- instructions executed and the memory addresses