We present a new, completely redesigned, version of F ⋆ , a language that works both as a proof assistant as well as a general-purpose, verification-oriented, effectful programming language. In support of these complementary roles, F ⋆ is a dependently typed, higher-order, call-by-value language with primitive effects including state, exceptions, divergence and IO. Although primitive, programmers choose the granularity at which to specify effects by equipping each effect with a monadic, predicate transformer semantics. F ⋆ uses this to efficiently compute weakest preconditions and discharges the resulting proof obligations using a combination of SMT solving and manual proofs. Isolated from the effects, the core of F ⋆ is a language of pure functions used to write specifications and proof terms-its consistency is maintained by a semantic termination check based on a well-founded order. We evaluate our design on more than 55,000 lines of F ⋆ we have authored in the last year, focusing on three main case studies. Showcasing its use as a general-purpose programming language, F ⋆ is programmed (but not verified) in F ⋆ , and bootstraps in both OCaml and F#. Our experience confirms F ⋆ 's pay-as-you-go cost model: writing idiomatic ML-like code with no finer specifications imposes no user burden. As a verification-oriented language, our most significant evaluation of F ⋆ is in verifying several key modules in an implementation of the TLS-1.2 protocol standard. For the modules we considered, we are able to prove more properties, with fewer annotations using F ⋆ than in a prior verified implementation of TLS-1.2. Finally, as a proof assistant, we discuss our use of F ⋆ in mechanizing the metatheory of a range of lambda calculi, starting from the simply typed lambda calculus to System F ω and even µF ⋆ , a sizeable fragment of F ⋆ itself-these proofs make essential use of F ⋆ 's flexible combination of SMT automation and constructive proofs, enabling a tactic-free style of programming and proving at a relatively large scale. Categories and Subject Descriptors D.3.1 [Programming Languages]: Formal Definitions and Theory-Semantics; F.3.1 [Logics and Meanings of Programs]: Specifying and Verifying and Reasoning about Programs-Mechanical verification Keywords verification; proof assistants; effectful programming 1 Henceforth, we refer to the new language presented in this paper as "F ⋆ " while referring to the old, defunct version as "old-F ⋆ ".

HACL * is a verified portable C cryptographic library that implements modern cryptographic primitives such as the ChaCha20 and Salsa20 encryption algorithms, Poly1305 and HMAC message authentication, SHA-256 and SHA-512 hash functions, the Curve25519 elliptic curve, and Ed25519 signatures. HACL * is written in the F * programming language and then compiled to readable C code. The F * source code for each cryptographic primitive is verified for memory safety, mitigations against timing side-channels, and functional correctness with respect to a succinct high-level specification of the primitive derived from its published standard. The translation from F * to C preserves these properties and the generated C code can itself be compiled via the CompCert verified C compiler or mainstream compilers like GCC or CLANG. When compiled with GCC on 64-bit platforms, our primitives are as fast as the fastest pure C implementations in OpenSSL and Libsodium, significantly faster than the reference C code in TweetNaCl, and between 1.1x-5.7x slower than the fastest hand-optimized vectorized assembly code in SUPERCOP. HACL * implements the NaCl cryptographic API and can be used as a drop-in replacement for NaCl libraries like Libsodium and TweetNaCl. HACL * provides the cryptographic components for a new mandatory ciphersuite in TLS 1.3 and is being developed as the main cryptographic provider for the miTLS verified implementation. Primitives from HACL * are also being integrated within Mozilla's NSS cryptographic library. Our results show that writing fast, verified, and usable C cryptographic libraries is now practical. 1 THE NEED FOR VERIFIED CRYPTO Cryptographic libraries lie at the heart of the trusted computing base of the Internet, and consequently, they are held to a higher standard of correctness, robustness, and security than other distributed applications. Even minor bugs in cryptographic code typically result in CVEs and software updates. For instance, since 2016, OpenSSL has issued 11 CVEs 1 for bugs in its core cryptographic primitives, including 6 memory safety errors, 3 timing side-channel leaks, and 2 incorrect bignum computations. Such flaws may seem difficult to exploit at first, but as Brumley et al. [24] demonstrated, even an innocuous looking arithmetic bug hiding deep inside an elliptic 1

We present Low * , a language for low-level programming and verification, and its application to high-assurance optimized cryptographic libraries. Low * is a shallow embedding of a small, sequential, well-behaved subset of C in F * , a dependently-typed variant of ML aimed at program verification. Departing from ML, Low * does not involve any garbage collection or implicit heap allocation; instead, it has a structured memory model à la CompCert, and it provides the control required for writing efficient low-level security-critical code. By virtue of typing, any Low * program is memory safe. In addition, the programmer can make full use of the verification power of F * to write high-level specifications and verify the functional correctness of Low * code using a combination of SMT automation and sophisticated manual proofs. At extraction time, specifications and proofs are erased, and the remaining code enjoys a predictable translation to C. We prove that this translation preserves semantics and side-channel resistance. We provide a new compiler back-end from Low * to C and, to evaluate our approach, we implement and verify various cryptographic algorithms, constructions, and tools for a total of about 28,000 lines of code, specification and proof. We show that our Low * code delivers performance competitive with existing (unverified) C cryptographic libraries, suggesting our approach may be applicable to larger-scale low-level software.

No abstract

No abstract