Alchemy: A Language and Compiler for Homomorphic Encryption Made easY Eric Crockett Chris Peikert Chad Sharp University of Michigan and University of Michigan University of Michigan Georgia Institute of Technology ABSTRACT ACM Reference Format: Fully Homomorphic Encryption (FHE) is a cryptographic “holy Eric Crockett, Chris Peikert, and Chad Sharp. 2018. Alchemy: A Language and Compiler for, Homomorphic Encryption Made easY. In CCS ’18: 2018 grail” that allows a worker to perform arbitrary computations on ACM SIGSAC Conference on Computer & Communications Security Oct. 15– client-encrypted data, without learning anything about the data 19, 2018, Toronto, ON, Canada. ACM, New York, NY, USA, 18 pages. https: itself. Since the first plausible construction in 2009, a variety of //doi.org/10.1145/3243734.3243828 FHE implementations have been given and used for particular ap- plications of interest. Unfortunately, using FHE is currently very complicated, and a great deal of expertise is required to properly 1 INTRODUCTION implement nontrivial homomorphic computations. Fully Homomorphic Encryption (FHE) is a powerful cryptographic This work introduces Alchemy, a modular and extensible system concept that allows a worker to perform arbitrary computations on that simplifies and accelerates the use of FHE. Alchemy compiles client-encrypted data, without learning anything about the data it- “in-the-clear” computations on plaintexts, written in a modular self. Although first envisioned 40 years ago [49] as a cryptographic domain-specific language (DSL), into corresponding homomorphic “holy grail,” no plausible candidate FHE scheme was known until computations on ciphertexts—with no special knowledge of FHE Gentry’s seminal work in 2009 [26, 27]. Motivated by FHE’s po- required of the programmer. The compiler automatically chooses tential to enable new privacy-sensitive applications and enhance (most of the) parameters by statically inferring ciphertext noise existing ones, a flurry of research activity has led to FHE schemes rates, generates keys and “key-switching hints,” schedules appro- with better efficiency, stronger security assurances, and specialized priate ciphertext “maintenance” operations, and more. In addition, features. (See [3, 4, 11–15, 18–20, 30–32, 51, 52] for a sampling.) In its components can be combined modularly to provide other useful addition, there are a variety of real-world FHE implementations functionality, such logging the empirical noise rates of ciphertexts which have been used for particular applications of interest (see, throughout a computation, without requiring any changes to the e.g., [17, 22, 25, 29, 33, 38, 46]). original DSL code. Unfortunately, using current FHE implementations for non-trivial As a testbed application, we demonstrate fast homomorphic homomorphic computations is quite complicated: First, one must evaluation of a pseudorandom function (PRF) based on Ring-LWR, express the desired “in the clear” computation (on plaintexts) in whose entire implementation is only a few dozen lines of simple terms of the FHE scheme’s “instruction set,” i.e., the basic homo- DSL code. For a single (non-batched) evaluation, our unoptimized morphic operations it natively supports. This is non-trivial because implementation takes only about 10 seconds on a commodity PC, the operations (which can vary based on the scheme) are typically which is more than an order of magnitude faster than state-of- algebraic ones like addition and multiplication on finite fields, and the-art homomorphic evaluations of other PRFs, including some sometimes other functions like permutations on fixed-sized arrays specifically designed for amenability to homomorphic evaluation. of field elements. Thus, one needs to “arithmetize” the desired com- putation in terms of these operations, as efficiently as possible for CCS CONCEPTS the instruction set at hand. (Moreover, the instruction set can some- • Security and privacy → Public key encryption; • Software and times depend on the choice of plaintext and ciphertext rings, which its engineering → Software design techniques; can also affect the third step below.) Second, FHE ciphertexts accumulate “errors” or “noise” under KEYWORDS homomorphic operations, and too much noise causes the result to decrypt incorrectly—so proper noise management is essential. In fully homomorphic encryption; domain-specific languages; compil- addition, the ciphertext “degree” increases under certain operations, ers but can be brought back down using other means. So along with homomorphic operations that perform meaningful work on the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed plaintext, one must also carefully schedule appropriate “mainte- for profit or commercial advantage and that copies bear this notice and the full citation nance” operations, such as linearization and other forms of key on the first page. Copyrights for components of this work owned by others than the switching, and rescaling (also known as modulus switching) to keep author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission the ciphertext noise and size under control. and/or a fee. Request permissions from [email protected]. Third, one must choose appropriate ciphertext parameters for CCS ’18, October 15–19, 2018, Toronto, ON, Canada the desired level of security, i.e., dimensions and moduli that are © 2018 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-5693-0/18/10...$15.00 compatible with the noise rates at the various stages of the compu- https://doi.org/10.1145/3243734.3243828 tation (and also consistent with any restrictions inherited from the first step). Importantly, the choice of parameters itself affects the implementation of the “plaintext” PRF computation is only a few noise growth incurred by the homomorphic operations, so one may dozen lines of very simple and transparent code; Alchemy handles need several cycles of trial and error until the parameters stabilize. everything else. Lastly, one also needs to generate all the needed keys and aux- It has long been understood that homomorphic evaluation of iliary key-switching “hints” that are needed for the maintenance symmetric-key primitives like PRFs is a very useful tool in the the- operations, and to encrypt the input plaintexts under the appropri- ory and practice of FHE (see, e.g., [26, 28, 33]). For example, it allows ate keys. a client to encrypt its data using symmetric-key encryption—which In summary, the above process requires a great deal of expertise is much faster and more compact than FHE encryption—while still in both the theory of FHE and the quirks of its particular imple- allowing a worker to compute on the data homomorphically. The mentation, in addition to a lot of manual programming and trial- worker first homomorphically evaluates the symmetric decryption and-error. Perhaps for this reason, most applications of FHE to date circuit on an FHE encryption of the user’s secret key, resulting in have been ad-hoc, one-off implementations, with complex code that an FHE encryption of the user’s data. From there the worker can is hard to debug and which obscures the nature of the underlying homomorphically evaluate the actual function of interest. computation. Prior work has homomorphically evaluated PRFs like the AES block cipher [18, 24, 33, 45] and the “LowMC” cipher [1], which was 1.1 Contributions specially designed to have low multiplicative depth for amenability This work introduces Alchemy, a system that greatly simplifies and to FHE and multi-party computation (MPC). On standard laptop- accelerates the implementation of homomorphic computations.1 In class hardware, highly optimized state-of-the-art implementations short, Alchemy automatically and safely transforms “in-the-clear” require a few minutes (or much more) for a single AES or LowMC computations on plaintexts into corresponding homomorphic com- evaluation. They can also use SIMD techniques to compute scores putations on ciphertexts. Crucially, this requires no detailed knowl- of evaluations at once, resulting in amortized rates of a few seconds edge of particular FHE schemes on the part of the programmer. One per block, or even sub-second rates for LowMC amortized over simply writes (and runs, and debugs) a program that describes a hundreds of blocks. However, the latency remains in the several desired plaintext computation, and then obtains a matching homo- minutes, which makes its unsuitable for many scenarios. morphic computation with very little additional effort. By constrast, our homomorphic evaluation of a Ring-LWR PRF At a more technical level, Alchemy consists of two main pieces: takes only about twelve seconds for a single evaluation on com- 2 (1) domain-specific languages (DSLs) for expressing plaintext and modity hardware. This is primarily due to its use of rich natively ciphertext computations, including both “native” operations and a supported FHE operations like “ring switching” [22, 30] and SIMD library of higher-level functions built out of them; and (2) a compiler operations on “slots” [51], its small number of such operations, and that transforms plaintext programs into corresponding homomor- its low multiplicative depth (over a large ring). This good “algebraic phic ones. The