STRONG PRIVACY FOR COMMUNICATION, BROWSING, AND …

STRONG PRIVACY FOR COMMUNICATION, BROWSING, AND STORAGE

A DISSERTATION

SUBMITTED TO THE DEPARTMENT OF COMPUTER SCIENCE

AND THE COMMITTEE ON GRADUATE STUDIES

OF STANFORD UNIVERSITY

IN PARTIAL FULFILLMENT OF THE REQUIREMENTS

FOR THE DEGREE OF

DOCTOR OF PHILOSOPHY

Saba Eskandarian

May 2021

http://creativecommons.org/licenses/by-nc/3.0/us/

This dissertation is online at: http://purl.stanford.edu/yn775mg8974

© 2021 by Saba Eskandarian. All Rights Reserved.

Re-distributed by Stanford University under license with the author.

This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 United States License.

ii



http://purl.stanford.edu/yn775mg8974

I certify that I have read this dissertation and that, in my opinion, it is fully adequatein scope and quality as a dissertation for the degree of Doctor of Philosophy.

Dan Boneh, Primary Adviser


Zakir Durumeric


Matei Zaharia

Approved for the Stanford University Committee on Graduate Studies.

Stacey F. Bent, Vice Provost for Graduate Education

This signature page was generated electronically upon submission of this dissertation in electronic format. An original signed hard copy of the signature page is on file inUniversity Archives.

iii

Abstract

As news of large-scale privacy compromises becomes increasingly frequent, there is a need for new tools to

protect user privacy across all the technologies we use in our daily lives. This thesis develops new approaches

to protecting user data as it is typed into a web browser, when it is transmitted in messaging conversations,

and when it resides in cloud storage. The techniques used will vary from new system designs using hardware

enclaves to novel applications of zero-knowledge proof systems, but for each application the thesis will show

how to achieve order of magnitude performance improvements that enable previously out of reach use cases.

iv

Acknowledgments

First and foremost, I would like to thank my advisor Dan Boneh for everything he has done for me these last

five years. I started the PhD with a general sense of excitement around cryptography and security but little

direction beyond that. Dan patiently helped me get started on various projects until I was eventually able

to develop some sense of what kinds of problems I like to work on myself. The way he balances providing

support and encouraging independence is really fantastic, and I hope I will be able to emulate this myself in

the future. At every step of the PhD he has provided technical, emotional, and financial support, and it has

made for an extremely enjoyable time.

In addition to Dan, I have been fortunate to benefit from interactions with a number of other faculty mem-

bers. I did a rotation my first year with Omer Reingold and later had the opportunity to TA his introduction to

theory class. Omer was always available to chat about problems, technical or not, and he helped me a great

deal in building confidence with myself and dealing with the stress that comes with grad school.

I also spent a rotation working with Matei Zaharia, which led to us collaborating on multiple projects

during the PhD. Matei introduced me to building systems for research, and the time I spent working with him

my first year significantly affected the flavor of problems I have worked on since.

Zakir Durumeric kindly allowed me to TA his Topics in Security class, where I learned a great deal,

broadened my view of what counts as security research, and made fantastic friends along the way. My social

interactions with Zakir’s group during the last year have been instrumental in keeping me sane during the

pandemic.

Keith Winstein’s willingness to talk whenever someone wanted to and his expressions of support and

caring for me and others during the pandemic have also been very encouraging in an otherwise fairly grim

year. I will sorely miss his entertaining and unexpected stories, as well as his willingness to offer his unique

perspective on so many topics.

My conversations with David Mazieres over lunch have changed how I think about my relationship with

software, and his excellent questions and comments on my talks have significantly improved my presentation

skills.

I would like to thank John Boothroyd for hosting two years of a program called 12@12, where students

in different departments across campus came together for weekly lunches and gave informal talks about

their research meant to be accessible to general audiences. I really enjoyed that program as well as John’s

v

Preparing for Faculty Careers class which I took last spring.

Ruth Harris and Megan Harris have made every administrative aspect of the PhD painless and efficient,

and have also been so much fun to work with. I fondly remember several adventures involving working with

Megan to placate the 4B coffee machine, and the vacuum cleaner Ruth bought us for cleaning up after the

security/theory lunches first year has probably saved many days of cumulative student-hours by now.

The Applied Crypto group has been my academic family at Stanford, and I have learned (and laughed!)

more with them in the last five years than I thought was possible in such a short time. I would especially

like to thank Dima Kogan and Florian Tramer for eating lunch with me almost every day for 4 years before

the pandemic forced our lives online. Henry Corrigan-Gibbs may well have saved me from giving up by

regularly inviting me on bike rides followed by frozen yogurt. The broader security and theory groups at

Stanford have been a great source of both friendship and technical help.

I was fortunate to have the opportunity to teach CS355, our advanced cryptography class, with an amazing

group of co-instructors and TAs: Dima Kogan, Florian Tramer, Alex Ozdemir, Riad Wahby, and Katy Woo.

I learned a lot about cryptography and teaching cryptography and am grateful to them and all the CS355

students for making the class such an enjoyable experience.

My officemates in Gates 494 – Bruce Spang, Margalit Glasgow, Sam Kim, and Yan Michalevsky – have

been wonderful, both as friends and collaborators. I always looked forward to our conversations in the office.

Sam taught me so much, both about cryptography and how to approach research in general, during our long

conversations before morning meetings.

I would also like to thank all my co-authors: Dan Boneh, Henry Corrigan-Gibbs, Matei Zaharia, Sam

Kim, Maurice Shih, Charlotte Peale, Lucjan Hanzlik, Mihai Christodorescu, Payman Mohassel, Giancarlo

Pellegrino, Ben Fisch, Joseph Bonneau, Eran Messeri, Jonathan Cogan, Sawyer Birnbaum, Peh Chang Wei

Brandon, Dillon Franke, Forest Fraser, Gaspar Garcia, Eric Gong, Hung Nguyen, Taresh Sethi, and Vishal

Subbiah.

I spent a very fun and eventful summer at Visa Research with Mihai Christodorescu and Payman Mo-

hassel, who kindly allowed me to change my whole internship project partway through on a whim based

on a lunch conversation. Their excellent mentoring and the great cohort of fellow interns made for a very

memorable summer.

My first experiences with research were under the guidance of Mohammad Mahmoody and abhi shelat

at UVA. They were far more patient with me than I deserved, and they had far more confidence in me than I

had in myself. Thank you both so much.

Finally, I would like to thank my friends and family. I have made several lifelong friends during the PhD

both at Stanford and in the surrounding area. I was also fortunate to have the company of Kyle Bibler and

Kerry Lapallo, who moved to the Bay area at the same time as me after we finished college together, kept in

touch throughout the PhD, and shared many adventures with me.

The Bay area Baha’i community has been a second family to me these past five years, welcoming me

with open arms upon my arrival and always being there for me since.

vi

My family has been extremely supportive throughout the PhD, and of course for the preceding 22 years

as well. Their encouragement and the attitude toward life and work that they raised me with is responsible

for everything I have been able to do since. It is worth mentioning that my mom and I started PhD programs

at the same time, and it is no surprise that she ended up finishing a full year before me.

vii

Contents

Abstract iv

Acknowledgments v

1 Introduction 11.1 Overview of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Protecting User Inputs to the Browser . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.2 Secure Messaging for Whistleblowers . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.3 Key Rotation in the Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Works Contained in this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Fidelius: Protecting User Secrets from Compromised Browsers 72.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 Trusted User I/O Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.2 Web Enclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.2 Developer Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Trusted Path for User I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6.2 Trusted Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6.3 Message structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7 Web Enclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7.1 Web Enclave State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

viii

2.8 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.8.1 Attacks on Core Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.8.2 Attacks on Trusted I/O Path and UI . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.9 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.9.1 Trusted Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.9.2 Browser and Web Enclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.10 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.11 Discussion and Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.12 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Express: Lowering the Cost of Metadata-Hiding Communication 353.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.1 Express API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.2 Security Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.3 Design Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3 Express Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3.1 Review: Private Writing with DPFs . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.2 Hiding Metadata without Synchronized Rounds . . . . . . . . . . . . . . . . . . . . 44

3.4 Protecting Against Malicious Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.4.1 Auditing to Prevent Disruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.4.2 Preventing Targeted Disruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.5 Full Express Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.6 Using Express for Whistleblowing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.6.1 Plausible Deniability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.6.2 Dialing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.7 Implementation and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.7.1 Communication Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.7.2 Client Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.7.3 Server Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.8 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.10 Additional Details of Security Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.11 Additional Details on SNIPs and Analysis of Auditing Protocol . . . . . . . . . . . . . . . . 63

ix

4 Improving Speed and Security in Updatable Encryption Schemes 664.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.1.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.2.1 Basic Cryptographic Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.2.2 Pseudorandom Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.2.3 Authenticated Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.3 New Definitions for Updatable Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.3.1 Updatable Encryption Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.3.2 Prior Notions of Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.3.3 Improving Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.3.4 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.4 UAE with Bounded Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.4.1 A Simple Nested Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.4.2 Bounded Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.4.3 Nested Construction with Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.5 UAE from Key-Homomorphic PRFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.5.1 Encoding Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.5.2 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.5.3 Security Under Relaxed Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.5.4 Consequences of Relaxed Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.6 Almost Key-Homomorphic PRFs from Lattices . . . . . . . . . . . . . . . . . . . . . . . . 94

4.6.1 Ring Learning with Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

4.6.2 Almost Key-Homomorphic PRFs from RLWE . . . . . . . . . . . . . . . . . . . . 95

4.6.3 Implementation Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.7 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.8 Conclusion and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.9 Everspaugh et al. [66] Security Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.10 Comparison to the Ciphertext-Independent Setting . . . . . . . . . . . . . . . . . . . . . . 104

4.11 Full Construction of Simple Nested Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.12 Full Definition of Relaxed Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.13 Proof of theorem 4.4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.13.1 Proof of Strong Compactness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.13.2 Proof of Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

4.13.3 Proofs of Update Independence, Message Confidentiality, and Re-encryption Indis-

tinguishability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4.13.4 Proof of Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

x

4.14 Proof of theorem 4.5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

4.14.1 Proof of Strong Compactness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

4.14.2 Proof of Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

4.14.3 Proof of Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

4.14.4 Proof of Relaxed Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

4.15 Proof of theorem 4.6.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

4.15.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

4.15.2 Key-Homomorphism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

5 Conclusion 147

Bibliography 148

xi

List of Tables

3.1 Complexity of processing a single write in Express with n mailboxes, message size |m|, and security

parameter λ. Communication measures bits sent only. . . . . . . . . . . . . . . . . . . . . . . . 52

xii

List of Figures

2.1 Overview of Fidelius. The web enclave, embedded in a malicious browser and OS, communicates with

the user through our trusted I/O path and securely sends data to a remote origin. We assume that both

the web browser and the OS are compromised. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Design of Fidelius’s user interface. The green area is the trusted display overlay. . . . . . . . . . . . 14

2.3 State machine representing web enclave behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 Images of our Fidelius prototype in use. The image above shows the view of a user, and the image below

shows the view of an attacker taking a screen capture while the user enters credit card information. Since

trusted overlays are decrypted and placed over the image after leaving the compromised computer, the

attacker does not see the user’s data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.5 Prototype of the trusted path: (a) standard USB keyboard connected to our RPI Zero dongle to encrypt

keystrokes, (b) Computer with a Fidelius-enabled browser, and (c) standard HDMI display connected

to our RPI 3 dongle to overlay secure frames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6 Trusted keyboard dongle built from Raspberry Pi Zero. In untrusted mode, the dongle forwards key

presses from the keyboard to the computer. In trusted mode, the dongle sends a constant stream of

encrypted values to the enclave. The values correspond to key presses if there has been any input or

null values otherwise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.7 Trusted display dongle built from Raspberry Pi 3. Frames arrive on the RPI3 over HDMI in, which con-

nects through a board that treats the frames to be displayed as camera inputs. Overlays are transmitted

over Bluetooth and decrypted on the RPI3. The combined frame and overlay go to the display through

the HDMI out cable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.8 Fidelius key press to display latency compared with the screen response time on various commercial

devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.9 Impact on page load time as the number of trusted components varies. Adding components does not

significantly affect load time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.10 Breakdown of display costs by component. Render/refresh delays are an artifact of our hardware and

could be dramatically reduced. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.11 Key press to display latency when rendering forms. Widths are fractions of the most popular screen

width (w = 1366px): S= 18w, M= 1

4w, L= 1

2w, XL= 2

3w. Increments calculated from the previous row. . 31

xiii

3.1 Contents of the tables held by servers in Express. Each server stores the conversion from virtual to

physical addresses and a distinct key for each mailbox. Combining data from the two servers allows a

user holding both keys for a given mailbox to read its contents. . . . . . . . . . . . . . . . . . . . 50

3.2 Server communication costs when sending 160 Byte messages, including both data sent and

received. Riposte also requires an auditing server whose costs are not depicted. . . . . . . . 54

3.3 Client communication costs when sending 160 Byte messages, including both data sent and

received. Express requires significantly less communication than prior work. . . . . . . . . 54

3.4 Our auditing protocol dramatically reduces computation costs for the client while server-side

costs remain comparable to prior work, where audit computation time is dwarfed by DPF

evaluation anyway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.5 Message delivery latency in Express and Pung for various message sizes. Express outper-

forms Pung by 1.3− 2.6× for 1KB messages and by 2.0− 2.9× for 10KB messages. Pung’s

performance for 10KB messages is comparable to Express’s performance for 32KB messages. 57

3.6 Express’s throughput is 1.4-6.3× that of Riposte for 1KB messages. Even with 32KB mes-

sages, Express’s throughput is still comparable to Riposte on 1KB messages. For large num-

bers of mailboxes, both systems are computation-bound by the number of DPF evaluations

required to process writes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.7 Dollar costs to run end-to-end metadata hiding systems with cryptographic security guaran-

tees. Prices are based on Google Cloud Platform public pricing information for compute

instances and data egress. Processing one million messages in Express in the presence of

100,000 registered mailboxes costs 5.9× less than the next cheapest system. . . . . . . . . 57

4.1 Security experiment for confidentiality (theorem 4.3.4) and update independence (theorem 4.3.6) 78

4.2 Security experiment for integrity (theorem 4.3.7) . . . . . . . . . . . . . . . . . . . . . . . 84

4.3 Our nested scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.4 Our UAE from almost Key-Homomorphic PRFs. . . . . . . . . . . . . . . . . . . . . . . . 90

4.5 RLWE parameters for each value of |q| (length of q in bits) used in our evaluation. . . . . . . . . . . 97

4.6 Comparing the throughput of our KH-PRF, ReCrypt, and our nested construction configured to allow

128 re-encryptions, for messages of length 4KB, 32KB, and 100KB. Higher numbers are better. Our

KH-PRF is evaluated with four choices of q. The AVX column refers to an implementation that takes

advantage of Intel’s AVX vector instructions. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4.7 KeyGen and ReKeyGen costs. The main differences in performance are caused by whether the ReKeyGen

algorithm needs to sample only AES keys or also KH-PRF keys, the type of KH-PRF used, and the

number of ciphertexts contained in the update token. . . . . . . . . . . . . . . . . . . . . . . . . 98

4.8 KH-PRF based UAE (|q| = 60) and nested UAE (t = 128) decryption times. The KH-PRF construction

decrypts faster than nested AES when there are more than 50 re-encryptions. ReCrypt is not depicted

as it takes 500× longer than our KH-PRF based UAE to decrypt. . . . . . . . . . . . . . . . . . . 99

xiv

4.9 Ciphertext body expansion for the KH-PRF based UAE, Nested UAE, and ReCrypt. Our constructions

generally have larger ciphertext expansion than ReCrypt, although the Nested UAE matches ReCrypt

for some settings, e.g., annually re-keying data for 20 years. . . . . . . . . . . . . . . . . . . . . 99

4.10 Simplified confidentiality definition of Everspaugh et al. [66] (theorem 4.9.1) . . . . . . . . 102

4.11 Simplified re-encryption indistinguishability definition of Everspaugh et al. [66] theorem 4.9.2103

4.12 Ciphertext integrity definition of Everspaugh et al. [66] (theorem 4.9.3) . . . . . . . . . . . 104

4.13 Our simple nested scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.14 Security experiment for relaxed integrity (theorem 4.12.1) . . . . . . . . . . . . . . . . . . 108

xv

Chapter 1

Introduction

We live in an exciting time in the history of computing. Networked devices are everywhere, and computers are

woven into the fabric of daily lives in ways unimaginable even a couple decades ago. At the same time, new

advances in the functionality offered by computing devices have been built without security considerations in

mind. As a result, there are many, many ways in which our private data can be compromised in today’s digital

world. There are many reasons why this happens, including poor security on endpoint devices, a willingness

to upload and store data on third party cloud storage services which may be inadequately secured, and an

evolving but imperfect internet infrastructure. Perhaps most disappointing are the cases where private data

is compromised not because of any security failure but because the very applications users intend to use are

designed to leak private data, either because this leakage is inherent in the application or because it is built

into the design for business purposes.

The goal of this thesis is to help provide our devices and applications with the degree of security necessary

to protect privacy in an era of ubiquitous computing. To this end, we use a diverse array of tools – ranging

from hardware enclaves to new cryptographic techniques – to enhance users’ security and privacy across

the spectrum from endpoint devices to cloud storage and the applications in between. We hope the ideas

presented here form a stepping stone in the critical project of improving security in our daily lives.

Along the way, we hope to demonstrate that there are many settings where strong security guarantees may

initially seem out of reach if performance and functionality goals are to be met, but that the choice between

the two is in fact not nearly as stark as it may appear. Rather, if we approach problems from a security-first

perspective and tailor our solutions to take advantage of the particular contour of each problem we attempt

to solve, it is often possible to achieve strong security and privacy guarantees while still achieving acceptable

performance and functionality.

1

CHAPTER 1. INTRODUCTION 2

1.1 Overview of Results

This thesis consists of three works, each considering a different security or privacy problem, and each using

different tools to solve the respective problem. We begin by considering the security of users’ devices against

malware and considering the question of how to protect the secrets users type into their computers when those

computers may well be compromised by powerful malware. Next, we look at secure messaging and show

how to build a metadata-hiding messaging system specifically designed to protect whistleblowers who wish

to contact journalists. Finally, we discuss the security of data that is encrypted and sent to a third-party cloud

storage provider. Specifically, we will consider the problem of how to change the key under which data is

encrypted without revealing the keys or data to the cloud provider, but also without incurring high client-side

computation or communication costs.

We now summarize the main challenges addressed by each aspect of this thesis and briefly describe the

core contributions of our solutions.

1.1.1 Protecting User Inputs to the Browser

Given the amount of sensitive information users type into their computers, and into their web browsers in

particular, it is important to have confidence that this information is not accessible to malicious parties who

may have gained a foothold on a computer via malware. Since malware could potentially take the form of a

root exploit that enables complete access to the computer’s I/O operations, we need to look beyond potentially

vulnerable software in the operating system in order to gain security in this setting. As such, this work makes

use of hardware enclaves, which provide a security guarantee at the level of hardware, even if the entire OS

and software stack above the hardware are compromised.

A hardware enclave allows a program to run in a region of memory that is isolated from the OS, where

the memory is inaccessible to any other program and the code and data residing in that region of memory

are encrypted when not in active use. Moreover, enclaves allow for a process called attestation, where a

computer that hosts an enclave can prove to a remote server that it is in fact running an authentic enclave.

While the presence of an enclave gives hope that we may be able to get some security from the hardware,

even in the face of a fully compromised software stack, a number of problems must be solved before the

security of an enclave can protect the secrets users type into their computers. Most importantly, enclaves

provide protection for code and data stored in memory, but in order for user secrets to reach an enclave, they

must first be typed by a user and then shown on a display. Both of these I/O operations require the assistance

of the operating sytem, as enclaves cannot make system calls on their own without OS assistance.

A second problem that must be overcome is answering the question of how to integrate enclaves into

end-user applications. Pushing the entire contents of a large application like a web browser into an enclave

would require a major engineering effort, and even then, moving a large trusted code base – that itself may be

full of vulnerabilities – into an enclave does not necessarily improve security for users, it just moves where

the code that malware will exploit can run. Thus care needs to be taken to minimize and isolate the segments


of a large application that need to be run in enclave to provide security.

To address these challenges, we develop the Fidelius system, which provides a trusted path from users to

an enclave and from an enclave to a display, as well as a mechanism for integrating with a web browser to

facilitate date entry and sending data to a remote server. Fidelius is covered in detail in Chapter 2.

Our trusted path solution involves using dongles, which we prototype using Raspberry Pis, that are at-

tached to off-the-shelf keyboards and displays. These dongles enable devices to switch between “untrusted”

and “trusted” modes. In the untrusted mode, both dongles simply act as pass-through devices, not changing

the usual behavior of the keyboard or display in any way. In the trusted mode, the keyboard dongle sends a

constant encrypted and authenticated stream of keystrokes to the enclave, sending empty encrypted packets if

a user is not typing to prevent leaking side-channel information about typing patterns. On the display side, the

dongle takes a more targeted approach to minimize the computational power required of the dongle. Instead

of having the enclave render and encrypt all the content on the screen and send it to the dongle for decryp-

tion, the enclave only handles rendering and encrypting the secret information that needs to appear on the

screen, e.g., a social security number, and the OS handles the rest, e.g., the browser window and non-sensitive

components of a web page. The dongle receives the standard output from the OS and the encrypted output

from the enclave and overlays the sensitive content on top of the non-sensitive content, displaying the final

composite output to the user. Both dongles have indicator lights that inform the user whether or not they are

in the trusted mode.

Our trusted path approach is a generic one which is compatible with any sort of application a user may

want to use. We demonstrate its efficacy in practice by additionally building an enclave that connects to a web

browser via a web extension and enables enhanced security for user secrets in the browsing context. To do

this, we introduce the abstraction of a web enclave, which allows enclave functionality to be integrated into

sensitive components of web pages and gives web developers easy access to the enclave. A demonstration of

the Fidelius system in action is available at https://crypto.stanford.edu/fidelius/.

1.1.2 Secure Messaging for Whistleblowers

Next we turn our attention to the problem of protecting messaging metadata. In particular, we will focus our

attention on how whistleblowers can safely communicate with journalists without revealing their identities to

the messaging infrastructure or any other adversaries lurking on the network. This is particularly important

because the identity of the whistleblower is often just as important as the content of the messages sent by

the whistleblower, and often the identity of the whistleblower must remain private long after a journalist

publishes the content of a whistleblower’s messages.

While the privacy of message contents have significantly improved in recent years with the increasing

availability of end-to-end encrypted messaging apps, protection of metadata remains an important problem

to solve. In chapter 3, we present the Express system, which makes significant progress in making metadata-

hiding communication for the whistleblowing use case more feasible.

https://crypto.stanford.edu/fidelius/


Express adopts a mailbox model for communicating messages, where journalists register a separate mail-

box for each whistleblower from which they will receive messages. The system relies on splitting trust

between two servers who provide the Express service, with the assumption that the two servers will not col-

lude to deanonymize users, even though one or the other of the servers is allowed to deviate arbitrarily from

the established protocol in its effort to compromise user privacy.

The core technique used by Express to allow whistleblowers to privately write into their assigned mail-

boxes uses distributed point functions (DPFs) [34, 74]. This technique has been used in prior messaging

works, most notably Riposte [50], but we make a number of additional contributions that transform this

generic approach to private writing into a practical system for whistleblowing.

First, we need a way to ensure that users of the Express system can only access mailboxes which they

own or are designated for them to write messages to. We handle read access, which does not have any

privacy requirement as the identities of journalists are not secret, with a mechanism for cryptographic access

control. Messages stored in each mailbox are encrypted under a key provided by a journalist for that particular

mailbox, with a different mailbox key used on each of the two servers. The encryption is done in counter

mode to allow new messages to be XORed into a mailbox without requiring servers to decrypt/re-encrypt

messages, and the servers re-randomize the contents of ciphertexts in a mailbox between attempts to read

them, preventing any two-time pad attacks on updated ciphertexts masked with the same counter and hiding

which mailboxes have actually had their contents modified.

Protecting against malicious users who want to write into others’ mailboxes is a more difficult challenge to

overcome because the Express servers are not allowed to know which mailbox each message is being written

to. This problem is even more urgent because the private writing mechanism updates mailbox contents by

XORing messages into the previous contents of a mailbox. Thus a malicious user who write a random

message into a given mailbox can completely corrupt the contents of that mailbox. Repeating this for all

registered mailboxes would render the Express system unusable.

Our approach to this problem is twofold. We protect against a malicious user who would write to others’

mailboxes by associating each mailbox with a 128-bit virtual address, effectively making the address space

of mailboxes so large that a malicious user who does not the mailbox address assigned to another user has

a negligible probability of overwriting the contents of someone else’s mailbox. The servers maintain a page

table that translates virtual addresses to physical addresses, allowing them to still do work proportional to the

number of registered addresses to update mailbox contents, even though a malicious user would now have to

do a computationally infeasible amount of work to overwrite all mailbox contents from the outside.

Unfortunately, even with our virtual address defense, it is possible for a malicious client to launch an

in-protocol denial of service attack against Express. This is because a client who sends a malformed DPF to

the system can corrupt all the mailboxes in the system at once without needing to separately find and write

a random message to each one. We prevent this attack by introducing a new DPF auditing protocol which

allows the servers to check that the message they are processing is well-formed without learning anything

about the message’s contents or its destination. Our auditing protocol improves upon the security, practicality,


and both asymptotic and real-world performance of a prior auditing protocol used in the Riposte system [50].

Ultimately, the combination of techniques used in Express reduces communication costs by one to three

orders of magnitude and reduces client computation costs by an order of magnitude while achieving equal or

better server-side performance and reducing the dollar cost to run the private communication system.

1.1.3 Key Rotation in the Cloud

The final problem addressed in this thesis is that of key rotation. Key rotation is the process of changing the

key under which a ciphertext is encrypted and is a common practice for data encrypted and stored with a

third-party cloud storage provider. There does exist a simple, naıve approach to secure key rotation. A user

who has outsourced storage of encrypted data to the cloud need only download all the data again, decrypt

it using the old key, and re-encrypt it using the new key before uploading the new ciphertext. While this is

undoubtedly a secure way to rotate keys, it is by no means efficient. The user’s local computer will incur data

transfer and computation costs linear in the size of the data being rekeyed, which often defeats the purpose

of outsourcing data to the cloud in the first place. As a result, deployed solutions today take a more ad-hoc

approach to key rotation that provides weaker security guarantees.

One promising approach to improving security for key rotation without incurring high costs for the client

is to use an updatable encryption scheme. Updatable encryption, first introduced by Boneh et al. [28], allows

a client device who holds the old and new keys to send a small update token to the cloud storage server.

This update token enable the server to change the key under which data is encrypted, without learning either

the keys or the plaintext data. Unfortunately, prior work on updatable encryption, while proving fantastic

performance benefits on the client side, has historically incurred costs so much higher on the server that it

could not feasibly be used in practice.

In chapter 4, we make new strides in the theory and practice of updatable encryption, improving re-

encryption throughput on the server by orders of magnitude to the point where throughput on the server can

in some cases almost match the throughput of a standard, non-updatable encryption scheme. This brings

updatable encryption closer to practical use. We are able to achieve the latter result by taking advantage of

the fact that often key rotation is being done for standards compliance reasons and users know in advance how

many times encrypted data will be rekeyed in its lifetime. For example, data retention standards may require

some data to be kept for ten years with the key being rotated once a year, meaning there will be at most ten

key rotations over the lifetime of a ciphertext. To address this common special case, we have a scheme based

on nesting AES encryptions which can take advantage of the same hardware acceleration features used by

standard AES encryption. For the general case where the number of key rotations is not known in advance, we

present a new scheme based on lattice cryptography which gains two orders of magnitude in performance over

prior work, although it comes with a slightly weaker integrity guarantee that prior updatable authenticated

encryption schemes.

Another contribution of this chapter is a series of stronger definitions for updatable authenticated encryp-

tion schemes (in the ciphertext-independent) setting. Most importantly, we identify and remove what we see


as a gap in prior definitions. Prior work, borrowing from existing definitional frameworks for encryption,

defined security for freshly encrypted ciphertexts and re-encrypted ciphertexts separately. As a result of the

structure of these definitions, schemes that hid the content of a ciphertext but leaked metadata about the ci-

phertexts age – captured by proxy via the number of times the ciphertext’s key has been rotated – would be

considered secure. Our new definitions provide the same protections for encrypted data while additionally

hiding this potentially sensitive metadata.

1.2 Works Contained in this Thesis

The results in this thesis are based on material that originally appeared in the following jointly authored

publications.

• Chapter 2: Fidelius: Protecting User Secrets from Compromised Browsers, with Jonathan Cogan,

Sawyer Birnbaum, Peh Chang Wei Brandon, Dillon Franke, Forest Fraser, Gaspar Garcia, Eric Gong,

Hung Nguyen, Taresh Sethi, Vishal Subbiah, Michael Backes, Giancarlo Pellegrino, and Dan Boneh,

published in IEEE S&P (Oakland) 2019 [64].

• Chapter 3: Express: Lowering the Cost of Metadata-Hiding Communication with Cryptographic Pri-

vacy, with Henry Corrigan-Gibbs, Matei Zaharia, and Dan Boneh, published in USENIX Security

2021 [65].

• Chapter 4: Improving Speed and Security in Updatable Encryption Schemes with Dan Boneh, Sam

Kim, and Maurice Shih in Asiacrypt 2020 [27].

Chapter 2

Fidelius: Protecting User Secrets fromCompromised Browsers

This chapter deals with protecting the secrets that users type into their computers, and especially their web

browsers, from the prying eyes of malware. Users regularly enter sensitive data, such as passwords, credit

card numbers, or tax information, into the browser window. While modern browsers provide powerful client-

side privacy measures to protect this data, none of these defenses prevent a browser compromised by malware

from stealing it. This chapter presents Fidelius, a new architecture that uses trusted hardware enclaves inte-

grated into the browser to enable protection of user secrets during web browsing sessions, even if the entire

underlying browser and OS are fully controlled by a malicious attacker.

Fidelius solves many challenges involved in providing protection for browsers in a fully malicious envi-

ronment, offering support for integrity and privacy for form data, JavaScript execution, XMLHttpRequests,

and protected web storage, while minimizing the trusted code base. Moreover, interactions between the

enclave and the browser, the keyboard, and the display all require new protocols, each with their own secu-

rity considerations. Finally, Fidelius takes into account UI considerations to ensure a consistent and simple

interface for both developers and users.

As part of building Fidelius, we develop the first open source system that provides a trusted path from

input and output peripherals to a hardware enclave with no reliance on additional hypervisor security assump-

tions. These components may be of independent interest and useful to future projects.

We implement and evaluate Fidelius to measure its performance overhead, finding that Fidelius imposes

acceptable overhead on page load and user interaction for secured pages and has no impact on pages and page

components that do not use its enhanced security features.

7

CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 8

2.1 Introduction

The web has long been plagued by malware that infects end-user machines with the explicit goal of stealing

sensitive data that users enter into their browser window. Some recent examples include TrickBot and Vega

Stealer, which are man-in-the-browser malware designed to steal banking credentials and credit card numbers.

Generally speaking, once malware infects the user’s machine, it can effectively steal all user data entered into

the browser. Modern browsers have responded with a variety of defenses aimed at ensuring browser integrity.

However, once the machine is compromised, there is little that the browser can do to protect user data from a

key logger.

In this chapter we present a practical architecture, called Fidelius, that helps web sites ensure that user

data entered into the browser cannot be stolen by end-user malware, no matter how deeply the malware is

embedded into the system. When using Fidelius, users can safely enter data into the browser without fear of

it being stolen by malware, provided that the hardware enclave we use satisfies the security requirements.

Hardware enclaves, such as Intel’s SGX, have recently been used to provide security for a variety of

applications, even in case of compromise [15,20,25,39,69,85,120,124,129,132,134,141,150,151,166]. An

enclave provides an execution environment that is isolated from the rest of the system (more on this below).

Moreover, the enclave can attest its code to a remote web site.

One could imagine running an entire browser in an enclave to isolate it from OS-level malware, but this

would be a poor design – any browser vulnerability would lead to malware inside the enclave, which would

completely compromise the design.

2.1.1 Our Contributions

Fidelius contains three components, discussed in detail in the following sections: (1) a small trusted func-

tionality running inside an isolated hardware enclave, (2) a trusted path to I/O devices like the keyboard and

the display, and (3) a small browser component that interacts with the hardware enclave.

A trusted path from the hardware enclave to I/O devices is essential for a system like Fidelius. First, this is

needed to prevent an OS-level malware from intercepting the data on its way to and from the I/O device. More

importantly, the system must prevent out-of-enclave malware from displaying UI elements that fool the user

into entering sensitive data where the malware can read it. Beyond protecting web input fields, the system

must protect the entire web form to ensure that the malware does not, for example, swap the “username” and

“password” labels and cause the user to enter her password into the username field.

We implement a prototype trusted path to the keyboard using a Raspberry Pi Zero that sits between the

user’s machine and the keyboard and implements a secure channel between the keyboard and the hardware

enclave. We implement a trusted path to the display using a Raspberry Pi 3 that sits between the graphics card

and the display. The Raspberry Pi 3 overlays a trusted image from the hardware enclave on top of the standard

HDMI video sent to the display from the graphics card. We discuss details in Section 2.9.1. Our trusted path

system is open source and available for other projects to use. We note that we can not use SGXIO [159],


an SGX trusted I/O project, because that system uses hypervisors, which may be compromised in our threat

model.

Another complication is the need to run client-side JavaScript on sensitive form fields. For example, a

web site may use client-side JavaScript to ensure that a credit card checksum is valid, and alert the user if

not. Similarly, many sites use client-side JavaScript to display a password strength meter. Fidelius should

not prevent these scripts from performing as intended. Several projects have already explored running a

JavaScript interpreter in a hardware enclave. Examples include TrustJS [77] and Secureworker [121]. Our

work uses the ability to run JavaScript in an enclave as a building block to enable privacy for user inputs in

web applications. The challenge is to do so while keeping the trusted enclave – the TCB – small.

To address all these challenges, this chapter makes the following contributions:

• The design of Fidelius, a system for protecting user secrets entered into a browser in a fully-compromised

environment.

• A simple interface for web developers to enable Fidelius’s security features.

• The first open design and implementation of a trusted path enabling a hardware enclave to interact with

I/O devices such as a display and a keyboard from a fully compromised machine.

• A browser component that enables a hardware enclave to interact with protected DOM elements while

keeping the enclave component small.

• An open-source implementation and evaluation of Fidelius for practical use cases.

2.2 Background

A hardware enclave provides developers with the abstraction of a secure portion of the processor that can

verifiably run a trusted code base (TCB) and protect its limited memory from a malicious or compromised

OS [1, 54]. The hardware handles the process of entering and exiting an enclave and hiding the activity of

the enclave while non-enclave code runs. Enclave code invariably requires access to OS resources such as

networking and user or file I/O, so developers specify an interface between the enclave and the OS. In SGX,

the platform we use for our implementation, the functions made available by this interface are called OCALLs

and ECALLs. OCALLs are made from inside the enclave to the untrusted application, usually for procedures

requiring resources managed by the OS, such as file access or output to a display. ECALLs allow code outside

the TCB to call the enclave to execute trusted code.

An enclave proves that it runs an untampered version of the desired code through a remote attestation

mechanism. Attestation loosely involves an enclave providing a signed hash of its initial state (including

the running code), which a server compares with the expected value and rejects if there is any evidence of a

corrupted program. In order to persist data to disk when an enclave closes or crashes, SGX also provides a

data sealing functionality that encrypts and authenticates the data for later recovery by a new instance of the

enclave.


Finally, one of the key features of enclaves is the protection of memory. An enclave gives developers a

small memory region inaccessible to the OS and only available when execution enters the enclave. In this

memory, the trusted code can keep secrets from an untrusted OS that otherwise controls the machine. SGX

provides approximately 90MB of protected memory. Unfortunately, a number of side-channel attacks have

been shown to break the abstraction of fully-protected enclave memory. We briefly discuss these attacks and

accompanying defenses below and in Section 2.12.

Security of hardware enclaves. We built Fidelius using the hardware enclave provided by Intel’s SGX. SGX

has recently come under several side-channel attacks [43, 154], making the current implementation of SGX

insufficiently secure for Fidelius. However, Intel is updating SGX using firmware and hardware updates with

the goal of preventing these side-channel attacks. In time, it is likely that SGX can be made sufficiently secure

to satisfy the requirements needed for Fidelius. Even if not, other enclave architectures are available, such as

Sanctum for RISC-V [55] or possibly a separate co-processor for security operations.

2.3 Threat Model

We leverage a trusted hardware enclave to protect against a network attacker who additionally has full control

of the operating system (OS) on the computer running Fidelius. We assume that our attacker has the power

to examine and modify unprotected memory, communication with peripherals/network devices, and commu-

nication between the trusted and untrusted components of the system. Moreover, it can maliciously interrupt

the execution of an enclave. Note that an OS-level attacker can always launch an indefinite denial of service

attack against an enclave, but such an attack does not compromise privacy.

We assume that the I/O devices used with the computer are not compromised and that the dongles we add

to keyboards/displays follow the behavior we describe. We could assume that there is a trusted initial setup

phase where the devices can exchange keys and other setup parameters with the enclave. This corresponds

to a setting where a user buys a new computer, sets it up with the necessary peripherals, and then connects

to the internet, at which point the machine immediately falls victim to malware. Alternatively, this honest

setup assumption could easily be avoided with an attestation/key exchange step between the peripherals and

the enclave. We discuss both options in Section 2.6.1.

Overview of Security Goals. We would like to provide the security guarantee that any user data entered via a

trusted input will never be visible to an attacker, and, except in the case of denial of service, the data received

by the server will correspond to that sent by the user, e.g. it will not be modified, shuffled, etc. Moreover, the

enclave will only send data to an authenticated server, and a server will only send data to a legitimate enclave.

Finally, we wish for all the low-level protocols of our system to be protected against tampering, replay, and

other attacks launched by the compromised OS.

The remote server in our setting cooperates to secure the user by providing correct web application code to

be run in the enclave. We are primarily concerned with the security of user secrets locally on a compromised

device, but this does include ensuring that secrets are not sent out to an attacker.


Overview of Usability Goals. Although our work is merely a prototype of Fidelius, we intend for it to be

fully functional and to defend not only against technical attacks on security but also against user interface

tricks aiming to mislead a user into divulging secrets to a malicious party. This task looms particularly

important in our mixed setting where trusted input/output come through the same channels as their untrusted

counterparts. In particular, we must make sure a user knows whether the input they are typing is protected or

not, what data the remote server expects to receive, and where the private data will eventually be sent. We

leave the task of optimizing the user experience to future work, but also aim to provide a tool which can be

used “as-is.”

We also want to provide a usable interface for developers that deviates only minimally from standard web

development practices. As such, we endeavor to add only the minimal extensions or limitations to current

web design techniques to support our security requirements.

Enumeration of Attacks. After describing the system in detail in subsequent sections, we discuss why

Fidelius satisfies our security goals. Here we briefly list the different classes of non-trivial attacks against

which we plan to defend. Refer to Section 2.8 for details on the attacks and how we defend against them.

- Enclave omission attack: The attacker fakes use of an enclave.

- Enclave misuse attack: The attacker abuses Enclave ECALLs for unexpected behavior.

- Page tampering attack: The attacker modifies protected page elements or JavaScript.

- Redirection attack: The attacker fakes the origin to which trusted data is sent.

- Storage tampering attack: The attacker reads, modifies, deletes, or rolls back persistent storage.

- Mode switching attack: The attacker makes unauthorized entry/exits from private keyboard mode.

- Replay attack: The attacker replays private key presses or display overlays.

- Input manipulation attack: The attacker forges or manipulates placement of protected input fields.

- Timing attack: The attacker gains side-channel information from the timing of display updates or key-

board events.

Security Non-Goals. Fidelius provides the tools necessary to form the basis of a secure web application,

focusing on protecting user inputs and computation over them. We do not provide a full framework for

secure web applications or a generic tool for protecting existing web applications. In particular, we do not

protect against developers who decide to run insecure, leaky, or malicious JavaScript code inside an enclave,

but we do provide a simple developer interface to protect security-critical components of applications.

We assume the security of the trusted hardware platform and that the enclave hides the contents of its

protected memory pages and CPU registers from an attacker with control of the OS, so side channel attacks

on the enclave [43,154] are also out of the scope of this work. We discuss side channel attacks and mitigations

for SGX in Section 2.12. Physical attackers who tamper with the internal functionality of our devices also

lie outside our threat model, but we note that our trusted devices seem to be robust against opportunistic

physical attackers that do not tamper with hardware internals but can, for example, attach a usb keylogger to


Card Number

MM/YY CVV

BrowserWeb Enclave

OS

Trusted Path to I/O

Devices Origin

Figure 2.1: Overview of Fidelius. The web enclave, embedded in a malicious browser and OS, communicates with theuser through our trusted I/O path and securely sends data to a remote origin. We assume that both the web browser andthe OS are compromised.

a computer. The SGX hardware itself is also designed to resist advanced hardware attackers.

Finally, we do not address how the honest server protects sensitive data once the user’s inputs reach it. Our

goal is to protect data from compromise on the client side or in transit to the server. Once safely delivered

to the correct origin, other measures must be taken to protect user data. For example, we do not defend

against a server who receives secrets from the user and then displays them in untrusted HTML sent back to

the browser.

2.4 Architecture Overview

The goal of Fidelius is to establish a trusted path between a user and the remote server behind a web applica-

tion. To achieve this goal, Fidelius relies on two core components: a trusted user I/O path and a web enclave.

In practice, this involve subsystems for a secure keyboard, a secure video display, a browser component to

interact with a hardware enclave, and the enclave itself. Figure 2.1 gives an overview of the components of

Fidelius.

2.4.1 Trusted User I/O Path

The trusted user I/O path consists of a keyboard and display with a trusted dongle placed between them

and the computer running Fidelius. Each device consists of trusted and untrusted modes. The untrusted

modes operate exactly the same as in an unmodified system. The trusted keyboard mode, when activated,

sends a constant stream of encrypted keystrokes to the enclave. The enclave decrypts and updates the state

of the relevant trusted input field. The trusted and untrusted display modes are active in parallel, and the

trusted mode consists of a series of overlays sent encrypted from the enclave to the display. Overlays include

rendered DOM subtrees (including, if any, the protected user inputs) placed over the untrusted display output


as well as a dedicated portion of the screen inaccessible to untrusted content. We cover these functionalities

and details of the protocols used to secure them in Section 2.6. Finally, both trusted devices have LEDs that

notify the user when a trusted path is established and ready to collect user input. Our system relies, in part, on

users not typing secrets on the keyboard when these security indicator lights are off. This ensures that only

the enclave has access to secrets entered on the keyboard. We note, however, that several works have studied

the effectiveness of security indicators in directing user behavior [135,160] and found that users often ignore

them. We briefly discuss potential alternatives in Section 2.11, but leave the orthogonal problem of designing

a better user interface – one that is more difficult to ignore – to future work.

2.4.2 Web Enclave

A web enclave is essentially a hardware enclave running a minimalistic, trusted browser engine bound to a

single web origin. A browser using a web enclave delegates the management and rendering of portions of

a DOM tree and the execution of client-side scripts, e.g. JavaScript and Web Assembly, to the enclave. In

addition, the web enclave can send and receive encrypted messages to and from trusted devices and the origin

server. Finally, the web enclave provides client-side script APIs to access the DOM subtree, secure storage,

and secure HTTP communication.

When a user loads a web page, Fidelius checks whether the page contains HTML tags that need to be

protected, e.g., secure HTML forms. If it does, it initiates a web enclave, runs remote attestation between that

enclave and the server, and validates the identity of the server. Once this process completes, Fidelius loads

the HTML tags it needs to protect into the web enclave and verifies their signatures. Then, when the user

accesses a protected tag, e.g. with a mouse click, Fidelius gives control to the enclave, which in turn activates

the devices’ trusted mode. The trusted mode LEDs are turned on, informing the user that the trusted path is

ready to securely collect user input.

Web enclaves provide two main ways to send protected messages to a remote server: directly through an

encrypted form submission or programmatically via an XMLHttpRequest API. When a user clicks a form’s

submit button, the web browser notifies the enclave of this event. Then, the web enclave encodes the form

data following HTML form norms1, encrypts that data, and signs it. The encrypted form is passed to the web

browser, which sends it to the remote server. When a script needs to send messages to the server, it can use the

XMLHttpRequest web API. The web enclave XMLHttpRequest API interface is similar to that implemented

by web browsers; however, it encrypts sensitive fields such as the request body and custom HTTP headers.

HTTP responses are sent by the server in encrypted form. The enclave will automatically decrypt responses

and resume execution of the JavaScript function waiting for the response.

1See, https://www.w3.org/TR/html5/sec-forms.html

https://www.w3.org/TR/html5/sec-forms.html


Card Number

MM/YY CVV

Secure | https://pay.site.com/

Holder Place order

Protecting pay.site.com, Field: CVV Fidelius active

Cancel

Online Store X

Figure 2.2: Design of Fidelius’s user interface. The green area is the trusted display overlay.

2.5 Interface Design

This section describes the interfaces that Fidelius provides for end-users and developers who wish to consume

or create protected web applications. Here we describe only how Fidelius appears to users and developers,

deferring technical details of how it works to subsequent sections.

2.5.1 User Interface

The primary challenge in designing an interface for a system with a mix of trusted and untrusted components

lies in distinguishing the trusted parts from the untrusted parts in a way that cannot be faked by an attacker.

Our solution is to dedicate a small part of the screen to the web enclave, rendering that portion of the screen

inaccessible to the OS while the trusted display is active, as indicated by an LED outside the display. Outside

of this region, user interaction with Fidelius does not differ at all from interactions with a typical web appli-

cation. Figure 2.2 shows the design of Fidelius’s user interface in use on a sample payment page. Trusted

input fields do not have any special visual features that distinguish them from other inputs. Instead, the ded-

icated trusted region of the screen displays information that defends against attacks which make use of UI

manipulation to fool a user into giving sensitive data to an attacker.

There are two important pieces of information shown in the protected display region. First, we must en-

sure that the user sends sensitive information only to the intended destination and avoids attacks like changing

the contents of the url bar or picture-in-picture attacks [86]. We achieve this by including the origin of the

web enclave in the trusted region. In Figure 2.2, the trusted region shows that the web enclave is connected

to pay.site.com.

Second, we must ensure that users can distinguish real trusted inputs from untrusted ones and that an


attacker cannot fool the user by changing the untrusted text surrounding a trusted input field. This could

include attacks where untrusted input fields are made to look just like trusted ones (which in fact is the case

by default in Fidelius) or, for example, where the username and password prompts before two inputs are

switched, causing the user’s password to be processed as a username, which potentially receives far less

protection after being sent to the server. We protect against this class of attacks by displaying a name for each

trusted input in the dedicated display region when that field has focus. This serves to indicate to the user that

the current input field is trusted. It also protects against any attack involving shuffling of input field labels to

fool a user or cause incorrect data to be sent to the server because the descriptive name for each input field

lies outside the reach of an attacker.

2.5.2 Developer Interface

Design of a developer interface must provide an easy to use and backwards compatible way for developers to

access the features of Fidelius. Our developer interface requires no changes for pages or components of pages

that do not make use of Fidelius’s features. Developers who wish to provide stronger security guarantees to

Fidelius users include additional attributes in existing HTML tags directing Fidelius to use the web enclave

in rendering and interacting with the content of those tags. Listing 2.1 shows an example of an HTML page

supporting Fidelius.

1 <html>

2 <head> [...] </head>

3 <body>

4 <form action="submit_data"

5 name="payment"

6 method="POST"

7 secure="True" sign="tX5ReRzE42Qw">

8 <input type="text"

9 value="Holder" name="holder" />


11 value="Card Number" name="card"/>


13 value="MM/YY" name="exp"/>


15 value="CVV" name="cvv"/>

16 </form>

17 <div class="btn"><p>Place order</p></div>

18 <div class="btn"><p>Cancel</p></div>

19 <script type="text/JavaScript"

20 src="validator.js"

21 secure="True" sign="Fi3Rt9mq2ff0">

22 </script>

23 </body>

24 </html>


Listing 2.1: Fidelius-enabled code for the online payment web page. In red, the new HTML attributes required by

Fidelius.

Fidelius currently supports <form>, <input>, and <script> tags. To mark any of these tags as

compatible with Fidelius, developers add a secure attribute to the tag. In the case of <script> and

<form> tags, a signature over the content of the tag is included in a sign attribute, to be verified with

respect to the server’s public key inside the enclave as described in Section 2.7. The signature ensures that

the form and script contents have not been modified by malware before they were passed to the enclave. The

signature is not needed for <input> tags because the signature on a form includes the inputs contained

within it. <input> tags also require a name attribute to be shown in the trusted component of the display

when that input has focus.

JavaScript included in secure <script> tags runs on an interpreter inside the web enclave with different

scope than untrusted code running in the browser. Trusted JavaScript has access to its own memory and its

own web APIs for secure storage and secure HTTP requests, but it cannot directly access the memory or web

APIs available to untrusted JavaScript. Trusted and untrusted JavaScript can, however, make calls to each

other and pass information between each other as needed using an interface similar to the postMessage

cross-origin message passing API.

Fidelius enforces a strict same-origin policy for web enclaves, so network communication originating or

ending in an enclave can only come from its specified origin. By default, the origin of HTML tags is inherited

from the web page. In general, the origin is derived from the initial URL of the page. However, for tags such

as <form> and <script>, the origin is derived from the action and src attributes respecively. The

origin specified here is not authenticated and therefore susceptible to tampering. We discuss the process by

which a web enclave connects to remote servers and verifies their legitimacy in Section 2.7.

2.6 Trusted Path for User I/O

In this section, we describe the building blocks to create and manage a trusted path connecting a keyboard,

display, and web enclave. Specifically, we cover device setup, communication patterns between devices, and

the structure of individual messages passed between devices.

Although we develop our trusted I/O path in the context of the larger Fidelius system and focus our

discussion on web applications, it is important to note that the trusted path is fundamentally a separate system

from the web enclave. In other words, although the two systems interact closely in the design of Fidelius,

the trusted path has applications outside the web and can be run on its own as well. To our knowledge, this

is the first system to provide a trusted path to the user for both input and output relying only on assumptions

about enclave security. We cover the details of how we realize the trusted peripherals in hardware dongles in

Section 2.9.


2.6.1 Setup

In order to securely communicate, the web enclave and peripherals (or the dongles connected to them) must

have a shared key. One option is to operate in a threat model with an initial trusted phase where we assume

the computer is not yet compromised. Pre-shared keys are exchanged when the user configures the computer

for the first time. Devices store the key in an internal memory, and the enclave seals the shared keys for future

retrieval. The key can be accessed only by the enclave directly and not by user-provided JavaScript running

inside it.

In the more realistic setting where new peripherals can be introduced to a computer over time, we must

protect against attacks that involve introduction of malicious periphal devices. In this setting, we need

Fidelius-compatible devices to include a trusted component that can perform an attestation with the enclave

to prove its legitimacy before exchanging keys. Note that this attestation must occur in both directions – from

enclave to keyboard and from keyboard to enclave – or the device that does not attest can be faked by an

attacker.

2.6.2 Trusted Communication

The process of switching between trusted and untrusted modes presents an interesting security challenge.

An authentication procedure between the enclave and the trusted devices can ensure that only the enclave

initiates switches between trusted and untrusted modes, but this ignores the larger problem that the enclave

must rely on the untrusted OS to inform it when an event has happened that necessitates switching modes.

Avoiding that necessity would require moving a prohibitively large fraction of the browser and UI into an

enclave. Our solution has two parts and relies on making the user aware of when key presses produce trusted

or untrusted input. First, we include a light on each dongle that turns on only when the keyboard or display

are in trusted mode. This alone, however, does not suffice to solve the problem, as an attacker could mount a

“rapid switching” attack where it jumps in and out of trusted mode faster than the user can perceive or react,

leading to parts of the user’s input being leaked by untrusted input. Even worse, rapid switching between

modes may occur quickly enough to not be noticable to a user monitoring the lights. To prevent this attack,

we force a short delay when switching out of trusted mode. This ensures the user will have time to notice and

react when a switch occurs.

The enclave switches devices in and out of trusted mode by sending one of two reserved messages which

are simply fixed strings that they interpret as commands to change the trust setting. When in trusted mode,

messages between the enclave and the peripherals are encrypted as described in Section 2.6.3.

Since the timing of key presses can reveal sensitive information about what keys are being pressed [143],

we must also avoid leaking timing information while in trusted input mode. We do this by having the keyboard

send a constant stream of key presses where most contain only an encryption of a dummy value that indicates

no key pressed. As long as the fixed frequency of key presses exceeds the pace at which a user types, the user

experience is unaffected by this protection. Since user key presses typically result in changes on the display,


we update the display contents at the same rate as we read keyboard inputs.

Our trusted input design in many ways mirrors that of Bumpy [115] and SGX-USB [87], which also

provide generic trusted user input using similar techniques but do not provide the web functionality that we

do. In contrast to our work, Bumpy does not display any trusted user input. SGX-USB allows for generic I/O

but does not solve the problem of mixing trusted and untrusted content in a user interface as we do in both our

keyboard and display. Neither system has source code available. We improve on the features of both works

by protecting against timing attacks on encrypted data sent from trusted input devices.

2.6.3 Message structure

Messages sent in the trusted communication protocol described above must include safeguards against replay

attacks. To do this, we include a counter in every message sent, so that the same count never repeats twice.

Counters are maintained on a per-device and per-origin basis, so every message between the enclave and the

keyboard or display must include a counter value and the name of the origin in addition to the encrypted key

press or overlay itself.

2.7 Web Enclave

In this section we cover the details of the web enclave. First, we provide an overview of the state transitions

of a web enclave. Next, we present the protocols for remote attestation, origin authentication, and exchange

of key material. Finally, we present the details of the operations: secure HTML forms, JavaScript code

execution, secure network communication, and persistent storage across web enclave executions.

2.7.1 Web Enclave State Machine

The web enclave implements the state machine in Figure 2.3. At any point, it can be in one of the following

five states: initial, authenticated, ready, end, and fail. Transitions are caused by ECALLs. Each state has a

list of accepted ECALLs. For example, the initial state accepts only ECALLs for the remote attestation and

origin validation. Other ECALLs bring the web enclave to the fail state. No other transition is possible from

this state, and the enclave needs to be terminated after reaching it.

Fidelius creates a web enclave when it finds any <form> or <script> tags with the secure attribute

set. Then it derives the origin of the tags that need to be protected. By default, the origin of the tags are

inherited from the web page they belong to, i.e., the domain and port of the URL. However, for tags such as

<form> and <script>, the origin is derived from the action and src attributes respecively. Tags can

have different origins. While it is possible to create one web enclave for each origin, the current version of

the web enclave assumes that all protected components on a page communicate with the same origin.

Once the origin has been determined, Fidelius passes the origin to the web enclave and performs remote

attestation and origin validation, after which the enclave and the origin can share a symmetric key. This key


Initial

Ready

Authed

End

Fail

Ecall SuccessEcall Failure

Remote Attestation & origin verification

Add formsAdd JavaScript

Verify tag signatures

Run JavaScriptEvent notificationsGet encrypted keystrokesSend encrypted frames

Exit page or manually terminate

Figure 2.3: State machine representing web enclave behavior.

will be used to encrypt any communication between the enclave and the origin, so any network manipulation

or monitoring will only result in an attacker recovering encrypted data for which it does not have the key. As

a result, the rest of the network stack can remain outside the enclave in untrusted code. In order to verify an

origin, the enclave must have the corresponding public key, either as a hard-coded value or, more realistically,

by verifying a certificate signed by a hard-coded authority.

At this point, the web enclave is in the authenticated state. Fidelius retrieves the tags with the secure

attribute set and loads them into the enclave. These operations do not cause a state transition. The only

ECALL that causes a valid transition from this state is verification of the signatures. If the validation of all

signatures succeeds, the enclave enters the ready state. From this point on, the enclave is fully operational

and can decrypt keyboard inputs, prepare encrypted outputs for the display, execute JavaScript functions, and

take/release control of the trusted path upon focus and blur events respectively.


2.7.2 Features

Once an enclave has successfully entered the ready state, the full functionality of Fidelius becomes avail-

able to the web application. Fidelius supports secure HTML forms, JavaScript execution, secure network

communication, and persistent protected storage.

Secure HTML Forms. When parsing a page, Fidelius finds <form> tags with the secure attribute and,

after verifying the provided signature using the server’s public key, creates a form data structure inside the

enclave to keep track of the form and each of the inputs inside it. We currently store server public keys inside

the enclave but could replace this with root certificates instead. When the user highlights an input inside a

given form, the browser notifies the enclave. The enclave switches the keyboard from untrusted to trusted

input mode (see Section 2.6 for details), and subsequent user key presses modify the state of the highlighted

input field. As mentioned in Section 2.5, various defenses at the interface level protect against attacks that

an attacker could mount by modifying untrusted content between the enclave and the user. By pushing these

defensess into the UI, we allow ourselves to keep many components of the browser outside of the enclave

and dramatically reduce Fidelius’s TCB. For example, monitoring of mouse movements and placement of

forms on the page can be managed outside the enclave, and tampering/dishonesty with these elements will be

detected by a user who notices the inconsistency between what she sees on the screen and the content of the

trusted overlay.

Submission of HTML forms involves encrypting the content of the form as one blob using the shared key

negotiated during attestation and sending that to the server.

Javascript. We run a JavaScript interpreter inside the enclave but leave out heavy components like the event

loop. When a trusted JavaScript function is called, the enclave provides the interpreter with function inputs

and any other state that should be available to the code about to run.

Javascript running in the enclave can access the content of protected HTML forms via the the global

variable forms. The forms variable contains a property for each form name. For example, with reference to

the HTML code in Listing 2.1, the payment form can be accessed via forms.payment where payment

is the value of the attribute name of the <form> tag. Developers can implement custom input validation

procedures. For example, a very simple form of validation can be checking if the credit card field contains

forbidden characters such as white spaces. The JavaScript function that verifies the presence of white spaces

can be implemented as shown in Listing 2.2.

1 function cardNumberHasWhiteSpaces()

2 return /\s/g.test(forms.payment.card);

3

Listing 2.2: Simple form validation

Network Communication. In order for protection of user data on the local machine to translate into a useful

web application, there must be a mechanism for transmitting data out from the enclave without tampering

by the compromised browser or OS. We provide a basic mechanism for doing this by supporting HTML

forms, but web applications in general need to send back data to the server programmatically in a variety of


contexts, not just when a user submits a form. To support this need, we provide support for XMLHttpRequests

(as shown in Listing 2.3) where requests are encrypted inside the enclave using the shared key from the

attestation process before leaving the enclave.

1 function doPay(e)

2 // input form to JS associative array

3 d = toDict(forms.payment);

4

5 // validate payment data

6 if (validate(d))

7 return false;

8

9

10 // prepare raw messages

11 json_str = JSON.stringify(d);

12

13 // create SecureXMLHttpRequest

14 var xhr = new SecureXMLHttpRequest();

15 xhr.open("POST",

16 "https://pay.site.com/submit_data",

17 false); // only sync calls

18

19 // use sec_json content type

20 xhr.setRequestHeader('Content-Type',

21 'application/sec_json; charset=UTF-8');

22

23 // encrypt, sign, and send

24 xhr.send(json_str);

25

26 // seal data for possible future reuse

27 storeCreditCardData(d);

28

Listing 2.3: XMLHTTPRequest example

The problem of defending against replay of messages over the network is not unique to the trusted hard-

ware setting and must be handled separately by applications built on Fidelius.

Persistent Storage. Fidelius provides developers with a web storage abstraction similar to the standard web

storage provided by unmodified web browsers. Secure web storage can be accessed via localStorage,

as shown in Listing 2.4.

1 function storeCreditCardData(d)

2 localStorage['holder'] = d.holder;

3 localStorage['cc'] = d.card;

4 localStorage['exp'] = d.expiry;

5 localStorage['cvv'] = d.cvv;

6


Listing 2.4: Web storage

When the need for persistent storage arises, Fidelius encrypts the data to be stored using a sealing key and

stores it on disk (it could equivalently use existing browser storage mechanisms to hold the encrypted data).

The sealing key is a feature provided by SGX to an enclave in order to store persistent data across multiple

runs of the enclave.

This approach raises two problems we must resolve. First, every instance of the same enclave shares the

same sealing key, so we must ensure that different enclaves created by the same browser cannot read each

others’ secrets. We can prevent this problem by including the associated origin as additional authenticated

data with the encrypted data to be stored. This way an enclave can find and restore data associated with the

origin it connects to but, as a matter of policy, does not allow the user to access data associated with any

other origin. The integrity guarantees of our trusted hardware platform ensure that our code will abide by this

policy.

The second issue is that of rollback attacks. A malicious operating system could roll back or delete data

that is stored to disk, so, for applications that rely on maintaining sensitive state, the enclave must have a

way to determine whether it has the most up-to-date stored data. A generic solution to this problem, such

as ROTE [111], would suffice, but ROTE requires a distributed setting which may not be available to a user

browsing the web from home. We can solve this problem by enlisting the assistance of the server to ensure

protection against rollbacks, especially in situations where an enclave is connected to a server that already

keeps information about the user. The idea is to keep a revision number, one for each origin, that gets sent

from the server to the enclave at the end of the attestation process and is incremented whenever changes are

made to locally stored data. Since the attacker cannot change the number stored on the server or in the enclave

during execution, we can detect whenever a rollback attack has been launched or stored data has been deleted

by observing a mismatch between the number on the data reloaded by the enclave and the number sent by the

server.

Our generic approach for storage of user secrets and network connections could easily be extended to

include storage of cookies, resulting in a separate cookie store, accessible only to the enclave, that otherwise

provides the same functionality available from cookies in unmodified browsers.

2.8 Security Analysis

In this section we give a clear enumeration of the different kinds of threats against which we expect Fidelius

to defend and argue that Fidelius does indeed protect against these attacks. We first discuss attacks on the

core features of Fidelius and then move on to attacks targeted specifically at the trusted I/O path and user

interface.


2.8.1 Attacks on Core Features

Enclave omission attack. An attacker with full control of the sofware running on a system may manipulate

the browser extension and enclave manager software to pretend to use an enclave when in fact it does not.

This attack will, however, fail because of defenses built into our user interface via the keyboard and display

dongles. Absent a connection to a real enclave, the trusted input lights on the keyboard and display will not

light, alerting the user that entered data is unprotected.

Enclave misuse attack. A more subtle attack of this form uses the enclave for some tasks but fakes

it for others. For example, to circumvent the defense above, trusted input from the user could use the real

enclave functionality, but trusted output on the display could be spoofed without the enclave. As such, it is

necessary for each I/O device to separately defend against fake use of an enclave. The defenses described for

the previous attack suffice to protect against this attack as well, but both lights are needed.

An attacker could also use the genuine trusted I/O path but attempt to omit use of the enclave when run-

ning JavaScript inside the browser. This attacker could clearly not access persistent storage, trusted network

communication, or user inputs because those features require keys only available inside the enclave. On

the other hand, the JavaScript to be run inside the enclave is not encrypted, so an attacker could potentially

also run it outside the enclave, so long as it does not make use of any other resources or features offered by

Fidelius. At this point, however, the JavaScript becomes entirely benign because it cannot give the attacker

running it any new information or convince the user or remote server of any falsehoods because the trusted

paths to all private information or trusted parties are barred.

A last variant of this attack would omit certain ECALLs that perform necessary setup operations like

initializing a form and its inputs before the user begins to enter data. Omission of these ECALLs would

result in the system crashing but would not leak secrets in the process. As mentioned before, we cannot

conceivably protect against a denial of service attack where the compromised OS refuses to allow any access

to the system. We can only ensure that normal or abnormal use of the enclave does not leak user secrets.

Page tampering attack. Failing to omit an enclave entirely or even partially, the attacker can turn to

modifying the inputs given to various ecalls. In particular, the names and structure of forms and their inputs

or the JavaScript to be run inside the enclave could be modified. Mounting this attack, however, would require

an adversary who can break the unforgeability property of the signatures used to sign secure <form> and

<script> tags. Those tags are verified with an origin-specific public key (either hard-coded in the enclave

or verified with a certificate) that lies out of reach of our attacker.

Since trusted JavaScript is the only way to access trusted user inputs from within the browser, the fact that

we have separate scope for execution of trusted and untrusted JavaScript means that any attempt to directly

access user secrets stored in protected inputs will necessarily be thwarted.

Redirection attack. This attack resembles a straightforward phishing attempt. Instead of tampering

with the operation of Fidelius, a browser could navigate to a malicious website designed to look legitimate

in an attempt to send user secrets to an untrusted server. Here again the persistent overlay added by our

display dongle prevents an attack by displaying the origin to which the enclave has connected. The strict


same-origin policy within the enclave means that the origin displayed in the trusted portion of the screen

is the only possible destination for network connections originating withing the enclave. While an attacker

could establish a connection with a server other than the declared origin, the data sent to that server will be

encrypted with a key known only to the intended origin, rendering the data useless to others. As such, the

only way for an attacker to have legitimate-looking text appear there is to send user data only to legitimate

destinations.

Storage tampering attack. Although authenticated encryption with a sealing key tied to the enclave

protects persistently stored data from tampering, an attacker can still delete or roll back the state of stored

data. We detail our solution to protect against this attack in Section 2.7.2, where we enlist the assistance of

the server to keep an up-to-date revision number for the enclave’s data out of reach of the attacker. Attacks

where the browser connects to a malicious site whose trusted JavaScript tries to read or modify persistent

storage for other sites are prevented by our policy of strict separation between stored data associated with

different origins.

2.8.2 Attacks on Trusted I/O Path and UI

We now consider attacks against the trusted I/O path to the user. Direct reading of private key presses and

display outputs is prevented by encryption of data between the enclave and keyboard/display dongles, but we

also consider a number of more sophisticated attacks. Since the I/O path to the user closely relates to the

user interface, we discuss attacks against both the protocols and the interface together. We discuss security

considerations involved in the setup of trusted I/O devices in Section 2.6.1.

Mode switching attack. As discussed in Section 2.6, the decision to switch between trusted and untrusted

modes ultimately lies with the untrusted browser because it decides when an input field receives focus or blurs

or when to activate Fidelius in the first place. We defend against this type of tampering with the light on the

dongles and the delay when switching from trusted to untrusted modes. These defenses protect against both

a standard unauthorized exit from the enclave as well as a rapid switching attack that tries to capture some

key presses by quickly switching between modes.

Replay attack. We defend against replay of trusted communications between the enclave and display by

including a non-repeating count in every message that is always checked to make sure an old count does not

repeat. An attacker could, however, eavesdrop on key presses destined for one enclave, switch to a second

enclave connected with a site it controls, and replay the key presses to the second enclave in an attempt to read

trusted key presses. We defend against this attack by including the name of the origin along with the count

in encrypted messages, so they cannot be replayed across different enclaves. Likewise, since the keyboard

and display use different keys to encrypt communications with the enclave(s), messages cannot be replayed

across sources.

Input manipulation attack. Attackers can attempt to make untrusted input fields appear where a user

might expect trusted input fields and thereby fool users into typing trusted information in untrusted fields.

Since the attacker has almost full control of what gets placed on the display, this grants considerable freedom


in manipulating the display to mimic visual queues that would indicate secure fields. Fortunately, our display

dongle reserves a strip at the bottom of the screen for trusted content directly from the enclave. This area

informs the user what trusted input is currently focused, if any.

An attacker could also manipulate the placement of actual trusted input fields or the labels that precede

them on a page in order to confuse or mislead a user as to the purpose of each field. By using the trusted

display area to show which trusted input currently has focus, if any, we give developers the opportunity to

assign inputs descriptive trusted names that will alert a user if there is a mismatch between an input’s name

and its stated purpose in the untrusted section of the display.

Timing attack. The fact that key presses originate with the user means that the timing of presses and

associated updates to content on the screen may leak information about user secrets [143]. We close this

timing side channel by having the keyboard send encrypted messages to the enclave at a constant rate while

in trusted mode, sending null messages if the user does not press a key during a given time period and

queueing key presses that appear in the same time period. A high enough frequency for this process ensures

that the user experience is not disrupted by a backlog of key presses. Updates to display overlay contents also

happen at a constant rate, so timing channels through key presses and display updates cannot leak information

about user secrets.

Multi-Enclave Attacks. As mentioned in Section 2.3, Fidelius does not aim to protect against attacks

mounted by incorrect or privacy-compromising code provided by an origin that has already been authenti-

cated. That said, we briefly discuss here some attacks that could be launched by collaboration between a

malicious OS and a malicious remote origin that is trusted by Fidelius (for example, in case of a maliciously

issued certificate) and which tries to steal data a user meant to send to a different trusted origin. An attacker

who has compromised a trusted site could always ask for data from a user directly, rendering these attacks

less important in practice, but there may be some kinds of data a user would only want to reveal to one trusted

origin and not others, e.g. a password for a particular site.

First we consider an enclave-switching attack, a more involved variant of the mode-switching attack

described above. In this attack, the untrusted sytem rapidly switches between different enclaves, one con-

necting to a legitimate site and the other to a malicious site controlled by the attacker. Fidelius’s existing

mode-switching delay also protects against this variant of the attack because the display always shows the

origin associated with the enclave currently in use.

A more complicated attack could run one honest, uncompromised enclave concurrently with an enclave

connected to an malicious origin. The uncompromised enclave would feed its overlays to the display while

the compromised enclave would receive inputs from the keyboard. This may be noticed by users in the current

Fidelius design because anything typed would not appear on the display, but by the time a user notices this,

secrets may have already been compromised. To defend against this, the keyboard and display dongles could

be configured to only connect to one enclave at a time (not connecting to another enclave until the first enclave

declares it has entered the end state) and to check that they have connected to the same enclave at setup by

using the enclave to send each other hashes of fresh origin-specific secrets.


Figure 2.4: Images of our Fidelius prototype in use. The image above shows the view of a user, and the image belowshows the view of an attacker taking a screen capture while the user enters credit card information. Since trusted overlaysare decrypted and placed over the image after leaving the compromised computer, the attacker does not see the user’sdata.


USB HID USB HID

Trusted Keyboard ON/OFF

Sec USB HID

Browser

OS

Web Enclave

RPI 3RPI Zero

Overlay Frames

HDMI

HDMI

(a) (b) (c)

Trusted Display ON/OFF

Figure 2.5: Prototype of the trusted path: (a) standard USB keyboard connected to our RPI Zero dongle to encryptkeystrokes, (b) Computer with a Fidelius-enabled browser, and (c) standard HDMI display connected to our RPI 3 dongleto overlay secure frames.

2.9 Implementation

We implemented a prototype of Fidelius, including both the trusted path described in Sections 2.5 and 2.6 and

the Web Enclave features described in Section 2.72. Our prototype is fully functional but does not include

the trusted setup stage between the enclave and devices, which we carry out manually. Figure 2.4 shows

screenshots of our prototype in use, and Figure 2.5 gives an overview of its physical construction.

Since Fidelius requires few changes on the server side and our evaluation therefore focuses on browser

overhead, we do not implement a server modified to run Fidelius. This would consist mainly of having the

server verify a remote attestation and decrypt messages from the web enclave.

2.9.1 Trusted Path

Our prototype runs on an Intel Nuc with a 2.90 GHz Core i5-6260U Processor and 32 GB of RAM running

Ubuntu 16.04.1 and SGX SDK version 2.1.2. We produced dongles to place between the Nuc and an off-

the-shelf keyboard and display using a Raspberry Pi Zero with a 1 GHz single core Broadcom BCM2835

processor and 512 MB of RAM running Raspbian GNU/Linux 9 (stretch) for the keyboard and a Raspberry

Pi 3 with a 1.2 GHZ quad-core ARM Cortex A53 processor and 1GB RAM running Raspbian GNU/Linux 9

(stretch) at a display resolution of 1280x720. Figures 2.6 and 2.7 show our input and output dongle devices.

The Raspberry Pi Zero simulated two input devices to the Nuc, one standard keyboard and one secure

keyboard, with only one device active at any time based on the state of the application being run. The RPI 3

uses a B101 rev. 4 HMDI to CSI-2 bridge and the Picamera Python library [89] to treat the HDMI output from

the Nuc as a camera input on which it overlays trusted content before rendering to the real display. Trusted

content is sent over a separate bluetooth channel. The bluetooth channel exists as a matter of convenience

for implementation, as HDMI does allow for sending auxiliary data, but we were unable to programmatically

access this channel through existing drivers.2Our open source implementation of Fidelius, the instructions to build the dongles and accompanying sample code are available at

https://github.com/SabaEskandarian/Fidelius.

https://github.com/SabaEskandarian/Fidelius


Power

USB toComputer

Debugging Display

Bluetooth Keyboard InputOutput pins for LED

Figure 2.6: Trusted keyboard dongle built from Raspberry Pi Zero. In untrusted mode, the dongle forwards key pressesfrom the keyboard to the computer. In trusted mode, the dongle sends a constant stream of encrypted values to the enclave.The values correspond to key presses if there has been any input or null values otherwise.

When an encrypted overlay packet reaches the RPI3 display device from the Nuc, it is first decrypted and

decoded from a flat black and white encoding used to transfer data back to a full RBG color representation.

Next, the image is transferred from the decryption/decoding program to the rendering code, which places it

on the screen. We introduce a refresh delay between sending frames to give the Picamera library adequate

time to render each frame before receiving the next one.

Although we have built a working Fidelius prototype, a number of improvements could make for a more

powerful and complete product. These changes include miniaturization of dongle hardware, faster transfer

protocols, e.g. USB 3.0 instead of Bluetooth, and custom drivers to reduce latency between the dongles and

the keyboard/display. We leave the engineering task of optimizing Fidelius to future work.

2.9.2 Browser and Web Enclave

On the Intel Nuc device, Fidelius is implemented as a Chrome browser extension running on Chrome version

67.0.3396 communicating with a native program via Chrome’s Native Messaging API3 for web enclave man-

agement. The extension activates on page load and checks whether the page contains components that need to

be protected, e.g., secure HTML forms and JavaScript. If it does, it communicates with the native program to

initiate the web enclave and perform remote attestation with the server. Once this process completes, the user

3See https://developer.chrome.com/apps/nativeMessaging

https://developer.chrome.com/apps/nativeMessaging


HDMI In(Computer)

HDMI Out(Display)

Power

BluetoothDongle

HDMI to Camera Input

Output pins for LED

Figure 2.7: Trusted display dongle built from Raspberry Pi 3. Frames arrive on the RPI3 over HDMI in, which connectsthrough a board that treats the frames to be displayed as camera inputs. Overlays are transmitted over Bluetooth anddecrypted on the RPI3. The combined frame and overlay go to the display through the HDMI out cable.

can interact with secure components on the page, and secure JavaScript code can be run in the enclave. Since

the page setup process occurs independently of the page loading in the browser, only the secure components

of a page are delayed by the attestation process – non-secure elements of a page have no loading penalty as a

result of running Fidelius.

The majority of the work of enclave management is handled by the native code. For symmetric encryption

of forms, bitmaps, and keystrokes we use AES-GCM encryption and for signing forms we use ECDSA

signatures. JavaScript inside the enclave is run on a version of the tiny-js [162] interpreter that we ported

to run inside the enclave.

2.10 Evaluation

We evaluate Fidelius in order to determine whether the overheads introduced by the trusted I/O path and web

enclave are acceptable for common use cases and find that Fidelius outperforms display latency on some

recent commercial devices by as much as 2.8× and prior work by 13.3×. Moreover, communication between

the browser and enclave introduces a delay of less than 40ms to page load time for a login page. We also

identify which components of the system contribute the most overhead, how they could be improved for a


iPhone6s

GalaxyS7

Fidelius HTCRezound

KindleOasis 2

0

200

400

600

Lat

ency

(ms)

Display Response Latency

5 100

20

40

60

Number of Trusted Components

Lat

ency

(ms)

Additional Page Load Time

ScriptsForms

Refresh Decrypt Decode Transfer Render

0

20

40

60

80

100

Lat

ency

(ms)

Display Pipeline Costs

Figure 2.8: Fidelius key press to dis-play latency compared with the screenresponse time on various commercialdevices.

Figure 2.9: Impact on page load timeas the number of trusted componentsvaries. Adding components does notsignificantly affect load time.

Figure 2.10: Breakdown of displaycosts by component. Render/refreshdelays are an artifact of our hardwareand could be dramatically reduced.

production deployment, and how performance scales for larger and more complex trusted page components.

TCB Size. The trusted code base for Fidelius consists of 8,450 lines of C++ code, of which about 3200 are

libraries for handling form rendering and another 3800 are our enclave port of tiny-js. This does not

include native code running outside the enclave or in the browser extension because our security guarantees

hold even if an attacker could compromise those untrusted components of the system. It also excludes dongle

code which runs on the Raspberry Pi devices and not the computer running the web browser. Compared to

the 18,800,000 lines of the Chrome project4, Fidelius supports many of the important functionalities one may

wish to secure in a web browser while exposing an attack surface orders of magnitude smaller than a naive

port of a browser into a trusted execution environment.

Comparison to Commercial Devices. For a standard login form with username and password fields, Fi-

delius’s key press to display latency is 201.8 ms. We exclude the time it takes to transfer the encrypted key

press from the keyboard to the enclave over USB 2.0 (480 Mbps) and the encrypted bitmap from the enclave

to the display over bluetooth (3 Mbps) from these figures. This is a reasonable omission because the size of

the data being transferred is small compared to the transfer speed of these two protocols. Figure 2.8 compares

the latency between a key press and display update in Fidelius to measurements of the display latency on sev-

eral commercial mobile devices [106]. Although not competitive with high-performance devices, Fidelius

performs comparably or even faster than some popular commercial devices, running 2.8× faster than the

latency on the most recent Kindle. Fidelius’s efficiency arises from leaving the majority of a page unmodified

and only using encrypted overlays for trusted components.

Comparison to Prior Work. We also compared Fidelius to Bumpy [115], which provides a trusted input

functionality but no corresponding display. For this comparison, we compared Bumpy to Fidelius’s trusted

path without the display component, which accounts for the vast majority of the latency. Bumpy’s source

code is not available, so we compare to the reported performance values measured on an HP dc5750 with an

4https://www.openhub.net/p/chrome/analyses/latest/languages_summary

https://www.openhub.net/p/chrome/analyses/latest/languages_summary


Field size(s) W H W×H px Time (ms) Incr. (ms)

1 Small 171 50 8,550 195.83 -1 Medium 342 50 17,100 199.20 3.381 Large 683 50 34,150 209.65 10.451 Extra large 911 50 45,550 214.74 -2 Extra large 911 100 91,100 227.02 12.28

Figure 2.11: Key press to display latency when rendering forms. Widths are fractions of the most popular screen width(w = 1366px): S= 1

8w, M= 1

4w, L= 1

2w, XL= 2

3w. Increments calculated from the previous row.

AMD Athlon64 X2 Processor at 2.2 GHz and a Broadcom v1.2 TPM. Fidelius outperforms Bumpy’s reported

performance by 13×, running with a latency of 10.59ms compared to Bumpy’s 141ms. We believe this

more than compensates for differences in the computing power used to evaluate the two systems. Although

SGX-USB [87], whose source code is also unavailable, was developed on more recent hardware, we cannot

compare directly to their reported performance results because they report generic USB data transfer rates

into an enclave whereas we care about the latency of reading and processing key presses.

Page Load Overhead. Figure 2.9 shows the page load overhead incurred by Fidelius, not including remote

attestation. Fidelius’s overhead includes the time for the browser to inform the enclave of secure components

and for the enclave to verify signatures on them, totaling 35.3ms. We do not report time for remote attestation,

which depends on the latency to the attestation service. Fortunately, waiting for the attestation server to

respond can occur in parallel with other page load operations because notifying the enclave of the existence

of trusted components and verifying signatures do not involve sensitive user data. Moreover, attestation time

is independent of page content, so our measurements fully capture Fidelius’s page load time increase as

trusted components are added. As seen in Figure 2.9, adding components does not significantly increase page

load time.

Performance Factors. Figure 2.10 shows the cost of various components of our trusted display pipeline,

described in Section 2.9.1, which makes up almost all of Fidelius’s performance overhead. The two most

expensive operations that take place on the display are rendering the overlay using the Picamera module and

the refresh delay we introduce in order to allow the Picamera module to process frames without forming a

queue of undisplayed frames. The Picamera module and associated hardware on the Raspberry Pi 3 is not op-

timized to add a dynamic overlay to the camera feed. A better approach would involve directly manipulating

the data from the Nuc computer’s HDMI output instead of using it to simulate a camera and placing overlays

on top of the camera feed. This could easily be achieved in a production deployment of Fidelius and would

dramatically reduce display latency.

We also considered how performance varies as the size of the trusted components on a page increase.

Figure 2.11 shows that latency increases linearly with the size of the trusted component. This happens because

as the size of the overlay increases, it takes longer to decrypt, decode and transfer the overlays. Taking

steps to optimize the display pipeline would further mitigate latency increase. However, even under our


current implementation, for two full-page width input fields (See the two extra large input field experiments

in Figure 2.11), Fidelius has a display latency of only 227ms. Also, a tenfold increase in pixels (from one

small field to two extra large fields) results in only a 31ms latency increase.

2.11 Discussion and Extensions

Fidelius opens the door to a new class of secure web applications supported by the widespread availability of

hardware enclaves in modern computers. The fundamental problems solved by Fidelius – reliably establish-

ing a path from I/O devices to an enclave residing in an otherwise untrusted system and of protecting web

applications without moving large portions of a browser into an enclave – have applications well beyond the

login and payment examples described thus far.

Fidelius’s techniques and architecture can also support more complex applications such as online tax

filing or even web-based instant messaging. The trusted I/O path has applications beyond the web as well

and could be adapted to secure logins or desktop applications that use enclaves for their core functionality

but require interaction with a local user on the machine. We anticipate that Fidelius’s I/O approach will be

very useful, as hardware enclaves are most widely available on consumer desktop and laptop computers.

We close with a discussion of possible extensions that could broaden the applicability of our architecture

or would be important considerations in a widespread deployment.

Usability of Trusted Devices. We have implemented Fidelius with a user and developer interface that pro-

vides users with the necessary tools to interpret their interaction with Fidelius properly and avoid UI-based

attacks. However, our interface represents only one possible design for interaction between users and the

core Fidelius functionality. A great deal of work has studied the effectiveness of security indicators such as

our indicator lights [135, 160]. Other possible designs may, for example, use secure attention sequences or

separate trusted buttons to initiate communication with trusted components. Future work could explore this

space to determine what approach works best for this application in practice.

Event Loop. Fidelius leaves the JavaScript event loop outside the enclave to optimize the tradeoff between

TCB size and functionality. A number of additional applications could be enabled by moving the event loop

into an enclave, especially if there is a way to accomplish this more efficiently than with a direct port that

executes the loop as-is in trusted hardware.

HTML Rendering. In order to render HTML forms, we implemented a custom library that, given a descrip-

tion of a form and its inputs, produces a bitmap that represents the form. In order to extend support to other

HTML tags, we need to integrate a more versatile rendering engine into our web enclaves. Existing libraries

such as Nuklear [117] provide a solid first step in this direction.

Root Certificate Store. Our current implementation of the web enclave uses a limited number of public keys.

To scale to supporting any web site, the web enclave needs to have a root certificate store inside the enclave.

Mobile Devices. We have described Fidelius in the setting of a desktop device, but much of users’ interaction

with the web today takes place on mobile devices. While much of the Fidelius architecture could apply


equally well in an enclave-enabled mobile setting, a trusted path system for phones and tablets will necessarily

look very different from the keyboard and display dongles used by Fidelius. Android’s recent protected

confirmation system [58] represents a promising first step in this direction.

2.12 Related Work

NGSCB. In 2003 Microsoft announces the Palladium effort, later renamed NGSCB [161]. In that design,

attestation is provided by a TPM chip and enclave isolation is provided by hardware memory curtaining. The

project was scaled back in 2005 presumably due to the difficulty of adapting applications to the architecture.

In contrast, as we explained, web sites can take advantage of Fidelius by simply adding an HTML attribute

to web fields and forms that it wants to protect.

SGX and the Web. TrustJS [77] explores the potential for running JavaScript inside an enclave, demonstrat-

ing that running trusted JavaScript on the client-side can expedite form input validation. SecureWorker [121]

provides the developer abstraction of a web worker while executing the worker’s JavaScript inside an enclave.

Our work uses the ability to run JavaScript in an enclave as a building block to enable privacy for user inputs

in web applications. JITGuard [70] uses SGX to protect against vulnerabilities in Firefox’s JIT compiler.

Unmodified Applications on SGX. A handful of works aim to allow execution of unmodified applications

inside an SGX enclave. Haven runs whole applications inside an enclave [20], while SGXKernel [150],

Graphene [151], and Panoply [141] provide lower level primitives on which applications can be built. Scone [15]

secures linux containers by running them inside an enclave. Flicker [113] and TrustVisor [112] use older

hardware to provide features similar to SGX on which general applications can be built, albeit with weaker

performance due to the older and more limited hardware features on which they build. We focus on directly

solving the problem of hiding user inputs in an untrusted browser without using generic solutions in order to

minimize TCB and avoid the potential pitfalls of porting a monolithic browser into a trusted environment.

SGX Attacks and Defenses. A number of side channel attacks on SGX have been shown to take advan-

tage of, among other things, memory access patterns [38, 79, 164], asynchronous execution [158], branch

prediction [103], speculative execution [43, 154], and even SGX’s own security guarantees [136] to com-

promise data privacy. There do, however, exist many defenses that have been shown to evade these side

channels, often generically, without a great deal of overhead [111,130,138–140,142]. Even more promising,

researchers have proposed a series of other architectures [55, 105, 109] which defend against weaknesses in

SGX by design and are therefore invulnerable to broad classes of attacks. As our work is compatible with

generic defenses and concerns itself primarily with higher level functionalities built over enclaves, we do not

consider side channels in the presentation of Fidelius.

Protection Against Compromised Browsers. A number of software-based solutions for protection against

compromised browsers offer tradeoffs between security, performance, and TCB size. Shadowcrypt [81] uses

a Shadow DOM to allow encrypted input/output for web applications, but is vulnerable to some attacks [71].

Terra [73] uses VMs to allow applications with differing security requirements to run together on the same


hardware. Tahoma [56], IBOS [149], and Proxos [148] integrate support for browsers as OS-level features,

allowing smaller TCBs and stronger isolation/security guarantees than in a general-purpose OS. Cloud termi-

nal [110] evades the problem of local malware and protects against attackers by only running a lightweight

secure thin terminal locally and outsourcing the majority of computation to a remote server.

Trusted I/O Path. While many works study how to use a hypervisor to build a trusted path to users (e.g. [30,

37, 67, 165, 167]), little work has been done in the trusted hardware setting. SGXIO [159] provides a hybrid

solution that combines SGX with hypervisor techniques to allow a trusted I/O path with unmodified devices.

In contrast, our work relies only on hardware assumptions with no need for a hypervisor, but does require

modified keyboard and display devices. Intel has alluded to an internal tool used to provide a trusted display

from SGX [82, 99], but no details, source code, or applications are available for public use. SGX-USB [87]

allows for generic I/O but does not solve the problem of mixing trusted and untrusted content in a user

interface as we do in both our keyboard and display. ProximiTEE [60] bootstraps a similar generic trusted

I/O path off of a modified attestation procedure with new safeguards over standard SGX attestation.

Bumpy [115] (and its predecessor BitE [114]) use the trusted execution environment provided by Flicker [113]

to provide a secure input functionality similar to ours. Aside from the larger web architecture which we build

over our trusted I/O features, we go beyond these works by 1) enabling interactivity with the trusted input via

the trusted display (Bumpy does not display characters the user types) and 2) closing timing side channels on

user input (an improvement we also offer over SGX-USB).

2.13 Conclusion

We have presented Fidelius, a new architecture for protecting user secrets from malicious operating systems

while interacting with web applications. Fidelius protects form inputs, JavaScript execution, network con-

nections, and local storage from malware in a fully compromised browser. It also features the first publicly

available system for a trusted I/O path between a user and a hardware enclave without assumptions about

hypervisor security. Our open source implementation of Fidelius, accompanying sample code, and a video

demo are available at https://github.com/SabaEskandarian/Fidelius.

https://github.com/SabaEskandarian/Fidelius

Chapter 3

Express: Lowering the Cost ofMetadata-Hiding Communication

Whereas the previous chapter dealt primarily with protecting private data from risks that reside on users’

local devices, this chapter turns its attention to protecting user secrets as they travel over a network. A

more significant difference is that whereas the previous chapter protected against malicious code installed

without a legitimate user’s knowledge or consent, this chapter will protect against inherent weaknesses in

applications people knowingly and intentionally use all the time. In particular, we will focus on messaging

and on communication systems designed to protect the identities of whistleblowers.

Conventional messaging systems, even end-to-end encrypted ones that hide message contents from the

service provider, leak metadata about who users are talking to. As this information can be just as sensitive as

the message contents themselves, it would be very helpful to have messaging systems that hide users’ iden-

tities too, especially in cases where a user’s identity is very sensitive, e.g., when that user is a whistleblower

trying to contact a journalist. Unfortunately, existing systems for metadata-hiding messaging that provide

cryptographic privacy properties have either high communication costs, high computation costs, or both.

In this chapter, we introduce Express, a metadata-hiding communication system that significantly reduces

both communication and computation costs. Express is a two-server system that provides cryptographic se-

curity against an arbitrary number of malicious clients and one malicious server. In terms of communication,

Express only incurs a constant-factor overhead per message sent regardless of the number of users, whereas

previous cryptographically-secure systems Pung [9] and Riposte [50] had communication costs proportional

to roughly the square root of the number of users. In terms of computation, Express only uses symmetric key

cryptographic primitives and makes both practical and asymptotic improvements on protocols employed by

prior work. These improvements enable Express to increase message throughput, reduce latency, and con-

sume over 100× less bandwidth than Pung and Riposte, dropping the end to end cost of running a realistic

whistleblowing application by 6×.

35

CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 36

3.1 Introduction

Secure messaging apps and TLS protect the confidentiality of data in transit. However, transport-layer en-

cryption does little to protect sensitive communications metadata, which can include the time of a com-

munications session, the identities of the communicating parties, and the amount of data exchanged. As a

result, state-sponsored intelligence gathering and surveillance programs [47, 57, 80], particularly those tar-

geted at journalists and dissidents [128, 153], continue to thrive – even in strong democracies like the United

States [12, 13]. Anonymity systems such as Tor [62], or the whistleblowing tool SecureDrop [24, 147], at-

tempt to hide communications metadata, but they are vulnerable to traffic analysis if an adversary controls

certain key points in the network [61, 84, 88].

A host of systems can hide metadata with cryptographic security guarantees (e.g., Riposte [50], Talek [45],

P3 [91], Pung [9], Riffle [97], Atom [96], XRD [98]). Unfortunately, these systems generally use heavy

public-key cryptographic tools and incur high communication costs, making them difficult to deploy in prac-

tice. Another class of systems provides a differential privacy security guarantee (e.g., Vuvuzela [155], Alpen-

horn [102], Stadium [152], Karaoke [101]). These systems offer high throughput and very low communica-

tion costs, but their security guarantees degrade with each round of communication, making them unsuitable

for communication infrastructure that must operate over a long period of time.

This chapter presents Express, a metadata-hiding communication system with cryptographic security that

makes both practical and asymptotic improvements over prior work. Express is a two-server system that

provides cryptographic security against an arbitrary number of malicious clients and up to one malicious

server. This security guarantee falls between that of Riposte [50], which provides security against at most

one malicious server out of three total, and Pung [9], which can provide security even in the single-server

setting where the server is malicious. Express only uses lightweight symmetric cryptographic primitives and

introduces new protocols which allow it to improve throughput, reduce latency, consume over 100× less

bandwidth, and cost 6× less to operate compared to these prior works.

Express architecture. To receive messages via Express, a client registers mailboxes with the servers, who

collectively maintain the contents of all the mailboxes. After registration, the mailbox owner distributes

the address of a mailbox (i.e., a cryptographic identifier) to each communication peer via some out-of-band

means. Given the address of a mailbox, any client can use Express to upload a message into that mailbox,

without revealing to anyone except the mailbox owner which mailbox the client wrote into. Mailbox owners

can fetch the contents of their mailboxes at any time with any frequency they wish, and only the owner of a

mailbox can fetch its contents.

Crucially, Express hides which client wrote into which mailbox but does not hide which client read from

which mailbox. This requires mailbox owners to check their mailboxes at a fixed frequency, although there

need not be any synchronization between the rates that different owners access their mailboxes. As we will

discuss, this form of metadata privacy fits well with our main application: whistleblowing.

Technical overview. We now sketch the technical ideas behind the design of Express. As in prior work [50],


Express servers hold a table of mailboxes secret-shared across two servers; clients use a cryptographic tool

called a distributed point function [74] to write messages into a mailbox without the servers learning which

mailbox a client wrote into [50, 123]. This basic approach to private writing leaves two important problems

unsolved: handling read access to mailboxes and dealing with denial of service attacks from malicious users.

The first contribution of Express is to allow mailbox reads and writes to be asynchronous. This allows

Express clients to contact the system with any frequency they like, regardless of other clients’ behavior. In

contrast, prior systems such as Riposte, Pung, and Vuvuzela [9, 50, 155] require every client to write before

any client can read, so the whole system is forced to operate in synchronized rounds. We are able to allow

read/write interleaving in Express with a careful combination of encryption and rerandomization. At a high

level: any client in Express can read from any mailbox, but each read returns a fresh re-randomized encryption

of the mailbox contents that only the mailbox owner can decrypt. In this way, even if an adversary reads the

contents of all mailboxes between every pair of client writes, the adversary learns nothing about which honest

client is communicating with which honest client.

The second major challenge for messaging systems based on secret sharing [42, 49–51, 53, 163] is to

protect against malicious clients, who may corrupt the functioning of the system by submitting malformed

messages. Since no server has a complete view of the message being written by each client, servers can-

not immediately tell if a message is well-formed, e.g., whether it modifies only one mailbox or overwrites

the contents of many mailboxes with garbage, destroying real messages that may have been placed in them.

Express protects against such denial-of-service attacks using a new auditing protocol. In a system with n

mailboxes, Express’s auditing protocol requires only O(λ) communication between parties, for a fixed se-

curity parameter λ, as well as O(1) client side computation (in terms of AES evaluations and finite field

operations). The analogous scheme in Riposte required Ω(λ√n) communication and Ω(

√n) client computa-

tion [50], and additionally required a third non-colluding server. In practice, our new auditing scheme reduces

overall computation costs for the client by 8× for a deployment with one million registered mailboxes.

In addition to defending against malformed messages aimed at corrupting the whole database of mail-

boxes, Express must protect against targeted attacks. A malicious client could potentially send a correctly-

formed message containing random content to a single mailbox in hopes of overwriting any content written to

that mailbox by an honest client. We defend against this by assigning virtual addresses to each mailbox. Each

mailbox is accessed via a 128-bit virtual address, regardless of the actual number of mailboxes registered. The

servers store and compute only over the number of actually registered mailboxes, not the number of virtual

mailboxes. However, since virtual addresses are distributed at random over an exponentially large address

space, a malicious client cannot write to a mailbox unless it knows the corresponding address. Section 3.4

describes our protections against malicious clients in detail.

Evaluation application. We evaluate Express as a system for whistleblowers to send messages to journal-

ists while hiding their communications metadata from network surveillance. In this application, a journalist

registers a mailbox for each source from which she wishes to receive information. The journalist then com-

municates her mailbox address to the source via, for example, a one-time in-person meeting. Thereafter, the


source can privately send messages to the journalist by dropping them off in the journalist’s Express mailbox.

In this way, we can implement a cryptographically metadata-hiding variant of the SecureDrop system [24].

To provide whistleblowers with any reasonable guarantee of privacy, Express must provide its users with

a degree of plausible deniability in the form of cover traffic. Otherwise, merely contacting the Express

servers would automatically incriminate clients. As we will demonstrate, Express’s low client computation

and communication costs mean that an Express client implemented in JavaScript and embedded in a web

page can generate copious cover traffic. Browsers that visit a cooperative news site’s home page can opt-in to

generate cover traffic for the system by running a JavaScript client in the backgound – thereby increasing the

anonymity set enjoyed by clients using Express to whistleblow – without negatively impacting end-users’ web

browsing experience. We discuss this and other considerations involved in using Express for whistleblowing,

e.g., how a journalist can communicate a mailbox address to a source, in Section 3.6.

We implement Express and evaluate its performance on message sizes of up to 32KB, larger than is used

in the evaluations of Pung [9], Riposte [50] and Vuvuzela [155]. Recent high-profile whistleblowing events

such as the whistleblower’s report to the US intelligence community’s inspector general [11] (25.3KB) or last

year’s anonymous New York Times op-ed [10] (9KB) demonstrate that messages of this length are very rel-

evant to the whistleblowing scenario. We also compare Express’s performance to Pung [9] and Riposte [50],

finding that Express matches or exceeds their performance, and conclude that Express reduces the dollar

cost of running a metadata-hiding whistleblowing service by 6× compared to prior work (see Figure 3.7).

On the client side, Express’s computation and communication cost are both independent of the number of

users, at about 20ms client computation and 5KB communication overhead per message, enabling our new

strategies for efficiently generating cover traffic. This represents over 100× bandwidth savings compared to

Riposte [50] and over 7, 000× savings compared to Pung for one million users. Although Vuvuzela operates

under a very different security model, we compare the two systems qualitatively in our full evaluation, which

appears in Section 3.7.

In summary, we make the following contributions:

• The design and security analysis of Express, a metadata-hiding communication system that signifi-

cantly reduces both communication and computation costs compared to prior work.

• A new auditing protocol to blindly detect malformed messages that is both asymptotically and practi-

cally more efficient than that of Riposte [50] while also removing the need for a third server to perform

audits.

• An implementation and evaluation of Express that demonstrates the feasibility of our approach to

metadata-hiding whistleblowing. Our open-source implementation of Express is available online at:

https://github.com/SabaEskandarian/Express.

https://github.com/SabaEskandarian/Express


3.2 Design Goals

This section introduces the architecture of Express and describes our security goals.

An Express deployment consists of two servers that collectively maintain a set of locked mailboxes. Each

locked mailbox implements a private channel through which one client can send messages to another who

has the secret cryptographic key to unlock that mailbox.

To use Express, a client wishing to receive messages first registers a mailbox and gets a mailbox address.

From then on, any client who has been given the mailbox address can write messages to that mailbox, and

the owner of that mailbox can check the mailbox for messages whenever it wants. We discuss how clients

can communicate mailbox addresses to each other via a dialing protocol in Section 3.6.2.

We consider an attacker who controls one of the two Express servers, any number of Express clients, and

the entire network. The main security property we demand is that, after an honest client writes a message

into a mailbox, the attacker learns nothing about which mailbox the client wrote into. This corresponds to

an anonymity guarantee where the sender of a given message cannot be distinguished among the set of all

senders in a given time interval. We also require that an attacker who controls any number of malicious

clients cannot prevent honest clients from communicating with each other. In other words, we protect against

malicious clients mounting in-protocol denial-of-service attacks. We do not aim to protect against DoS

attacks by malicous servers, nor against network-level DoS attacks, but we will describe how clients can

incorporate straightforward checks to detect tampering by malicious servers.

3.2.1 Express API

Express allows clients to register mailboxes, read the contents of mailboxes they register, and privately write

to others’ mailboxes. Clients interact with the servers via the following operations:

Mailbox registration. A client registers a new mailbox by sending the Express servers distinct mailbox keys.

The servers respond with a mailbox address. We say that a client “owns” a given mailbox if it holds the

mailbox’s keys and address.

Mailbox read. To read from a mailbox, the client sends the mailbox’s address to the Express servers. The

servers respond with the locked (i.e., encrypted) mailbox contents, which the client can decrypt using its two

mailbox keys together.

Mailbox write. To write to a mailbox, a client sends a specially-encoded write request to the Express servers

that contains an encoding of both the address of the destination mailbox and the message to write into it. No

single Express server can learn either the destination address or message from the write request.

3.2.2 Security Goals

Based on the demands of our application to whistleblowing, Express primarily aims to provide privacy guar-

antees for writes and not for reads. For example, Express hides who whistleblowers send messages to, but


it does not hide the fact that journalists check their mailboxes. Below we describe Express’s core security

properties, which we formalize when proving security in Section 3.10.

Metadata-hiding. We wish to hide who a given client is writing to from everyone except the recipient of

that client’s messages. To this end, our metadata-hiding security guarantee requires that for each write into

an Express mailbox, no adversary who controls arbitrarily many clients and one server can determine which

mailbox that write targeted unless the adversary owns the target mailbox.

We formalize this requirement in Section 3.10, where we show that an adversary can simulate its view

of honest clients’ requests before seeing them, which proves that the adversary learns nothing from requests

that it can’t generate on its own, except necessary information such as the time the write occurred and which

client initiated it. In particular, this means the adversary does not learn the mailbox into which a request

writes, although it does learn that a write has occurred. A malicious server can stop responding to requests or

corrupt the contents of users’ mailboxes, but we require that even an actively malicious server cannot break

our metadata-hiding property.

Soundness. Express must be resilient to malformed messages sent by malicious clients. This means no client

can write to a mailbox it has not been authorized to access, even if it deviates arbitrarily from our protocol.

We capture this requirement via a soundness game in Section 3.10, where we also prove that no adversary

can win the soundness game in Express with greater than negligible probability in a security parameter.

3.2.3 Design Approaches

As there are many potential approaches to metadata-hiding systems, we now briefly sketch high-level deci-

sions made regarding the goals of Express.

Deployment scenario. Express’s primary deployment scenario is as a system for whistleblowing, where a

source leaks a document or tip to a journalist. In this setting, unlike prior work, Express does not require the

system to run in synchronous rounds. This is the deployment scenario on which we will focus the exposition

of the Express system. However, since this is a one-directional communication setting (the source can send

leaks to the journalist but not have an ongoing conversation), Express can also be used as a standard messaging

protocol where clients, e.g., sources and journalists, send messages back and forth to each other. In this

setting, similar to prior work, messaging in Express would progress in time epochs, with a server-determined

duration for each round.

Differential vs cryptographic privacy. Express belongs to a family of systems that provide cryptographic

security guarantees. In contrast, a number of systems (e.g., Vuvuzela, Stadium, Karaoke [101, 152, 155])

provide differentially private security. The difference between the two types of systems lies in the amount of

private metadata the systems leak to an adversary. Cryptographic security means that no information leaks

– the adversary learns nothing, even after observing many rounds of communication, about which clients

are communicating with each other. In contrast, systems providing the differential privacy notion of security

allow some quantifiable leakage of metadata. Thus, with differential privacy-based systems, an attacker can –


after a number of communication rounds – learn who is communicating. In contrast, the security of Express

does not degrade, even after many rounds of interaction. Thus, although differentially private systems offer

faster performance, cryptographic security is preferable for frequently used privacy-critical applications.

Distributing trust. There are two potential approaches to deployment of metadata-hiding systems. One

approach envisions a grass-roots deployment model where large numbers of people or organizations decide

to participate to run the system, and trust is distributed among the servers with tolerance for some fraction

behaving maliciously. The approach taken by Express (and the works to which we primarily compare it [9,

50]) envisions a commercial infrastructure setting where only a small number of participants (e.g., for our

example use case, the Wall Street Journal and the Washington Post) are needed to deploy the system with

its full security guarantees. Given equal performance and security against an equal fraction of malicious

servers, it is of course preferable to distribute trust over a larger number of parties. Thus designs that split

trust between a small number of parties can be seen as one point on a tradeoff between having many parties

that undergo some light vetting versus having few parties that undergo heavier vetting before being included

as servers in the system.

3.2.4 Limitations

We now discuss some limitations of Express to aid in determining which scenarios are best-suited to an

Express deployment.

The most important limitation to consider when deciding whether to deploy Express is the issue of cen-

sorship. As mentioned above, Express relies on distributing trust among two servers. Thus, if traffic to either

server is blocked, the system can no longer be accessed. Since we envision Express being deployed by major

news organizations, Express would not be appropriate for use in countries with a history of blocking traffic

to such organizations. This is true of any system that distributes trust over a small number of servers (or has

easily identifiable traffic). However, there is a need to prevent surveillance even in countries with relatively

open access to the internet. It is in this setting that Express can be an effective approach to metadata-hiding

communication.

Express allows mailbox owners to access their mailboxes and retrieve messages with whatever frequency

they desire when being used for one-way communication, but they must check mailboxes at regular intervals

in order to maintain security because Express does not hide which mailbox a given read accesses. If a

mailbox owner changes her mailbox-checking pattern based on the contents of messages received, this may

leak something about who is sending her messages. Note that although this implies that mailbox owners

should regularly check their mailboxes, it does not impose any restrictions on the frequency with which any

owner checks her mailboxes – it is not a fixed frequency required by the system and can be different for

each mailbox owner. This is in contrast with prior works, which fix a system-wide frequency with which

clients must contact the servers or require clients to always remain online. Clients sending messages through

Express but not also receiving messages (e.g., whistleblowers sending tips or documents) do not need to

regularly contact the system.


Another reason for mailbox owners to check their mailboxes regularly is that messages in Express are

written into mailboxes by adding, not concatenating, the message contents to the previous contents of the

mailbox. It is thus possible for a second message sent to the same mailbox to overwrite the original contents,

causing the content to be clobbered when someone eventually reads it. This risk can be easily mitigated,

however, because each mailbox is for one client to send messages to one other client, and servers zero-out the

contents of mailboxes after they are read to make space for new messages. Looking ahead to our application,

messages can be a leak of a single document, where more than one message is not required. If a journalist

expects to receive many messages from the same source before she has a chance to read and empty the

contents of a mailbox, one way to handle this situation is to register several mailboxes for the same source,

so each message can be sent to a different mailbox. This way, as long as a journalist checks and empties her

mailboxes before they have all been used, no messages will be overwritten.

While Express’s soundness property prevents in-protocol denial of service attacks by malicious clients, a

malicious Express server can launch a denial of service attack by overwriting mailboxes with garbage. This

attack will prevent communication through Express, but it can at least be detected. We discuss how clients

can add integrity checks to their messages to achieve authenticated encryption over Express in Section 3.5.

This means that a client receiving a garbage message will know that the message has been corrupted by a

malicious server.

Finally, like all systems providing powerful metadata-hiding guarantees, Express must make use of cover

traffic to hide information about which users are really communicating via Express. Although necessary,

cover traffic allows metadata-hiding systems to protect even against adversaries with strong background

knowledge about who might be communicating with whom by providing plausible deniability to clients

sending messages through Express. We further discuss cover traffic in Section 3.6.1.

3.3 Express Architecture

This section describes the basic architecture of Express. Section 3.4 shows how to add defenses to protect

against disruptive clients, and Section 3.5 states the full Express protocol. Section 3.6 discusses how to use

Express for whistleblowing, including how a mailbox owner communicates a mailbox address to senders and

how to increase the number of Express users by deploying it on the web.

The starting point for Express is a technique for privately writing into mailboxes using distributed point

functions [50, 74, 123]. We review how DPFs can be used for private writing in Section 3.3.1. A private

writing mechanism alone, however, does not suffice to allow metadata-hiding communication. We must also

have a mechanism to handle access control so that only the mailbox owner can access the contents of a

given mailbox. We discuss a lightweight cryptographic access control system in Section 3.3.2, where we

also explain how this combination of private writing and controlled reading enables metadata hiding without

synchronized rounds.


3.3.1 Review: Private Writing with DPFs

We briefly review the technique used in Riposte [50] for allowing a client to privately write into a database,

stored in secret-shared form, at a set of servers.

A naıve approach. In Express, two servers – servers A and B – collectively hold the contents of a set of

mailboxes. In particular, if there are n mailboxes in the system and each mailbox holds an element of a finite

field F, then we can write the contents of all mailboxes in the system as a vector D ∈ Fn. Each server holds

an additive secret share of the vectorD: that is, serverA holds a vectorDA ∈ Fn and serverB holds a vector

DB ∈ Fn such that D = DA +DB ∈ Fn.Once a client registers a mailbox, another client with that mailbox’s address can send messages or doc-

uments to the mailbox, which the mailbox owner can check at his or her convenience. Although Express

can support mailboxes of different sizes, size information can be used to trace a message from its sender to

its receiver, so Express clients must pad messages, either all to the same size or to one of a few pre-set size

options.

To write a message m ∈ F into the i-th mailbox naıvely, the Express client could prepare a vector

m · ei ∈ Fn, where ei is the ith standard-basis vector (i.e., the all-zeros vector in Fn with a one in coordinate

i). The client would then split this vector into two additive shares wA and wB such that wA + wB = m · ei,and send one of each of these “write-request” vectors to each of the two servers. The servers then process the

write by setting:

DA ← DA + wA ∈ Fn DB ← DB + wB ∈ Fn,

which has the effect of adding the value m ∈ F into the contents of the ith mailbox in the system.

The communication cost of this naıve approach is large: updating a single mailbox requires the client to

send n field elements to each server.

Improving efficiency via DPFs. Instead of sending such a large message, the client uses distributed point

functions (DPFs) [33,34,74] to compress these vectors. DPFs allow a client to split a point function f , in this

case a function mapping indices in the client’s vector to their respective values, into two function shares fAand fB which individually reveal nothing about f , but whose sum at any point is the corresponding value of

f . More formally, let fi∗,m : [N ] → F be a point function that evaluates to 0 at every point i ∈ [N ] except

that f(i∗) = m ∈ F. A DPF allows a client holding fi∗,m to generate shares fA and fB : [N ]→ F such that:

(i) an attacker who sees only one of the two shares learns nothing about i∗ or m, and

(ii) for all i ∈ [N ], fi∗,m(i) = fA(i) + fB(i) ∈ F.

Moreover, in addition to supporting messages m ∈ F, the latest generation of DPFs [34] allow for any

message m ∈ 0, 1∗. When using these DPFs with security parameter λ, each function share (fA and fB)

has bitlength O(λ logN + |m|). In addition to general improvements in efficiency over prior DPFs, our

choice of DPF scheme will enable new techniques that we introduce in Section 3.4.

In essence, the client can use DPFs to compress the vectorswA andwB , which reduces the communication

cost to O(λ · logN + log |F|) bits, when instantiated with a pseudorandom function [76] using λ-bit keys.


Upon receiving fA and fB the servers can evaluate them at each point i ∈ [n] to recover the vectors wA and

wB and update DA and DB as before.

3.3.2 Hiding Metadata without Synchronized Rounds

Private writing alone does not suffice to provide metadata-hiding privacy. In order to achieve this, we also

need to control read access to mailboxes. Otherwise, a network adversary who controls a single client could

read the contents of all mailboxes between each pair of writes and learn which client’s message modified

which mailbox contents, even if messages are encrypted. Prior works such as Pung [9] or Riposte [50]

prevent this attack by operating in batched rounds in which many clients write messages before any client is

allowed to read. The key feature that allows Express to hide metadata without relying on synchronized rounds

is that a message can only be read by the mailbox owner to whom it is sent. Express can make messages

available to mailbox owners immediately as long as (1) the messages remain inaccessible to an attacker who

does not own the mailbox whose contents have been modified and (2) the attacker cannot tell which mailbox

has been modified if it does not own the modified mailbox. Thus, all we need to successfully hide metadata

without rounds is a mechanism for access control that satisfies these two requirements. While an adversary

who continuously reads from all mailboxes could then still learn when a write occurs, it would learn nothing

about which mailbox contents were modified as a result.

Express includes a lightweight cryptographic approach to access control that relies on symmetric en-

cryption, does not require the servers to undertake any user authentication logic when serving read requests,

and enables useful implementation optimizations. A client registering a mailbox uploads keys kA and kB to

servers A and B respectively, and the servers encrypt stored data using the respective key for each mailbox,

decrypting before making modifications and re-encrypting after. The re-encryption ensures that the contents

of every mailbox are rerandomized after each write, so an attacker attempting to read the contents of a mail-

box for which it does not have both keys learns nothing from reading the encrypted contents of the mailbox,

including whether or not those contents have changed. This property still holds even if only one of the two

servers carries out the re-encryption, so its security is unaffected if a malicious server does not encrypt or re-

encrypt mailboxes. Our implementation encrypts mailbox contents in counter mode, so re-encryption simply

involves subtracting the encryption of the previous count and adding in the new one. Since these operations

are commutative, we can implement an optimization where re-encryption is not done on every write but only

when a read occurs after one or more writes. This makes our approach – which requires only symmetric en-

cryption – more efficient than a straightforward one based on public key encryption, e.g., where the contents

of each mailbox are encrypted under the owner’s public key when a read is requested.

3.4 Protecting Against Malicious Clients

The techniques in Section 3.3 suffice to provide privacy if all clients behave honestly, but they are vulnerable

to disruption by a malicious client. In the scheme described thus far, one malicious client can corrupt the


state of the two servers with a single message. To do so, the malicious client sends DPF shares fA and fB to

the servers that expand into vectors wA and wB such that wA + wB = v ∈ Fn, where v is non-zero at many

(or even all) coordinates. A client who submits such DPF key shares can, with one message to the servers,

write into every mailbox in the system, corrupting whatever actual messages each mailbox may have held.

Express protects against this attack with an auditing protocol that checks to make sure (wA + wB) ∈Fn is a vector with at most one non-zero component. In other words, the servers check that each write

request updates only a single mailbox. Any write request that fails this check can be discarded to prevent

it form corrupting the contents of DA and DB . Riposte [50], a prior work that also audits DPFs to protect

against malicious clients, uses a three-server auditing protocol that requires communication Ω(λ√n) and

client computation Ω(√n) for a system with n mailboxes, where λ is a security parameter. However, their

protocol takes advantage of the structure of a particular DPF construction that is less efficient than the one

used by Express. Applying their protocol to the more efficient DPFs used in Express would require client

communication and computation Ω(λn) and Ω(n) respectively as well as the introduction of an additional

non-colluding server. This linear bandwidth consumption per write would create a communication bottleneck

in Express and increase client-side computation costs significantly. Moreover, adding a third server – and

requiring that two out of three servers remain honest to guarantee security – would dramatically reduce the

practicality of the Express system. To resolve this issue, we introduce a new auditing protocol that drops

client computation (in terms of AES evaluations and finite field operations) to O(1) and communication

to O(λ) while simultaneously eliminating the need for a third server to perform audits. We describe our

two-party auditing protocol in Section 3.4.1.

Although auditing ensures that DPFs sent by clients must be well-formed, an attacker targeting Express

has a second avenue to disrupting the system. Instead of attempting to corrupt the entire set of mailboxes –

an attack prevented by the auditing protocol – a malicious client can write random data to only one mailbox

and corrupt any message a source may send to a journalist over that mailbox. Although this attack is easily

detectable when a journalist receives a random message, it still allows for easy disruption of the system and

cannot be blocked by blind auditing because the disruptive message is structured as a legitimate write.

We defend against this kind of targeted disruption with a new application of virtual addressing. At a

high level, we assign each mailbox a unique 128-bit virtual address and modify the system to ensure that

writing into a mailbox requires knowing the mailbox’s virtual address. In this way, a malicious user cannot

corrupt the contents of an honest user’s mailbox, since the malicious user will not be able to guess the honest

user’s virtual address. We discuss this defense and its implications for other components of the system in

Section 3.4.2.

3.4.1 Auditing to Prevent Disruption

This section describes our auditing protocol. We begin with a rough outline of the protocol before stating the

security properties required of it and then explaining the protocol in full detail. At a high level, our auditing


protocol combines the verifiable DPF protocol of Boyle et al. [34], which only provides security against semi-

honest servers, with secret-shared non-interactive proofs (SNIPs) first introduced by the Prio system [49] (and

later improved and generalized by Boneh et al. [26]) to achieve security against fully malicious servers. We

explain each of these ideas and how we combine them below.

Let the vectors wA and wB ∈ Fn be the outputs that servers A and B recover after evaluating fA(i),

fB(i), for i ∈ [n]. Note that even DPFs that output a message in 0, 1∗ begin with an element of a λ-bit

field F and expand it, so for the purposes of our auditing protocol, we can assume that every DPF output is

an element of F. We say that w = wA + wB ∈ Fn is a valid write-request vector if it is a vector in Fn of

Hamming-weight at most one. The goal of the auditing protocol is to determine whether a given write-request

vector is valid.

The observation of Boyle et al. [34] is that the following n-variate polynomial equals zero with high

probability over the random choices of r1, ..., rn if and only if (1) there is at most one nonzero wi and (2)

m = wi for the nonzero value of wi

f(r1, ..., rn) = (Σi∈[n]wiri)2 −m · (Σi∈[n]wir

2i ).

This polynomial roughly corresponds to taking a random linear combination of the elements of w – using

randomness shared between the two servers – and checking that the square of the linear combination and the

sum of the terms of the linear combination squared are the same. Using the fact that it is easy to compute

linear functions on secret-shared data, the two sums in the equation above can be computed non-interactively

by servers A and B. Boyle et al. suggest using a multiparty computation between the servers to compute the

remaining multiplications and check whether this polynomial in fact equals zero, thus determining whether

the DPF is valid.

The problem with this approach is that it is only secure against semi-honest servers. A malicious server

can deviate from the protocol and potentially learn which entry of w is non-zero. For example, suppose a

malicious server A is interested in knowing whether a write request modifies an index i∗. It runs the auditing

protocol as described, but it replaces its value wAi∗ with a randomly chosen value w′Ai∗ . If wAi∗+wBi∗ = 0,

i.e., i∗ was not the nonzero index of w, this modification will cause the audit to fail because the vector w′

that includes w′Ai∗ instead of wAi∗ no longer has hamming weight one. Thus the malicious server learns that

the write request would not have modified index i∗. On the other hand, if wAi∗ + wBi∗ 6= 0, i.e., i∗ was the

nonzero index of w, the inclusion of w′Ai∗ still results in a vector w′ of hamming weight one, and the auditing

protocol passes. Thus the malicious server can detect whether or not the write request modifies index i∗ by

observing whether or not auditing was successful after it tampers with its inputs.

To prevent this attack we make use of a SNIP proof system [26, 49]. In a SNIP, a client sends each

server a share of an input w and an arithmetic circuit Verify(). The client then uses a SNIP proof to convince

the servers, who only hold shares of w but may communicate with each other, that Verify(w) = 1. An

important property of a SNIP proof system is that it provides security against malicious servers. That is,

even a server who deviates from the protocol cannot abuse a SNIP to learn more about w. SNIP proofs


require computation and communication linear in the number of multiplications between secret values in the

statement being proved. Our approach is to instantiate the DPF verification protocol of Boyle et al. [34] inside

of a SNIP to protect it from potentially malicious servers. Since the Boyle et al. verification protocol only

requires two multiplications between shared values, the squaring and the multiplication by m, this results in

a constant-sized SNIP (i.e. size O(λ)).

Properties of auditing protocol. Before describing our protocol in detail, we recall the completeness, sound-

ness, and zero-knowledge properties we require of the auditing protocol (adapted from those of Riposte’s

auditing protocol [50]).

• Completeness. If all parties are honest, the audit always accepts.

• Soundness against malicious clients. If w is not a valid write request (i.e., the client is malicious) and

both servers are honest, then the audit will reject with overwhelming probability.

• Zero knowledge against malicious server. Informally: as long as the client is honest, an active attacker

controlling at most one server learns nothing about the write request w, apart from the fact that it is valid.

That is, for any malicious server there exists an efficient algorithm that simulates the view of the protocol

execution with an honest second server and an honest client. The simulator takes as input only the public

system parameters and the identity of the malicious server.

Our auditing protocol. Our auditing protocol proceeds as follows. We assume that data servers A and B

share a private stream of random bits generated from a pseudorandom generator with a seed r. In practice, the

servers generate the random seed by agreeing on a shared secret at setup and using a pseudorandom generator

to get a new seed for each execution of this protocol. We will describe the protocol using a SNIP as a black

box and give details on how to instantiate the SNIP in Section 3.11.

At the start of the protocol, server A holds r and wA ∈ Fn and server B holds r and wB ∈ Fn, both

generated by evaluating the DPF shares sent by the client at each registered mailbox address. The client holds

the index i∗ at which w is non-zero as well as the values of wA and wB at index i∗, which it computes from

the function shares fA and fB that it sent to the servers.

1. Servers derive proof inputs.

The servers begin by sending the random seed r used to generate their shared randomness to the client.

Next, they compute shares mA and mB of m, the value of w at its non-zero entry, which is simply the

sum of all the elements of wA or wB respectively because all but one entry of w should be zero. That

is, the servers compute

mA ← Σi∈[n]wAi and mB ← Σi∈[n]wBi.

Then serversA andB use their shared randomness r to generate a random vector r = (r1, ..., rn) ∈ Fn

and then compute the vector of squares R = (r21, ..., r

2n) ∈ Fn. After this, they compute shares of the


“check” values c = 〈w, r〉 and C = 〈w,R〉:

cA ← 〈wA, r〉 ∈ F, CA ← 〈wA, R〉 ∈ F

cB ← 〈wB , r〉 ∈ F, CB ← 〈wB , R〉 ∈ F

Here the notation 〈x, y〉 represents the inner product between vectors x, y ∈ Fn, defined as Σni=1xiyi.

At this point, the servers hold values mA, cA, CA and mB , cB , CB respectively.

2. Client derives proof inputs.

Since the client knows the seed r, the index i∗, and the values of wA and wB at index i∗ (and as a

consequence the value of m = wAi∗ + wBi∗ ∈ F), the client can compute the random values r∗, r∗2

that will be multiplied by the i∗th entries of wA and wB . Since all the values other than the i∗th

entry of w are zero, the client need not compute them. Thus the client computes the check values

c∗ = r∗ · (wAi∗ + ·wBi∗) and C∗ = r∗2 · (wAi∗ + ·wBi∗). Note that this allows the client to compute

the check values in only O(1) time even though the servers must do O(n) work to find them.

3. Proof computation and verification.

To complete the proof, the client prepares a SNIP proof π = (πA, πB), sends πA to server A, and

sends πB to server B. The servers then verify the proof, communicating with each other as needed.

The SNIP proves that

c2 −m · C = 0

where c← cA + cB and C ← CA + CB .

The soundness property of the SNIP proof guarantees that the servers will only accept the proof if the

statement is true, and the zero-knowledge property of the proof guarantees that as long as one server is

honest, the servers learn nothing from receiving the SNIP proof that they did not know before receiving

it (even if one server is fully malicious). Note that this statement only involves two multiplications:

c · c and m · C.

We sketch the instantiation of the proofs used in our auditing protocol as well as the security analysis of

the full auditing protocol in Section 3.11. Full details and a security proof for the SNIP proof system itself

can be found in the Prio paper [49] and the follow-up work of Boneh et al. [26].

3.4.2 Preventing Targeted Disruption

We now describe how Express prevents a targeted attack where a malicious client writes random data to a

single mailbox to corrupt its contents. Express servers assign each mailbox a 128-bit virtual address and

ensure that a client can only write to a mailbox if it knows the corresponding virtual address.


To implement this, the Express servers maintain an array of n physical mailboxes, but they also maintain

an array of 2λ virtual mailboxes, where λ ≈ 128 is a security parameter. The two data servers assign a

unique virtual address to each physical mailbox, and they collectively maintain a mapping – a page table –

that maps each active virtual address to a physical mailbox. Since the virtual addressing scheme’s only goal

is to prevent misbehavior by malicious clients, the servers both hold the contents of the page table (i.e., the

list of active virtual addresses and their mapping to physical addresses) in the clear. The virtual-address space

(around 2128 entries) is vastly larger than the number of physical mailboxes (around 220, perhaps), so the vast

majority of the virtual-address space goes unused.

When a client registers a new mailbox, the servers both allocate storage for a new physical mailbox, assign

a new random virtual address to this physical mailbox, and update their page tables. The address can either be

chosen by one server and sent to the other or generated separately by each server using shared randomness.

The servers then return the virtual and physical addresses for the mailbox to the client. As mentioned above,

a mailbox owner must communicate its address to others to receive messages. We describe how this can be

achieved when we discuss dialing in Section 3.6.2. The contents of the tables stored at the servers are shown

in Figure 3.1.

When preparing a write request, the client prepares DPF shares fA and fB : 2λ → F as if it were going

to write in to the exponentially large address space. However, instead of evaluating shares at every i ∈ [2λ],

the Express servers only evaluate fA and fB at the currently active virtual addresses. In this way, the number

of DPF evaluations the servers compute remains linear in the number of registered mailboxes, even though

clients send write requests as if the address space were exponentially large. A client who does not know the

address for a given mailbox has a chance negligible in λ of guessing the correct virtual address. Note that

this technique is only possible because Express uses a DPF whose share sizes are logarithmic in the function

domain size. Using virtual addresses with older square-root DPFs would result in infeasibly large message

sizes and computation costs.

Although virtual addressing, when combined with auditing, does fully resolve the issue of disruptive

writes, it does not fully abstract away physical addresses. Our auditing protocol critically relies on the client

knowing the index of the mailbox it wants to write to among the set of all mailboxes. As such, a client

preparing to send a message must be informed of both the virtual and physical addresses of the mailbox it

wishes to write to. Fortunately, the size of a physical address is much smaller than that of a virtual address

(about 20 bits compared to 128 bits for a virtual address), so communicating both addresses at once adds little

cost to only sending the virtual address.

3.5 Full Express Protocol

This section summarizes the full Express protocol described incrementally in Sections 3.3 and 3.4. We will

describe the protocol in full but refer to the steps of the auditing protocol as described in Section 3.4.1 to

avoid repeating the protocol spelled out in detail there. We prove security in Section 3.10. After describing


Data

0

0

Hi!

0

Virtual Addr.

Phys. Addr.

Key Data

0010...1010 0 kA0 abc

0101...1100 1 kA1 xf$

0111...0011 2 kA2 !7≈

1001...0111 3 kA3 ^tg

+Virtual Addr.

Phys. Addr.

Key Data

0010...1010 0 kB0 abc

0101...1100 1 kB1 xf$

0111...0011 2 kB2 2!)

1001...0111 3 kB3 ^tg

Server A

Server B

128 bits 128 bitslogN bits Data size

Figure 3.1: Contents of the tables held by servers in Express. Each server stores the conversion from virtual to physicaladdresses and a distinct key for each mailbox. Combining data from the two servers allows a user holding both keys fora given mailbox to read its contents.

the protocol, we describe how clients can add message integrity to their Express messages.

We assume that a mailbox owner has already set up a mailbox with virtual address v and physical address

p and communicated (p, v) to another client. We discuss options for communicating p and v to other clients

(“dialing”) in Section 3.6.2. We also assume that the mailbox owner holds mailbox keys kA and kB , which it

has sent to servers A and B respectively, and the client has a message m that it wants to send. Server A holds

vectors V of virtual addresses, KA of keys, and DA of mailbox contents, each of length n. Server B likewise

holds V , KB and DB . Each entry of DA and DB is encrypted in counter mode under the corresponding key

in KA or KB . Figure 3.1 shows the information held by servers A and B for each mailbox.

Sending a message.

1. The client generates DPF shares fA and fB of the point function fv,m : [2λ]→ 0, 1|m|. It sends fAto A and fB to B.

2. A andB evaluatewA ← (fA(V1), ..., fA(Vn)) andwB ← (fB(V1), ..., fB(Vn)). They use their shared


randomness to generate a seed r to be used in the auditing protocol, send it to the client, and prepare

the server inputs to the SNIP.

3. The client prepares the client inputs to the SNIP and generates the corresponding proof π = (πA, πB).

It sends πA to server A and πB to server B.

4. The servers verify the SNIP proof π, and they abort if the verification fails.

5. Servers A and B decrypt each DAi with KAi and each DBi with key KBi, i ∈ [n]. Next, they set

DAi ← DAi + wAi and DBi ← DBi + wBi before re-encrypting the new values of DAi and DBi

under the same keys (with new nonces).

Checking a mailbox.

1. The mailbox owner sends (p, v) to servers A and B to request to read from the mailbox at physical

address p.

2. Servers A and B check that virtual address v corresponds to physical address p and then send DAp and

DBp as well as the nonce used for the encryption of each value. Then they set the values of DAp and

DBp to fresh encryptions of 0 under KAp and KBp respectively, emptying the mailbox. Since only the

mailbox owner and whoever wrote into a mailbox know p and v, and the virtual address space for v is

huge, clients cannot read or delete the contents of each other’s mailboxes.

3. The mailbox owner decrypts the values of DAp and DBp it received with keys kA and kB to get

messages mAp and mBp. It outputs message m← mAp +mBp.

Complexity. Table 3.1 shows the communication and computational complexity of sending a message in

Express for the client and the servers. We measure computational complexity in terms of AES evaluations and

field operations separately to better capture the computation being carried out by each party. The complexities

reported are the sum of costs due to DPF evaluation, re-encryption, and auditing.

Client communication includes sending a DPF whose shares are functions with domain size 2λ, resulting

in DPFs of size O(λ2 + |m|). As discussed in Section 3.4.1, the auditing protocol involves the client sending

a proof of size O(λ).

Cryptographic costs on the client include generating DPF shares and evaluating the DPF at one point,

both of which cost O(λ + |m|). The server, on the other hand, must evaluate the DPF at each address and

also generate the random vectors needed for the auditing protocol. The number of field operations for each

party come directly from the costs incurred during the auditing protocol.

Message integrity. The core Express protocol does not protect message integrity, so a malicious server

could undetectably corrupt the contents of a mailbox. This can be remedied in a straightforward way by

using MACs. Given that the clients writing to and reading from a mailbox share a secret to establish an

address, they could instead use a master secret to derive (e.g., via a hash) a mailbox address and a MAC key.


Client Servers

Communication O(λ2 + |m|) O(λ)AES Evaluations O(λ+ |m|) O(n(λ+ |m|))Field Operations O(1) O(n)

Table 3.1: Complexity of processing a single write in Express with n mailboxes, message size |m|, and security param-eter λ. Communication measures bits sent only.

Messages written to Express could then be MACed before being split into shares via a DPF. Since a MAC-

then-encrypt approach provides authenticated encryption when the encryption is done in counter mode [29]

(as we do), Express with MACed messages provides authenticated encryption on the messages.

3.6 Using Express for Whistleblowing

Having described the core Express system itself, this section covers two important considerations involved

in using Express for whistleblowing: plausible deniability for whistleblowers and agreeing on mailbox ad-

dresses.

First, in order to provide meaningful security in practice, Express must hide both the recipient of a given

client’s message as well as whether a client is really communicating with a journalist. We discuss how to pro-

vide plausible deniability for Express clients in Section 3.6.1. Second, to set up their communication channel,

a journalist and whistleblower must agree on a mailbox address through which they will communicate. This

can be done either in person or via a dialing protocol as described in Section 3.6.2.

3.6.1 Plausible Deniability

We now turn to the goal of hiding whether or not a client is really communicating with a journalist. If

Express were only to be used by journalists and their sources, it would fundamentally fail to serve its purpose.

Although no observer could determine which journalist a given message was sent to, the mere fact that

someone sent a message using Express reveals that she must be a source for some journalist. In order to

provide plausible deniability to whistleblowers, other, non-whistleblowing users must send messages through

the system as well.

One solution for this problem, first suggested in the Conscript system [52], is to have cooperative web

sites embed Javascript in their pages that generates and submits dummy requests. For example, the New York

Times home page could be modified such that each time a consenting user visits (or for every nth consent-

ing user that visits), Javascript in the page directs the browser to generate a request to a special write-only

Express dummy address that the servers maintain but for which each server generates its own encryption key

not known to any user. Since no user has the keys to unlock this address, messages written to it can never be

retrieved, and Express’s metadata-hiding property guarantees that messages sent to the dummy address are

indistinguishable from real messages sent to journalists. This enables creating a great deal of cover traffic and


gives clients who really are whistleblowers plausible deniability, as long as communication patterns between

users and the Express servers are the same for real and cover traffic. Moreover, only one large organiza-

tion needs to implement this technique for all news organizations who receive messages through Express to

benefit from the cover traffic. The exact quantity of cover traffic required to provide the appropriate level

of protection for whistleblowers using Express is ultimately a subjective decision, but the Express metadata-

hiding guarantee implies that a whistleblower sending a message through Express cannot be distinguished

among the set of all users sending messages through Express, be they real messages or cover messages.

Express is particularly well-suited to this approach for two reasons: aligned incentives and low client

side costs. First, participating news organizations all have web sites and a natural incentive to direct cover

traffic to the Express system. Even if only one or a few organizations among them are willing to risk adding

dummy traffic scripts to their pages, everyone benefits. In fact, even the same organizations who are willing

to host the Express servers could add the dummy scripts to their own news websites to ensure adequate cover

traffic. Second, as demonstrated in Section 3.7, Express’s extremely low client computation and communi-

cation requirements lend themselves particularly well to this approach, since the client can easily run in the

background on a web browser, even in computation or data-restricted settings such as mobile devices. We

empirically evaluate a JavaScript version of the Express client in Section 3.7.2 and find it imposes very little

additional cost on the browser.

Using in-browser JavaScript to give users plausible deniability raises a number of security and ethical

concerns. We defer to the Conscript paper [52] for an extensive discussion of the security and ethical con-

siderations involved and note that it is also possible to generate cover traffic for Express using a standalone

client, as is common in other systems.

3.6.2 Dialing

In order to use Express, a journalist and source must agree on the mailbox address which the source will use

to send messages to the journalist. Journalists who make initial in-person contact with sources could, for

example, distribute business cards with mailbox addresses on them in QR code form.

Journalists and sources could also use a more expensive dialing protocol to share an initial secret before

moving to Express to more efficiently communicate longer or more frequent messages. One approach to

dialing that can conveniently integrate with Express is to use an improved version of the Riposte [50] system

as a dialing protocol. Riposte offers a public broadcast functionality that progresses in fixed time epochs,

where anyone can announce a message to the world. Since journalists can easily post their public keys

online, e.g., next to their name at the bottom of articles they write, anyone wishing to connect with a particular

journalist can send a mailbox address (and perhaps some introductory text) encrypted under that journalist’s

public key with no other identifying information. A client run by a journalist can download all Riposte

messages sent in a day and identify those encrypted under that journalist’s public key. The journalist can then

register any mailbox addresses sent to it and communicate with whoever sent the messages via Express. This

requires mailbox owners (in this case, the journalist) to choose virtual addresses instead of the servers, but


102 103 104 105 106

100

102

104

Number of Mailboxes

Com

mun

icat

ion

[KB

]Server Communication

Pung Riposte Express

Figure 3.2: Server communicationcosts when sending 160 Byte mes-sages, including both data sent andreceived. Riposte also requires anauditing server whose costs are notdepicted.

102 103 104 105 106

100

102

104

Number of MailboxesC

omm

unic

atio

n[K

B]

Client Communication


Figure 3.3: Client communicationcosts when sending 160 Byte mes-sages, including both data sent andreceived. Express requires sig-nificantly less communication thanprior work.

103 104 105 10610−4

10−1

102

Number of Mailboxes

Tim

e[m

s]

Audit Computation

Riposte Server Our ServerRiposte Client Our Client

Riposte Auditor

Figure 3.4: Our auditing protocoldramatically reduces computationcosts for the client while server-side costs remain comparable toprior work, where audit computa-tion time is dwarfed by DPF eval-uation anyway.

the probability of colliding addresses is low because the virtual address space is large. Using this approach

to dialing gives Express users the ability to bootstrap from a single message in a dialing system with fixed-

duration rounds to as many messages as they want in a system which processes messages asynchronously.

Since Riposte has a similar underlying architecture to Express, a number of the techniques used in Express

could be used to make it a more effective dialing protocol. Most importantly, instead of using Riposte’s DPFs

and auditing protocol, which are less efficient and require a third non-colluding server, the dialing protocol

can use a Riposte/Express hybrid approach where the DPF and auditing protocol are those of Express. This

means that the dialing protocol relies on the same trust assumptions as the main protocol, and it can even be

deployed on the same servers.

Integrity in the dialing protocol can be ensured in a way similar to the main protocol as well. Instead of

sending only a mailbox address, clients send a secret from which a mailbox address and MAC key can be

derived, and the encrypted message is then MACed using that key. To ensure that servers can’t tamper with

or erase messages by changing their state after seeing that of the other server, they are required to publish

and send each other commitments to (hashes of) the message shares they hold before publishing the actual

databases of messages.

3.7 Implementation and Evaluation

We implement Express with the underlying cryptographic operations (DPFs, auditing) in C and the higher

level functionality (servers, client) in Go. We use OpenSSL for cryptographic operations in C and base


our DPF implementation in part on libdpf [44], which is in turn based on libfss [156, 157]. We also re-

implemented the client-side computations involved in sending a write request in JavaScript for the whistle-

blowing application, using the SJCL [144, 145] and TweetNaCl.js [3] libraries for crypto operations. We

implement the DPF construction [34] and the auditing protocol using the field Fp of integers modulo the

prime p = 2128 − 159, since these field elements have a convenient representation in two 64-bit words. Our

implementation does not include the client-side integrity checks described in Section 3.5, but these checks

can be added by clients with no impact on server-side code or performance.

We evaluate Express on three Google Cloud instances (two running the servers and a third to simulate

clients) with 16-core intel Xeon processors (Haswell or later) with 64GB of RAM each and 15.6 Gbps band-

width. We run all three in the same datacenter to minimize network latency and focus comparisons to other

systems on computational costs since we begin our evaluation by considering communication separately. We

evaluate the JavaScript implementation of the whistleblowing client on a laptop with an Intel i5-2540M CPU

@ 2.60GHz and 4GB of RAM running Arch Linux and the Chromium web browser. All experiments use

security parameter λ = 128.

We compare Express to Riposte [50] and Pung [9], two prior works that also provide cryptographic

metadata-hiding guarantees, albeit in slightly different settings. We choose to compare to these systems

because, like Express, they also provide cryptographic security guarantees and only rely on a small number

of servers to provide their security guarantees. Riposte requires 3 servers, of which two must be honest (a

stronger trust assumption than Express) whereas Pung requires only a single server which can potentially be

malicious (a weaker trust assumption). We rerun the original implementations of Riposte and Pung on the

same cloud instances used to evaluate Express. Our evaluation results do not distinguish between real and

dummy messages because the two are identical from a performance perspective.

We find that Express reduces communication costs by orders of magnitude compared to Riposte and Pung,

with clients using over 100× less bandwidth than Riposte and over 4000× less bandwidth than Pung when

sending a message in the presence of one million registered mailboxes. On the client implemented in C/Go,

Express requires 20ms of computation to send a write request, even in the presence of one million registered

mailboxes, and our JavaScript client performs similarly, requiring 51ms for the same task.

We compare the performance of our auditing protocol to the prior protocol proposed by Riposte [50].

Despite making a weaker trust assumption and requiring only two servers, our protocol reduces client com-

putation time by several orders of magnitude, resulting in audit compute time of under 5 microseconds re-

gardless of the number of registered mailboxes and reducing overall client compute costs by 8× compared to

an implementation that uses Riposte’s auditing protocol.

On the server side, we show that Express’s throughput and latency costs are better than prior work. We

also calculate the dollar cost of running each system to send one million messages and find that Express costs

6× less to operate than Riposte, the second cheapest system. Throughout our experiments we generally com-

pare to prior work on message sizes comparable to or larger than those used in their original evaluations. Since

the recent whistleblower’s report to the US intelligence community’s inspector general contained 25.3KB of


text [11] and last year’s widely reported anonymous op-ed in the New York Times contained about 9KB of

text [10], we make sure to evaluate Express on 32KB messages as well.

3.7.1 Communication Costs

Figures 3.2 and 3.3 show communication costs for each party when sending a 160 Byte message and compares

to costs in Riposte [50] and Pung [9]. We use a smaller message size than in our subsequent experiments to

focus on measuring the role of the DPF and auditing in communication costs. Communication costs always

increase linearly with the size of the messages being sent. Express’s communication costs are constant

regardless of the number of mailboxes, compared to asymptotically√n in Riposte, the system with the next

lowest costs. For 214 mailboxes, Express has 8.34KB of communication by the server and 5.39KB by the

client for each write. The corresponding costs in Riposte are 208KB and 69KB, respectively, representing

communication reductions of 25× on the server side and 13× on the client. Riposte additionally requires a

third auditing server which incurs 13.8KB of communication, whereas Express has no such requirement. For

about one million (220) mailboxes, Express requires 101× less communication than Riposte on the client side

and 195× less on the server side. The communication reduction compared to Pung in this setting is 4, 631×on the server side and 7, 161× on the client side, reflecting the high cost of providing security with only one

server as Pung does. Our communication savings come from using log-sized DPFs that write into a large but

fixed-size virtual address space for write requests and from our new auditing protocol whose communication

costs do not increase with the number of mailboxes.

3.7.2 Client Costs

Client computation time in both our native C/Go and in-browser Javascript implementations remains constant

as the number of mailboxes on the server side increases: since the client always prepares a DPF to be run

on the 2128-sized virtual address space, the cost of preparing the DPF does not grow with the number of

mailboxes, and the client-side auditing cost is constant as well. To send a 1KB message, our client takes

20ms in C/Go and 51ms in Javascript. Combined with the low client communication costs in Figures 3.2

and 3.3, this shows that an Express client can easily be deployed as background Javascript in a web page to

create cover traffic, as explained in Section 3.6.1.

To further explore performance implications of an Express client being embedded on a major news site,

we measured the page load times of the New York Times, Washington Post, and Wall Street Journal websites.

On average, these pages took 5.4, 3.4, and 2.2 seconds to load completely (over a 50MBit/sec connection), so

the computation costs of our client in the browser are less than 3% of current page load times and can occur in

the background without impacting user experience. We also measured the sizes of the three websites (without

caching) at 4.9MB, 9.1MB, and 8.2MB, respectively. Our JavaScript implementation with dependent libraries

takes 72.5KB of space, so adding our code would increase a site’s size by less than 1.5%.

Auditing. In addition to enabling improved communication efficiency, as seen above, our auditing protocol


102 103 104 105 106

10−1

100

101

Number of Mailboxes

Tim

e[s

econ

ds]

Message Delivery Latency

Express (1KB) Pung (1KB)Express (10KB) Pung (10KB)Express (32KB)

Figure 3.5: Message delivery la-tency in Express and Pung for vari-ous message sizes. Express outper-forms Pung by 1.3−2.6× for 1KBmessages and by 2.0 − 2.9× for10KB messages. Pung’s perfor-mance for 10KB messages is com-parable to Express’s performancefor 32KB messages.

103 104 105

0

20

40

(Higher is better)

Number of Mailboxes

Thr

ough

put[

Msg

s/se

c]

Message Throughput

Riposte with 1KB MessagesExpress with 1KB Messages

Express with 32KB Messages

Figure 3.6: Express’s throughputis 1.4-6.3× that of Riposte for1KB messages. Even with 32KBmessages, Express’s throughput isstill comparable to Riposte on 1KBmessages. For large numbersof mailboxes, both systems arecomputation-bound by the num-ber of DPF evaluations required toprocess writes.

102 103 104 105 1060

500

1,000

Number of Mailboxes

Cos

t[$]

System Cost per 1M Messages


Figure 3.7: Dollar costs to run end-to-end metadata hiding systemswith cryptographic security guar-antees. Prices are based on GoogleCloud Platform public pricing in-formation for compute instancesand data egress. Processing onemillion messages in Express inthe presence of 100,000 registeredmailboxes costs 5.9× less than thenext cheapest system.

dramatically reduces computation costs for the client. Figure 3.4 shows the computation costs of our auditing

protocol as compared to the protocol used in Riposte [50], which we re-implemented for the purpose of this

experiment. Unlike Riposte, where client and server computation costs for auditing are comparable, our

protocol runs in O(1) time on the client, taking less than 5 microseconds regardless of how many mailboxes

are registered on the servers. This is about 55, 000× less than the client computation cost for auditing in

Riposte for one million mailboxes and translates to overall client computation on our system running 8×faster than it would if it were using the Riposte auditing protocol. In addition to the asymptotic improvement,

our protocol uses only hardware-accelerated AES evaluations, whereas Riposte’s auditing protocol involves

a mix of AES evaluations and more costly SHA256 hashes.

Our auditing protocol’s performance is comparable to Riposte on the server side, but it does not require

a third auditing server as Riposte does. The performance bottleneck on the servers is DPF evaluations, not

auditing, so server side performance improvements in auditing would only result in negligible improvements

in end-to-end performance. As we will see, Express outperforms Riposte’s overall throughput despite not

significantly changing server side auditing costs.


3.7.3 Server Performance

We now measure the performance of Express on the server-side. We measure the total throughput of the

system, the latency between when a client sends a message and when the mailbox owner can read it, and the

cost in dollars of running Express.

Throughput. We compare Express’s throughput to Riposte [50]. Figure 3.6 shows the comparison between

Express and Riposte for 1KB messages, where throughput is measured as the number of writes the servers

can process per unit time. Express’s throughput is 1.4-6.3× that of Riposte in our experiments, and Express’s

throughput when handling 32KB messages is comparable to Riposte when handling only 1KB messages for

up to about 50,000 mailboxes. Both systems are ultimately computation-bound by the number of DPF evalu-

ations required to process writes. The graph shows the high throughput of each system drops significantly as

they shift from being communication-bound to being computation-bound by DPF evaluations for increasingly

large numbers of mailboxes.

Like Express, Riposte uses DPFs to write messages across two servers. Unlike Express, Riposte requires

a third party to audit user messages and must run its protocol in rounds to provide anonymity guarantees to its

users. The rounds are necessary for Riposte’s anonymous broadcast setting because all messages are public,

so if messages were revealed after each write, the author of a message would clearly be whoever connected

to the system last. In contrast, Express messages can be delivered immediately without waiting for a round

to end.

Another difference between Express and Riposte is that Riposte relies on a probabilistic approach based

on hashing for users to decide where to write with their DPF queries. This means that there is a chance

messages will collide when written to the same address, rendering all colliding messages unreadable. We

evaluated Riposte with parameters set to allow a failure rate of 5%, meaning that 1 in 20 messages would

be corrupted by a collision and not delivered, even after Riposte’s collision-recovery procedure. Express’s

virtual address system avoids this issue because the space of virtual addresses is so large that collisions would

only occur with negligible probability.

Latency. Since Express does not require any synchronization between clients and the Express servers, the

latency of a write request consists only of the time for the servers to process the request and for the mailbox

owner to read the message. Figure 3.5 shows how latency for processing a single write request scales as

the number of mailboxes increases for various mailbox sizes. After about 10,000 mailboxes, or even 1,000

mailboxes for larger message sizes, message processing becomes bound by the latency of computing AES

for each DPF evaluation, so total latency increases linearly with the number of DPFs that must be evaluated

(one per mailbox).

In prior metadata-hiding communication systems, message delivery latency depends on a deployment-

specified round duration. As such, it is difficult to directly compare latency in Express to prior work. We

can, however, compare to the computation time on the servers to process one message and deliver it to its

recipient. For example, Riposte’s “latency” under this metric is simply the time to process a DPF write and

then run an audit. A more interesting comparison is to see how Express’s server-side costs compare to a


different architecture, such as the single-server PIR-based approach of Pung [9].

Since Pung [9] uses fast writes and more expensive reads whereas Express has fast reads but expensive

writes, we run both systems with a write followed by a read, as required by Pung’s messaging use case. As

shown in Figure 3.5, Express outperforms Pung by 1.3-2.6× when run with 100-1,000,000 mailboxes for

1KB messages. When we increase the message size to 10KB, we find that Pung is 2 − 2.9× slower than

Express and closely matches Express’s performance on 32KB messages. Note that the comparison to Pung

is not quite apples to apples because Pung operates in a stricter single-server security setting.

Total system cost. Having measured Express’s throughput and latency, we now turn to the question of Ex-

press’s cost in dollars (USD). Our evaluation focuses on the dollar cost of running the infrastructure required

for Express in the cloud and excludes human costs such as paying engineers to deploy and maintain the soft-

ware. The primary non-human costs in running Express, as with any metadata-hiding system, come from

running the necessary servers and passing data through them. Using the data from our evaluation thus far,

we estimate the price of running Express to send one million messages using public Google Cloud Platform

pricing information. We calculate the cost of running the system as the cost of hosting the Express servers for

the length of time required to process one million messages plus the data passed between the servers and back

to the client (data passing into Google cloud instances from clients outside is free). We price the instances

according to costs for various regions in the US and Canada and calculate data charges using the prices for

data transfer between regions in the US and Canada (for communication between servers) or with the public

internet (for communication with clients).

The results of this estimation process appear in Figure 3.7, where we carry out similar calculations for

Pung and Riposte. As depicted in the figure, processing one million messages with Express costs 5.9× less

than Riposte, the closest prior work measured, in the presence of 100,000 mailboxes. The high cost of running

Pung comes from its communication costs, where data egress charges far outweigh the cost of hosting the

system. The data egress cost of sending one million messages in Pung with 262,144 registered mailboxes

exceeds $1, 000. On the other hand, Express and Riposte incur smaller data costs, $0.05 per million messages

in Express and $4.21 per million messages in Riposte with one million registered mailboxes. The large gap in

cost between Express and Riposte comes from hosting the servers themselves. Express’s higher throughput

means it can process one million messages more quickly than Riposte, and the fact that it requires only two

servers, compared to three in Riposte, means that the cost per hour of running Express is approximately 2/3

that of running Riposte. Hosting costs per 24 hours, excluding data costs, are $11.75 for Pung, $37.25 for

Riposte, and $24.68 for Express, corresponding to the number of servers each system needs (including cost

differences for hosting servers in different regions).

Comparison to differential privacy systems. As described in Section 3.2.3, systems based on differential

privacy (DP) exchange gradual metadata leakage over time for stronger performance. Although this fun-

damental difference in security properties makes it difficult to do a direct comparison to DP systems such

as Vuvuzela [155], Stadium [152], and Karaoke [101], we will attempt here to roughly compare Express to

published performance results for Vuvuzela and Karaoke. Vuvuzela operates with the same distributed trust


model as Express, with a small number of servers, whereas Karaoke is designed for use in a setting with

many servers. See Section 3.2.3 for a discussion of these two approaches to distributing trust.

One further difference to keep in mind when comparing existing DP systems to Express (as well as the

systems we have compared Express to thus far) is that costs in Riposte, Pung, and Express increase in the

number of mailboxes registered, while costs in existing DP-based systems increase in the number of users

registered. This means that a fully connected communication graph on N users would require N2 mailboxes

in Express but would not require additional cost in DP systems beyond that of N users and the high volume

of traffic required for all of them to talk to each other. Fortunately, in most messaging systems, each user only

has a small number of active contacts relative to the total number of users on the platform, so this difference

should not cause harm in practice.

Vuvuzela’s end-to-end latency to deliver a 256 byte message for the lowest security setting on which it

was evaluated hovers around 8 seconds for 10,000 users and 20 seconds for one million users [155]. By com-

parison, Express takes 210ms to write and then read a larger 1KB message when there are 10,000 mailboxes

and 15 seconds when there are one million mailboxes. The higher latency in Vuvuzela is due to cover traffic

messages sent before a message can be delivered.

Karaoke operates using a variable number of servers, and its end-to-end latency to deliver a 256 byte

message hovers around 6 seconds for one million users and 100 servers when up to 20% of servers are

malicious [101]. However, Karaoke’s latency approximately triples when moving from providing security

against 20% malicious servers to 50% malicious servers, which more closely matches the one-out-of-two

security provided by Express. Since Karaoke’s evaluation was also conducted on more powerful machines

than ours, we conclude that latency is roughly comparable between Express and Karaoke.

On the other hand, not requiring cryptographic security allows DP solutions to achieve higher throughput

than cryptographic systems. As such, they can process messages faster and at lower cost than Express.

However, in addition to the difference in security guarantees, they achieve their low price by pushing the true

cost of operating the system onto clients. To send and receive messages, clients must always remain online.

3.8 Related Work

The most widely used anonymity system in use today is without a doubt Tor [62], which relies on onion

routing. SecureDrop [24,147] is a widely used Tor-based tool to allow sources to anonymously connect with

journalists to give tips. Although our work focuses on hiding metadata and not on preserving anonymity,

anonymity systems are often used even when clients only wish to hide metadata. Although a number of works

precisely model and analyze the security offered by Tor [16, 94, 95], it is unfortunately vulnerable to traffic

analysis attacks if a passive adversary controls enough of the network [61, 84, 88]. A recent impossibility

result suggests that this limitation may be necessary for broad classes of anonymity systems [59].

Cryptographic security. Express belongs to a broad family of works which aim to give cryptographic

guarantees regarding anonymity and metadata-hiding properties. One category of works in this area include


systems based on mix-nets [51, 53, 75, 97, 127, 133, 163] which involve all users in a peer to peer system par-

ticipating in shuffling messages [41,42]. Later work has added verifiability to this model [97] and outsourced

the shuffling to a smaller set of servers [133, 163]. Most recently, mixing techniques have been extended to

support large numbers of users in Atom [96] and XRD [98]. Systems in this line of work suffer from high

latency due to the need to run many shuffles and require participation by a large number of servers run by

different operators to achieve security.

An important difference between Express and mixnets relates to tradeoffs in anonymity and latency. Since

a user’s anonymity set is based on the number of messages being shuffled together, a mixnet operator must

choose between a high-latency setting with a large anonymity set or a lower latency setting with a smaller

anonymity set. For example, if 1,000 messages are sent through the system in one hour, a mixnet that

wants an anonymity set size of 1,000 must wait an hour before it can deliver messages, whereas Express can

achieve the same anonymity set but deliver messages immediately. A mixnet’s anonymity set is restricted

to the number of messages included in the mixing, which in turn depends on the desired latency, leading to

an inherent tradeoff between anonymity and latency [59]. Express messages, on the other hand, are in some

sense mixed with all the prior messages sent through the system. This means that while a mixnet may have

to compromise on anonymity set size to meet a given latency goal, Express does not.

Another class of cryptographic messaging solutions use private information retrieval techniques [8, 34,

46, 74, 116, 123] to render reads or writes into a database of mailboxes private and target a variety of use

cases [9, 31, 45, 48, 50, 91, 92]. Express falls into this category. Riposte [50] and, more recently, Blinder [4],

provide anonymous broadcast mechanisms using DPFs [74], and Talek [45] offers a private publish-subscribe

protocol. P3 [91] deals with privately retrieving messages with more expressive search queries. Pung [9]

operates in a single-server setting and therefore requires weaker trust assumptions than Express, but as we

show in Section 3.7, has higher costs than Express as well.

Differential privacy. Another class of works make differential privacy guarantees [63] instead of crypto-

graphic guarantees. These systems typically achieve better performance but at the cost of setting a privacy

budget that dictates how much privacy the system will provide. These works include Vuvuzela [155], Alpen-

horn [102], Stadium [152], and Karaoke [101].

3.9 Conclusion

We have presented Express, a metadata-hiding communication system that requires only symmetric key cryp-

tographic primitives while providing near-optimal communication costs. In addition to order of magnitude

improvements in communication cost, Express reduces the dollar cost of running a metadata-hiding commu-

nication system by 6× compared to prior work. Our implementation is open source and available online at

https://github.com/SabaEskandarian/Express.

The remaining sections in this chapter provide details regarding the security of our protocols as well as

additional background on SNIPs.

https://github.com/SabaEskandarian/Express


3.10 Additional Details of Security Arguments

This section formalizes and proves the soundness and metadata-hiding security properties described in Sec-

tion 3.2.

Soundness. We formalize soundness as follows.

Definition 3.10.1 (Soundness). We define the following soundness game SOUND[λ] played between an

adversary A and a challenger C who simulates the behavior of servers A and B. Both A and C are given λ

as input.

• Setup. Challenger C creates an initially empty list I of compromised mailbox indices. Adversary Arequests creation of a number of mailboxes N of its choosing. There are two ways in which it may create

a mailbox:

1. Adversary A performs the role of a user interacting with the servers to create a new mailbox. Chal-

lenger C adds this mailbox to I .

2. Adversary A instructs C to create a mailbox where C plays the role of both the user and the servers,

saving the user’s state (and in particular, the mailbox keys) at the end of the registration process.

• Queries and Corruptions. AdversaryA sends requests to the servers, controlled by C. At any time, it may

send C a mailbox index i, at which point C will send the saved state of the user who registered mailbox i

and add i to list I .

• Output. Challenger C performs a read on each registered mailbox. If |I| < N and any mailbox outside

of the list I contains nonzero contents, the adversary wins the game.

We say a messaging scheme is sound if no PPT adversary can win the soundness game above with greater

than negligible probability in the security parameter λ.

Claim 3.10.2. The Express scheme is sound.

Proof. The soundness proof follows closely from the soundness of our auditing protocol. For each write

request sent to the Express servers, we consider two cases: where the write modifies one mailbox and where

the write modifies more than one mailbox. If a write modifies more than one mailbox, then it will not be

applied to the database of mailboxes, except with negligible probability in λ, by the soundness property of

the auditing protocol. This means that we must only consider writes that modify a single mailbox. The

adversary does not know the virtual addresses of mailboxes outside of I , but it only wins the soundness game

if it produces a DPF that writes to the address of a mailbox outside of I . This can only occur with probability

2−λ (for λ = 128 in our instantiation of the protocol), which is also negligible. Thus an adversary can only

win the soundness game with probability negligible in λ.

Metadata-hiding. We can formalize the definition of metadata-hiding by requiring that there exists an effi-

cient simulator algorithm Sim that, given the list ` of honest clients who connect with the servers, produces

an output which is computationally indistinguishable from the view of an adversary A who controls any


number of users and one server while processing requests from the remaining honest users, subject to the re-

striction that the recipients of the messages from honest users are never among those controlled by A. More

specifically, ` should include which client connects, time of connection, and size of message transmitted for

each connection made to the compromised server. Given this information, the client can simulate the content

of the messages sent by the honest client.

This definition satisfies our intuitive notion of metadata-hiding because it means that for each message,

the server learns nothing about who the message is sent to, as everything it learns could be simulated before

it even sees the request. This information would be contained in the content of the honest client’s messages,

which are not given to the simulator. We sketch a proof of the metadata-hiding security argument below. The

proof relies on the zero-knowledge property of the auditing protocol, the privacy of the DPFs used, and the

security of the encryption used for access control.

Claim 3.10.3 (Informal). There exists an algorithm Sim that, given the list ` of honest client connections to

the Express servers, simulates the view of an adversary A who controls one Express server and any number

of clients, subject to the restriction that the recipients of the honest clients’ messages are never among those

controlled by A.

Proof (sketch). Sim simulates write requests from honest users and the process of auditing them by invoking

the simulator implied by the zero-knowledge property of the auditing protocol. Note that this in turn uses the

simulator implied by the definition of DPF privacy to generate DPF shares. Moreover, whenever malicious

users request to read the contents of mailboxes, the simulated honest server(s) returns encryptions of zero.

The proof that this simulator gives the adversary A a view indistinguishable from interaction with a

real honest server and honest users is fairly straightforward. First, since the adversary knows the virtual

addresses of honest users’ mailboxes, as well as one of the two keys needed to read the contents of those

mailboxes (if it has compromised one of the servers), it can send read requests for the contents of honest

mailboxes. However, since the adversary does not see the second key to any honest users’ mailboxes, we

invoke the semantic security of the encryption scheme used to protect honest mailbox contents to show that

the messages returned from read requests to an honest server are indistinguishable from encryptions of zero.

From here, just as in the case of soundness, the proof follows from the security of the auditing scheme.

From the zero-knowledge property of the auditing scheme, we know that the view of either server in the

auditing protocol can be simulated. But the view of each server in Express’s auditing protocol is the same as

the view of that server in the overall protocol, since the server’s view only consists of its shares of the proof

input (in the compressed form of a DPF share from which it derives the actual inputs) and the proof messages

themselves.

3.11 Additional Details on SNIPs and Analysis of Auditing Protocol

This section sketches the instantiation of the proofs used in our auditing protocol as well as the analysis of the

auditing protocol. Full details and a security proof for this proof system can be found in the Prio paper [49].


We include the instantiation of the proof here for completeness, including some improvements described in

the follow-up work of Boneh et al. [26].

The size of a SNIP proof is linear in the number of multiplication gates in the arithmetic circuit repre-

senting the statement to be proved. In our case, there are 2 multiplications. The client numbers the gates

as 1 and 2. The idea of the proof is to create three polynomials f , g, and h such that f, g represent the left

and right inputs of each gate and h to the outputs of each gate. f is the polynomial defined by the points

(0, rf ), (1, c), (2,m), and g is the polynomial defined by the points (0, rg), (1, c), (2, C), where rf and rg are

random values chosen by the client. Observe that the servers already hold shares of each point used to define

f and g except the random values rf and rg , shares of which must be included in the SNIP proof.

Next, h is defined as the polynomial representing the expected outputs of each multiplication gate, or the

product f · g. Since each of f and g will be of degree 2, h will be of degree 4. The client can compute h from

f and g and must send shares of the description of h to each server as part of the proof.

Since the servers now have shares of the inputs and outputs of each multiplication from f , g, and h, they

only need to check that f ·g = h to be convinced that this relationship holds among their inputs. They do this

by evaluating each polynomial at a random point t and checking equality. To compute the product f(t) · g(t),

the servers simply evaluate their shares of each function and publish the result. This reveals nothing about f

or g except their value at the point t.

The Prio paper [49] and the improvements of Boneh et al. [26] give full proofs of completeness, sound-

ness, and zero-knowledge for this protocol. As a minor optimization, instead of sending one proof as de-

scribed above, we send two separate SNIPs, one for each of the two multiplications. This results in a slightly

larger proof size but simplifies the polynomial multiplications because the polynomials f , g become linear

and h becomes quadratic. The security properties of the protocol are unchanged by this modification.

Analysis. Having described the relevant building blocks, we now sketch the analysis of our full auditing

protocol. The security properties of our auditing scheme follow directly from those of the two protocols we

combine to build it (which we do not re-prove here). Completeness follows directly from the completeness

of the verifiable DPF protocol of Boyle et al. as well as the completeness of SNIPs.

Likewise, soundness follows directly from the soundness of these two building blocks, with soundness

error equal to the sum of the soundness error of the DPF verification protocol and the SNIP. We prove the

following claim.

Claim 3.11.1. If the servers begin the auditing protocol holding vectors wA ∈ Fn and wB ∈ Fn such that

w = wA + wB ∈ Fn is a vector of Hamming-weight greater than one, then the audit will reject, except with

error probability ε = O(1/|F|).

By taking F to be a field of size 2λ, for security parameter λ, we can make the error probability ε negligibly

small in λ.

The claim is true because the auditing protocol will only accept a false proof if (1) the difference c2 −mC = 0 for a w that has more than one non-zero entry, or (2) the soundness of the SNIP fails to enforce that

only inputs satisfying this relationship will be accepted. But the probability of (1) is negligible in |F| by the


security of the DPF verification protocol of Boyle et al. [34], and the probability of (2) is negligible in |F| by

the soundness of SNIPs [26,49]. By a union bound, the soundness error of the overall protocol is at most the

sum of the soundness errors of the verifiable DPF protocol and the SNIPs.

To prove the zero-knowledge property, we must show that there exists a simulator algorithm Sim that can

produce outputs whose distribution is computationally indistinguishable from the view of the servers in an

execution of the Express auditing protocol where the sum wA + wB corresponds to a vector with a single

non-zero entry. This algorithm will interact with a potentially malicious adversary A who plays the role of

the server whose view is being simulated. This proves the security of the protocol because it shows that an

adversary can learn anything it would learn from actually participating in the protocol by running Sim on its

own.

The construction of Sim and subsequent proof of security follow almost directly from the original proof of

security for SNIPs used in Prio [49]. To see why, observe that the view of each server in the auditing protocol

consists of the server’s DPF share, the server’s share of the proof, and any messages sent between the servers

during the proof. The only difference between this and the standard SNIP simulator is that the server’s inputs

are compressed in the form of DPF shares instead of being stated explicitly as the vector wA or wB . In

essence, the DPF can be thought of as an efficient way to encode the server’s inputs to the proof. To bridge

this difference between our protocol and the original SNIP, we make one small change to the SNIP simulator.

The original SNIP simulator samples the server’s input share at random. Our modified SNIP simulator will

sample the server’s input shares using simulated DPF shares instead. Since the proof of zero-knowledge is

otherwise identical, we defer to the prio paper for the full proof [49].

Chapter 4

Improving Speed and Security inUpdatable Encryption Schemes

In this chapter, we turn our attention to securing data that is encrypted and stored in the cloud. We will focus

in particular on the problem of key rotation. Key rotation refers to the process of re-encrypting encrypted

content under a fresh key, and overwriting the old ciphertext with the new one. Periodic key rotation is

a common practice designed to limit the long-term power of cryptographic keys. When encrypted data is

stored in the cloud, key rotation can be very costly: it may require downloading the entire encrypted content

from the cloud, re-encrypting it on the client’s machine, and uploading the new ciphertext back to the cloud.

An updatable encryption scheme is a symmetric-key encryption scheme designed to support efficient key

rotation in the cloud. The data owner sends a short update token to the cloud. This update token lets the cloud

rotate the ciphertext from the old key to the new key, without learning any information about the plaintext.

Recent work on updatable encryption has led to several security definitions and proposed constructions.

However, existing constructions are not yet efficient enough for practical adoption, and the existing security

definitions can be strengthened.

This chapter makes three contributions. First, we introduce stronger security definitions for updatable

encryption (in the ciphertext-dependent setting) that capture desirable security properties not covered in prior

work. Second, we construct two new updatable encryption schemes. The first construction relies only on

symmetric cryptographic primitives, but only supports a bounded number of key rotations. The second con-

struction supports a (nearly) unbounded number of updates, and is built from the Ring Learning with Errors

(RLWE) assumption. Due to complexities of using RLWE, this scheme achieves a slightly weaker notion of

integrity compared to the first. Finally, we implement both constructions and compare their performance to

prior work. Our RLWE-based construction is 200× faster than a prior proposal for an updatable encryption

scheme based on the hardness of elliptic curve DDH. Our first construction, based entirely on symmetric

66

CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 67

primitives, has the highest encryption throughput, approaching the performance of AES, and the highest de-

cryption throughput on ciphertexts that were re-encrypted fewer than fifty times. For ciphertexts re-encrypted

over fifty times, the RLWE construction dominates it in decryption speed.

4.1 Introduction

Consider a ciphertext ct that is a symmetric encryption of some data using key k. Key rotation is the process

of decrypting ct using k, and re-encrypting the result using a fresh key k′ to obtain a new ciphertext ct′. One

then stores ct′ and discards ct. Periodic key rotation is recommended, and even required, in several security

standards and documents, including NIST publication 800-57 [19], the Payment Card Industry Data Security

Standard (PCI DSS) [125], and Google’s cloud security recommendations [78].

Key rotation ensures that secret keys are periodically revoked. In the event that a key is compromised,

regular key rotation limits the amount of data that is vulnerable to compromise. Limiting the amount of data

that is encrypted with the same key for extended periods of time also helps prevent advanced brute-force

attacks. Key update on ciphertexts can also be used to revoke old users from accessing newly encrypted data.

Key rotation can be expensive when the ciphertext is stored in the cloud, and the cloud does not have

access to the keys. Key rotation requires the client to retrieve all the encrypted data from the cloud, re-

encrypt it by decrypting with the old key and re-encrypting with the new key, and then upload the resulting

ciphertext back to the cloud. The traffic to and from the cloud can incur significant networking costs when

large amounts of data are involved. Alternatively, the client can send the old and the new key to the cloud,

and have the cloud re-encrypt in place, but this gives the cloud full access to the data in the clear. We note

that either way, the cloud must be trusted to discard the old ciphertext.

Updatable encryption [28, 32, 66, 93, 104] is a much better approach to key rotation for encrypted data

stored in the cloud. Updatable encryption is a symmetric encryption scheme that supports the standard key-

generation, encryption, and decryption algorithms, along with two additional algorithms called ReKeyGen

and ReEncrypt used for key rotation. The re-key generation algorithm is invoked as ReKeyGen(k, k′)→ ∆,

taking as input a pair of keys, k and k′, and outputting a short “update token” ∆, also called a re-encryption

key. The re-encryption algorithm is invoked as ReEncrypt(∆, ct) → ct′, taking as input a short ∆ and a

ciphertext ct encrypted under k, and outputting an updated ciphertext ct′ that is the encryption of the same

data as in ct, but encrypted under k′.

If the client’s data is encrypted using an updatable encryption scheme, then the client can use the re-key

generation algorithm ReKeyGen to generate a short update token ∆ to send the cloud. The cloud then runs

the re-encryption algorithm ReEncrypt to update all the client’s ciphertexts. As before, the cloud must be

trusted to discard the old ciphertexts.

Defining security Intuitively, the update token ∆ must not reveal any “useful” information to the cloud. This

was formalized by Boneh et al. [28] against passive adversaries, and was improved and extended to provide

security against active adversaries by Everspaugh et al. [66].


However, we show in section 4.3 that these existing elegant definitions can be insufficient, and may not

prevent some undesirable information leakage. In particular, we give a simple construction that satisfies the

existing definitions, and yet an observer can easily learn the age of a ciphertext, namely the number of times

that the ciphertext was re-encrypted since it was initially created. Ideally, this information should not leak to

an observer who only sees the ciphertext. This issue was recently independently pointed out in [32].

The age of a ciphertext (i.e., the number of times that the ciphertext was re-encrypted) can leak sensitive

private information about the plaintext in many real-world situations. We give two illustrative examples

assuming an annual key rotation policy is in use:

• Consider a national database managed in the cloud where information about each individual is stored

in a single fixed-size encrypted record. Suppose a newborn is recorded in the database at birth. If an

annual key rotation policy is used, and records are encrypted using a scheme that leaks the number of

key rotations, then an adversary (or a cloud administrator), who examines the stored ciphertexts will

learn every person’s age, even though age is regarded as personal identifiable information (PII) and

must be protected.

• Consider a dating app, like Tinder or Match.com, that maintains customer information in an encrypted

cloud storage. The number of key-updates on a person’s file can indicate how long the person has been

a customer, which is sensitive information that should be protected.

To address this definitional shortcoming, we define a stronger confidentiality property that requires that a

re-encrypted ciphertext is always computationally indistinguishable from a freshly generated ciphertext, no

matter how many times it was re-encrypted (sections 4.3.2 and 4.3.3). This ensures that an observer who

sees the encrypted content at a particular point in time, cannot tell the ciphertext age. We also strengthen the

integrity definition of [66] to cover additional tampering attacks, as discussed in section 4.3.4.

Constructing updatable encryption Next, we look for efficient constructions that satisfy our definitions.

We give two new constructions: one based on nested authenticated encryption and another based on the Ring

Learning With Errors (RLWE) problem [108, 131].

Our first construction, presented in section 4.4, makes use of carefully designed nested encryption, and

can be built from any authenticated encryption cipher. It satisfies our strong confidentiality and integrity

requirements, so that an adversary cannot learn the age of a ciphertext. However, the scheme only supports

a bounded number of re-encryptions, where the bound is set when the initial ciphertext is created. Another

limitation of this scheme is that decryption time grows linearly with the age of the ciphertext. Hence, the

scheme is practical as long as the maximum number of re-encryptions is not too large. Our implementation

and experiments, discussed below, make this precise.

Our second construction, presented in section 4.5, makes use of an almost key-homomorphic PRF (KH-

PRF) built from the RLWE problem. Recall that a key-homomorphic PRF (KH-PRF) [28, 122] is a secure

PRF F : K×X → Y , where (K,+) and (Y,+) are finite groups, and the PRF is homomorphic with respect

to its key, namely F (k1, x)+F (k2, x) = F (k1 +k2, x) for all k1, k2 ∈ K and x ∈ X . We say that the PRF is


an almost KH-PRF if the equality above holds up to a small additive error (see theorem 4.2.5). To see why a

KH-PRF is useful for updatable encryption, consider a single message block mi ∈ Y that is encrypted using

counter mode as cti ← mi + F (k, i), for some i ∈ X and k ∈ K. To rotate the key, the client chooses a new

key k′ ← K and sends ∆ = k′ − k ∈ K to the cloud. The cloud computes ct′i = cti + F (∆, i), which by the

key-homomorphic property satisfies ct′i = mi + F (k′, i), as required.

It remains an open challenge to construct a secure KH-PRF whose performance is comparable to AES.

However, there are several known algebraic constructions. In the random oracle model [22, 68], there is a

simple KH-PRF based on the Decision Diffie-Hellman (DDH) assumption [122], and a simple almost KH-

PRF based on the Learning With Rounding (LWR) problem [28]. There are also several KH-PRFs whose

security does not depend on random oracles, as discussed in the related work section.

Everspaugh et al. [66] construct an updatable encryption scheme that supports unbounded key updates

by combining a key-homomorphic PRF with authenticated encryption and a collision-resistant hash function.

They evaluate their construction using the KH-PRF derived from DDH, in the random oracle model, instan-

tiated in the 256-bit elliptic curve Curve25519 [23]. We show that the Everspaugh et al. [66] construction

satisfies our new confidentiality security definitions for updatable encryption. However, compared to our first

nested encryption construction that relies only on generic authenticated encryption, the implementation of

the Everspaugh et al. construction is much slower as it uses expensive group operations.

In our second updatable encryption scheme, we significantly improve on the performance of the Ev-

erspaugh et al. [66] construction by extending it to work with an almost key-homomorphic PRF. Our con-

struction supports nearly unbounded key-updates, and outperforms the Everspaugh et al. construction by

200× in speed. The high performance of the scheme is, in part, due to a new almost KH-PRF construc-

tion from the RLWE assumption. Almost KH-PRFs can already be constructed from the (Ring-) Learning

with Rounding (RLWR) assumption [18, 28]. However, we observe that for the specific setting of updatable

encryption, the parameters of the PRF can be further optimized by modifying the existing PRF construc-

tions to base security directly on the standard RLWE assumption. We provide the details of our construction

in section 4.6.

The use of an almost key-homomorphic PRF leads to some complications. First, there is a small ciphertext

expansion to handle the noise that arises from the imperfection of the KH-PRF key-homomorphism. More

importantly, due to the noisy nature of the ciphertext, we show that an adversary may gain information about

the age of the corresponding plaintext using a chosen ciphertext attack, which violates our new security

definition. Therefore, while this construction is attractive due to its performance, it can only be used in

settings where revealing the age of a ciphertext is acceptable. In section 4.5.3 we capture this security property

using a relaxed notion of ciphertext integrity, and show that the scheme is secure in this model.

Implementation and experiments In section 4.7, we experiment with our two updatable encryption schemes

and measure their performance. For our first construction based on authenticated encryption, we measure the

trade-off between its efficiency and the number of key rotations it can support. Based on our evaluation, our

first construction performs better than the other schemes in both speed and ciphertext size, as long as any


given ciphertext is to be re-encrypted at most twenty times over the course of its lifetime. It outperforms the

other schemes in speed (but not in ciphertext size) as long as ciphertexts are re-encrypted at most fifty times.

For our second construction, which uses an almost key-homomorphic PRF based on RLWE, we compare

its performance with that of Everspaugh et al. [66], which uses a key-homomorphic PRF over Curve25519.

Since we use an almost key-homomorphic PRF that is inherently noisy, any message to be encrypted must

be padded on the right to counteract the noise. Therefore, compared to the elliptic-curve based construction

of Everspaugh et al., our construction produces larger ciphertexts (32% larger than those of Everspaugh et al.).

However, in terms of speed, our implementation shows that our construction outperforms that of Everspaugh et al.

by over 200×. We provide a more detailed analysis in Section 4.7. Implementations of both our constructions

are open source and available at [2].

Summary of our contributions. Our contributions are threefold. First, we strengthen the definition of up-

datable encryption to provide stronger confidentiality and integrity guarantees. Second, we propose two new

constructions. Finally, we experiment with both constructions and report on their real world performance and

ciphertext expansion. Encryption throughput of our first construction, while allowing only a bounded number

of key rotations, is close to the performance of AES. Our second construction, based on a key-homomorphic

PRF from RLWE, is considerably faster than the previous construction of Everspaugh et al. [66], which is

based on elliptic curves.

4.1.1 Related Work

Two flavors of updatable encryption There are two flavors of updatable encryption: ciphertext-dependent

schemes [28, 66] and ciphertext-independent schemes [32, 93, 104]. In a ciphertext-dependent updatable

encryption scheme, the client can re-download a tiny fraction of the ciphertext that is stored by the server

before generating the update tokens. In a ciphertext-independent updatable encryption scheme, the client

generates its update token without needing to download any components of its ciphertext. In this work, we

focus on the ciphertext-dependent setting, where constructions are considerably more efficient. We provide

a detailed comparison of the two settings in section 4.10. Further discussion of the two models can be found

in [104].

Key-homomorphic PRFs. The concept of key-homomorphic PRFs was introduced by Naor, Pinkas, and

Reingold [122], and was first formalized as a cryptographic primitive by Boneh et al. [28], who construct

two KH-PRFs secure without random oracles: one from LWE, and another from multilinear maps. They also

observe that any seed homomorphic PRG G : S → S2 gives a key-homomorphic PRF. More constructions

for key-homomorphic PRFs from LWE include [17, 36, 90].


4.2 Preliminaries

Basic notation. For an integer n ≥ 1, we write [n] to denote the set of integers 1, . . . , n. For a distribu-

tion D, we write x ← D to denote that x is sampled from D; for a finite set S, we write x ←R S to denote

that x is sampled uniformly from S. We say that a family of distributions D = Dλλ∈N is B-bounded if the

support of D is −B, . . . , B − 1, B with probability 1.

Unless specified otherwise, we use λ to denote the security parameter. We say a function f(λ) is negligi-

ble in λ, denoted by negl(λ), if f(λ) = o(1/λc) for all c ∈ N. We say an algorithm is efficient if it runs in

probabilistic polynomial time in the length of its input. We use poly(λ) to denote a quantity whose value is

bounded by a fixed polynomial in λ.

4.2.1 Basic Cryptographic Primitives

In this section, we review a number of basic cryptographic primitives that we use in this work. To analyze the

exact security of our constructions in Sections 4.4 and 4.5, we parameterize the security of these notions with

respect to advantage functions ε : N→ R that bound the probability of an efficient adversary in breaking the

security of the primitive.

Definition 4.2.1 (Collision-Resistant Hash Functions). Let Hλ = H : X → Yλ be a family of hash func-

tions. We say that H is εcr-secure as a collision resistant hash function if for all efficient adversaries A, we

have

Pr[A(1λ, H)→ (x0, x1) ∧H(x0) = H(x1) : H ←R Hλ

]= εcr(λ).

We say thatH is secure as a collision resistant hash function if εcr(λ) = negl(λ).

Definition 4.2.2 (Pseudorandom Generators). Let G : Xλ → Yλ be a keyed function. We say that G is

εprg-secure as a pseudorandom generator (PRG) if for all efficient adversaries A, we have∣∣∣Pr[A(1λ, y0) = 1 : s←R Xλ, y0 ← G(s)

]− Pr

[A(1λ, y1) = 1 : y1 ←R Yλ

]∣∣∣ = εprg(λ).

We say that G is a secure pseudorandom generator if |Xλ| < |Yλ|, and εprg(λ) = negl(λ).

4.2.2 Pseudorandom Functions

In this section, we review the definition of a pseudorandom function.

Definition 4.2.3 (Pseudorandom Functions [76]). Let F : Kλ × X → Y be a keyed function. We say that F

is εprf -secure as a pseudorandom function (PRF) if for all efficient adversaries A, we have∣∣∣Pr[AF (k,·)(1λ) = 1 : k←R Kλ

]− Pr

[Af(·)(1λ) = 1 : f ←R Funs[Xλ,Yλ]

]∣∣∣ = εprf(λ),


where Funs[X ,Y] denotes the set of all functions with domain X and range Y . We say that F is a secure

pseudorandom function if εprf(λ) = negl(λ).

In this work, we use a special family of pseudorandom functions called key-homomorphic PRFs (KH-PRFs)

that satisfy additional algebraic properties. Specifically, the key space K and the range Y of the PRF exhibit

certain group structures such that its evaluation on any fixed input x ∈ X is homomorphic with respect to

these group structures. Formally, we define a key-homomorphic PRF as follows.

Definition 4.2.4 (Key-Homomorphic PRFs [28,122]). Let (K,⊕), (Y,⊗) be groups. Then, a keyed function

F : Kλ ×Xλ → Yλ is a key-homomorphic PRF (KH-PRF) if

• F is a secure PRF as specified in theorem 4.2.3.

• For every key k1, k2 ∈ K and every input x ∈ X , we have

F (k1, x)⊗ F (k2, x) = F (k1 ⊕ k2, x).

We also work with a slight relaxation of the notion of key-homomorphic PRFs. Namely, instead of requiring

that the PRF outputs are perfectly homomorphic with respect to the PRF keys, we require that they are

“almost” homomorphic in that F (k1, x) ⊗ F (k2, x) ≈ F (k1 ⊕ k2, x). Precisely, we define an almost key-

homomorphic PRF as follows.

Definition 4.2.5 (Almost Key-Homomorphic PRFs [28]). Let (K,⊕) be a group and let m and q be positive

integers. Then, an efficiently computable deterministic function F : K × X → Zmq is a γ-almost key-

homomorphic PRF if

• F is a secure PRF (Definition 4.2.3).

• For every key k1, k2 ∈ K and every x ∈ X , there exists a vector e ∈ [0, γ]m such that

F (k1, x) + F (k2, x) = F (k1 ⊕ k2, x) + e (mod q).

4.2.3 Authenticated Encryption

We recall the notion of an authenticated encryption scheme [21].

Definition 4.2.6 (Authenticated Encryption [21]). An authenticated encryption scheme for a message space

M is a tuple of efficient algorithms ΠAE = (KeyGen,Encrypt,Decrypt) that have the following syntax:

• KeyGen(1λ)→ k: On input a security parameter λ, the key-generation algorithm returns a key k.

• Encrypt(k,m) → ct: On input a key k and a message m ∈ M, the encryption algorithm returns a

ciphertext ct.


• Decrypt(k, ct) → m/⊥: On input a key k and a ciphertext ct, the decryption algorithm returns a

message m or ⊥.

We define the correctness, confidentiality, and integrity properties for an authenticated encryption scheme in

the standard way.

Definition 4.2.7 (Correctness). We say that an authenticated encryption scheme ΠAE = (KeyGen,Encrypt,

Decrypt) is correct if for all λ ∈ N and m ∈M, we have

Pr[Decrypt

(k,Encrypt(k,m)

)= m

]= 1,

where k← KeyGen(1λ).

Definition 4.2.8 (Confidentiality). Let ΠAE = (KeyGen,Encrypt,Decrypt) be an authenticated encryption

scheme for a message spaceM. We say that ΠAE satisfies εconfae -confidentiality if for all efficient adversaries

A, we have ∣∣∣Pr[AOk,0(·,·)(1λ) = 1

]− Pr

[AOk,1(·,·)(1λ) = 1

]∣∣∣ = εconfae (λ),

where k← KeyGen(1λ), and the oracle Ok,b for b ∈ 0, 1 is defined as follows:

• Ok,b(m(0),m(1)): On input two messages m(0),m(1) ∈M, the oracle computes ct← Encrypt(k,m(b))

and returns ct.

We say that ΠAE satisfies confidentiality if εconfae (λ) = negl(λ).

Definition 4.2.9 (Integrity). Let ΠAE = (KeyGen,Encrypt,Decrypt) be an authenticated encryption scheme

for a message spaceM. We say that ΠAE satisfies εintae -integrity if for all efficient adversaries A, we have

Pr[AOk(·)(1λ) = ct ∧ Decrypt(k, ct) 6= ⊥ ∧ ct /∈ Table

]= εintae (λ),

where k←R KeyGen(1λ), and the oracle Ok and table Table are defined as follows:

• Ok(m): On input a message m ∈ M, the oracle computes ct ← Encrypt(k,m), adds Table =

Table ∪ ct, and returns ct.

We say that ΠAE satisfies integrity if εintae (λ) = negl(λ).

For our updatable encryption scheme in section 4.4, we make use of authenticated encryption schemes that

satisfy a stronger confidentiality requirement than theorem 4.2.8. Namely, we rely on authenticated encryp-

tion schemes that satisfy ciphertext pseudorandomness, which requires that an encryption of any message is

computationally indistinguishable from a random string of suitable length. Authenticated encryption schemes

that satisfy ciphertext pseudorandomness can be constructed from pseudorandom functions or block ciphers

in a standard way. Widely-used modes for authenticated encryption such as AES-GCM also satisfy ciphertext

pseudorandomness.


Definition 4.2.10 (Ciphertext Pseudorandomness). Let ΠAE = (KeyGen,Encrypt,Decrypt) be an authenti-

cated encryption scheme for a message spaceM. We say that ΠAE satisfies εrandae -ciphertext pseudorandom-

ness if for all efficient adversaries A, we have∣∣∣Pr[AOk,0(·)(1λ) = 1

]− Pr

[AOk,1(·)(1λ) = 1

]∣∣∣ = εrandae (λ),

where k← KeyGen(1λ), and the oracles Ok,b for b ∈ 0, 1 are defined as follows:

• Ok,0(m): On input a message m ∈M, the oracle computes ct← Encrypt(k,m) and returns ct.

• Ok,1(m): On input a message m ∈ M, the oracle computes ct ← Encrypt(k,m), samples ct′ ←R

0, 1|ct|, and returns ct′.

We say that ΠAE satisfies ciphertext pseudorandomness if εrandae (λ) = negl(λ).

4.3 New Definitions for Updatable Encryption

In this section, we present new security definitions for updatable encryption in the ciphertext dependent

setting. Our definitions build upon and strengthen the confidentiality and integrity definitions for an updatable

authenticated encryption scheme from Everspaugh et al. [66]. We start by defining the syntax for an updatable

encryption scheme and its compactness and correctness conditions in section 4.3.1. We then present security

definitions for confidentiality and integrity, comparing each to prior definitions as we present them.

4.3.1 Updatable Encryption Syntax

For ciphertext-dependent updatable encryption schemes, it is useful to denote ciphertexts as consisting of

two parts: a short ciphertext header ct, which the client can download to generate its update token, and a

ciphertext body ct that encrypts the actual plaintext.

Formally, we define the syntax for an updatable encryption scheme as follows. To emphasize the cipher-

text integrity properties of our constructions in section 4.4 and section 4.5, we refer to an updatable encryption

scheme as an updatable authenticated encryption scheme in our definitions.

Definition 4.3.1 (Updatable Authenticated Encryption). An updatable authenticated encryption (UAE) scheme

for a message spaceM = (Mλ)λ∈N is a tuple of efficient algorithms ΠUAE = (KeyGen,Encrypt,ReKeyGen,

ReEncrypt,Decrypt) that have the following syntax:

• KeyGen(1λ) → k: On input a security parameter λ, the key generation algorithm returns a secret

key k.

• Encrypt(k,m)→ (ct, ct): On input a key k and a message m ∈Mλ, the encryption algorithm returns

a ciphertext header ct and a ciphertext body ct.


• ReKeyGen(k1, k2, ct) → ∆1,2,ct/⊥: On input two keys k1, k2, and a ciphertext header ct, the re-

encryption key generation algorithm returns an update token ∆1,2,ct or ⊥.

• ReEncrypt(∆, (ct, ct)) → (ct′, ct′)/⊥: On input an update token ∆, and a ciphertext (ct, ct), the

re-encryption algorithm returns a new ciphertext (ct′, ct′) or ⊥.

• Decrypt(k, (ct, ct)) → m/⊥: On input a key k, and a ciphertext (ct, ct), the decryption algorithm

returns a message m or ⊥.

A trivial way of achieving an updatable authenticated encryption scheme is to allow a client to re-download

the entire ciphertext, re-encrypt it, and send it back to the server. Therefore, for a UAE scheme to be useful and

meaningful, we require that the communication between the client and server be bounded and independent

of the size of the message encrypted in the ciphertext to be updated. This is captured by the compactness

property, which requires that any ciphertext header and update token have lengths that depend only on the

security parameter.

Definition 4.3.2 (Compactness). We say that an updatable authenticated encryption scheme ΠUAE = (KeyGen,

Encrypt,ReKeyGen,ReEncrypt,Decrypt) for a message space M = (Mλ)λ∈N is compact if there exist

polynomials f1(·), f2(·) such that for any λ ∈ N and message m ∈Mλ, we have (with probability 1)

|ct| ≤ f1(λ), |∆1,2,ct| ≤ f2(λ),

where k1, k2 ← KeyGen(1λ), (ct, ct) ← Encrypt(k1,m), and ∆1,2,ct ← ReKeyGen(k1, k2, ct). That is, the

lengths of the ciphertext header and update token are independent of the message length.

The correctness condition for an updatable encryption scheme is defined in a natural way.

Definition 4.3.3 (Correctness). We say that an updatable authenticated encryption scheme ΠUAE = (KeyGen,

Encrypt,ReKeyGen,ReEncrypt,Decrypt) for a message spaceM = (Mλ)λ∈N is correct if for any λ ∈ N,

N ∈ N and m ∈Mλ, we have

Pr[Decrypt(kN , (ctN , ctN )) = m

]= 1,

where k1, . . . , kN ← KeyGen(1λ), (ct1, ct1)← Encrypt(k1,m), and

(cti+1, cti+1)← ReEncrypt(ReKeyGen(ki, ki+1, cti), (cti, cti)

),

for i = 1, . . . , N − 1.

We note that the definition above requires that the correctness of decryption to hold even after unbounded

number of key updates. In theorem 4.4.1, we define a relaxation of this definition that requires correctness of

decryption for a bounded number of updates.


4.3.2 Prior Notions of Confidentiality

Standard semantic security for a symmetric encryption scheme requires that an encryption of a message does

not reveal any information about the message. In a regular symmetric encryption scheme, there exists only

one way to produce a ciphertext: via the encryption algorithm. In an updatable authenticated encryption

scheme, there exist two ways of producing a ciphertext: the encryption algorithm Encrypt that generates

fresh ciphertexts and the re-encryption algorithm ReEncrypt that generates re-encrypted ciphertexts. Previous

security formulations of updatable encryption capture the security of these algorithms in two separate security

experiments. The security of the regular encryption algorithm Encrypt is captured by the notion of message

confidentiality [28,66] while the security of the re-encryption algorithm ReEncrypt is captured by the notion

of re-encryption indistinguishability [66].

Both security experiments are divided into three phases, and are parameterized by h, the number of

honest keys, and d, the number of dishonest keys. During the setup phase of the security experiment, the

challenger generates h keys k1, . . . , kh ← KeyGen(1λ) that are kept private from the adversary, and d keys

kh+1, . . . , kh+d that are provided to the adversary. During the query phase of the experiment, the adversary

is given access to a set of oracles that evaluate the algorithms Encrypt, ReKeyGen, and ReEncrypt, allowing

the adversary to obtain ciphertexts under honest keys and rekey them.

The only distinction between the message-confidentiality and re-encryption indistinguishability exper-

iments is in the way we define the final challenge phase. In the message confidentiality experiment, the

adversary is given access to a challenge oracle where it can submit a pair of messages (m0,m1). As in a stan-

dard semantic security definition, the challenge oracle provides the adversary with an encryption of either

m0 or m1 under a specified honest key, and the adversary’s goal is to guess which of the messages was en-

crypted. In the re-encryption indistinguishability experiment, on the other hand, the adversary submits a pair

of ciphertexts((ct0, ct0), (ct1, ct1)

)of the same length to the challenge oracle and receives a re-encryption

of one of the ciphertexts. The adversary’s goal in the re-encryption indistinguishability experiment is to guess

which of the two ciphertexts was re-encrypted.

During the query phase of the experiment, the adversary can make queries to all four oracles as long

as their evaluations do not allow the adversary to “trivially” learn which messages are encrypted by the

challenge oracle. In particular, this means that no oracle will be allowed to rekey a challenge ciphertext from

an honest key to a dishonest key. To this end, the challenger in each experiment keeps a table of challenge

ciphertexts generated under each honest key and their re-encryptions. Much of the apparent complexity of

formalizing the definition arises from enforcing this straightforward check. We provide the full definitions of

Everspaugh et al. [66] for reference in Section 4.9.1

1The definitions that we present in Section 4.9 are actually simpler variants of the Everspaugh et al. [66] definitions. Our improve-ments to their definitions, presented in this section, are orthogonal to any simplifications that we make. See Section 4.9 for a fulldiscussion.


4.3.3 Improving Confidentiality

One property of an updatable authenticated encryption scheme that is not captured by the combination of

message confidentiality and re-encryption indistinguishability is hiding the number of times that a ciphertext

was re-encrypted, which contains information about the age of a ciphertext. Consider a UAE scheme where

the length of a ciphertext grows every time re-encryption is applied to the ciphertext. In such a scheme,

the length of a ciphertext reveals information about the number of times key rotation was carried out on

a ciphertext. However, this scheme can still suffice to satisfy re-encryption indistinguishability since the

adversary in the security experiment is always required to submit two challenge ciphertexts ct0, ct1 that have

the same size |ct0| = |ct1| and therefore the same age.

One natural way to rule out this type of UAE schemes is to simply require that any ciphertexts that are

produced by the encryption or re-encryption algorithm to always have fixed length. However, this strong

compactness property is still insufficient to completely hide the age of a ciphertext. For instance, take any

secure UAE scheme that satisfies message confidentiality and re-encryption indistinguishability, but modify

the encryption and re-encryption algorithms as follows:

• The encryption algorithm takes a message, applies the original encryption algorithm, but attaches the

bit 0 to the end of the final ciphertext.

• The re-encryption algorithm applies the original re-encryption algorithm (on all but the last bit), but

attaches the bit 1 to the end of the final ciphertext.

In this UAE scheme, the re-encryption algorithm does not modify the length of a given ciphertext. However,

the last of bit of a ciphertext completely reveals whether a ciphertext is a freshly generated ciphertext or

a re-encryption of an already existing ciphertext. This UAE scheme still satisfies message confidentiality

and re-encryption indistinguishability as the adversary in these security experiments is always required to

submit two fresh ciphertexts and two re-encrypted ciphertexts to the challenge oracle respectively. None

of the existing confidentiality experiments require an adversary to distinguish between fresh ciphertexts and

re-encrypted ciphertexts.

New confidentiality and strong compactness. To capture the additional security properties discussed above,

we define a new confidentiality security experiment (Definition 4.3.4) where the adversary can submit either

a message m0 or an existing ciphertext ct1 to the challenge oracle. The challenge oracle returns either a fresh

encryption of the message m0 or a re-encryption of the ciphertext ct1. If an adversary cannot distinguish be-

tween these two possible ciphertexts, then this implies that any re-encrypted ciphertexts are indistinguishable

from freshly generated ciphertexts.

Formalizing this experiment requires some care. To prevent trivial wins, we must also require an admis-

sibility condition that a fresh encryption of m0 and a re-encryption of ct1 results in ciphertexts of the same

length. For instance, we must forbid an adversary from submitting a ciphertext ct1 that encrypts a message

m1 for which |m0| 6= |m1| such that it can easily break the security game by observing the length of the


ExptconfΠUAE(λ, h, d,A, b):

k1, . . . , kh+d ← KeyGen(1λ)

b′ ← AO(kh+1, ..., kh+d)

Output b′ = b

OEncrypt(i,m):

Output Encrypt(ki,m)

OChallenge

(i, j,m, (ct, ct)

):

if j > h:

Output ⊥(ct′0, ct

′0)← Encrypt(kj ,m)

∆i,j,ct ← ReKeyGen(ki, kj , ct)

(ct′1, ct

′1)← ReEncrypt(∆i,j,ct, (ct, ct))

if (ct′0, ct

′0) = ⊥ or (ct

′1, ct

′1) = ⊥:

Output ⊥if |ct′0| 6= |ct

′1| or |ct′0| 6= |ct′1|:

Output ⊥T[j, ct

′b]← ct′b

Output (ct′b, ct

′b)

OReKeyGen(i, j, ct):

if j > h and T [i, ct] 6= ⊥:

Output ⊥∆i,j,ct ← ReKeyGen(ki, kj , ct)

if T [i, ct] 6= ⊥:

(ct′, ct′)← ReEncrypt

(∆i,j,ct, (ct,T[i, ct])

)T[j, ct

′]← ct′

Output ∆i,j,ct

OReEncrypt

(i, j, (ct, ct)

):



(∆i,j,ct, (ct, ct)

)if j > h and T[i, ct] 6= ⊥:

Output ⊥if j ≤ h and T[i, ct] 6= ⊥:

T[j, ct′]← ct′

Output (ct′, ct′)

Figure 4.1: Security experiment for confidentiality (theorem 4.3.4) and update independence (theorem 4.3.6)

resulting ciphertext. However, with this strict admissibility condition, the confidentiality security experiment

fails to rule out UAE schemes where the re-encryption algorithm modifies the length of a ciphertext.

Therefore, in addition to the new confidentiality experiment in Definition 4.3.4, we define an additional

strong compactness requirement (Definition 4.3.5), which enforces that the length of a ciphertext remains

a fixed length no matter how many times re-encryption is performed on the ciphertext. Both of these def-

initions must be satisfied to ensure a notion of confidentiality that hides ciphertext age. Conceptually, the

new confidentiality definition enforces that any freshly generated ciphertexts are indistinguishable from any

re-encrypted ciphertexts under the condition that these two ciphertexts are of the same length. The strong

compactness definition complements the new confidentiality requirement by enforcing that the length of a

ciphertext remains a fixed length no matter how many times a re-encryption was performed on the ciphertext.

We provide each of these two definitions below.

Definition 4.3.4 (Confidentiality). Let ΠUAE = (KeyGen,Encrypt,ReKeyGen,ReEncrypt,Decrypt) be an

updatable authenticated encryption scheme for a message space M = (Mλ)λ∈N. Then, for a security

parameter λ, positive integers h, d ∈ N, an adversary A, and a binary bit b ∈ 0, 1, we define the confi-

dentiality experiment ExptconfΠUAE(λ, h, d,A, b) and oraclesO = (OEncrypt,OReKeyGen,OReEncrypt,OChallenge) in


Figure 4.1. The experiment maintains a look-up table T, accessible by all the oracles, that maps key index

and ciphertext header pairs to ciphertext bodies.

We say that an updatable authenticated encryption scheme ΠUAE satisfies confidentiality if there exists a

negligible function negl(·) such that for all h, d ≤ poly(λ) and efficient adversaries A, we have∣∣∣Pr[ExptconfΠUAE

(λ, h, d,A, 0) = 1]− Pr

[ExptconfΠUAE

(λ, h, d,A, 1) = 1]∣∣∣ ≤ negl(λ).

Definition 4.3.5 (Strong Compactness). We say that an updatable authenticated encryption scheme ΠUAE =

(KeyGen,Encrypt,ReKeyGen,ReEncrypt,Decrypt) for a message spaceM = (Mλ)λ∈N is strongly com-

pact if for any λ ∈ N and any message m ∈Mλ, if we set

k0, k1, . . . , kN ← KeyGen(1λ)

(ct0, ct0)← Encrypt(k0,m)

for i ∈ [N ]:

∆i,i−1,cti−1← ReKeyGen(ki−1, ki, cti−1)

(cti, cti)← ReEncrypt(∆i,i−1,cti−1

, (cti−1, cti−1))

Then with probability 1, we have

• |cti| = |ctj | and |cti| = |ctj | for all 0 ≤ i, j ≤ N

• |∆i,i−1,cti−1| = |∆j,j−1,ctj−1

| for all 1 ≤ i, j ≤ N .

As discussed above, the original goal of the new confidentiality experiment above is to enforce the condition

that any re-encrypted ciphertexts are computationally indistinguishable from fresh ciphertexts. However, the

confidentiality experiment in Definition 4.3.4 captures a much wider class of confidentiality properties for a

UAE scheme. In fact, it is straightforward to show that a UAE scheme that satisfies the single confidential-

ity definition above automatically satisfies both message confidentiality (Definition 4.9.1) and re-encryption

indistinguishability (Definition 4.9.2), the separate security definitions for fresh and re-encrypted ciphertexts

in prior work [66]. Since the confidentiality definition above implies that an encryption of a message is indis-

tinguishable from a re-encryption of a ciphertext (given that the resulting ciphertexts are of the same length),

this implies that for any two messages m0,m1 such that |m0| = |m1|, we have

Encrypt(k,m0) ≈c (ct′, ct′) ≈c Encrypt(k,m1),

for any key k that is hidden from an adversary and any re-encrypted ciphertext (ct′, ct′) of appropriate length.

Similarly, the confidentiality definition above implies that for two ciphertexts (ct0, ct0) and (ct1, ct1) of the

same length,

ReEncrypt(ReKeyGen(k, k′, ct0),(ct0, ct0)

)≈c (ct

′, ct′) ≈c ReEncrypt

(ReKeyGen(k, k′, ct1), (ct1, ct1)

),


for an appropriate key k′ that is hidden from an adversary and any fresh ciphertext (ct′, ct′) of appropriate

length.

In combination with our new strong compactness requirement in Definition 4.3.5, the security experiment

in theorem 4.3.4 captures all the confidentiality properties we expect from an updatable encryption scheme.

This is why we refer to the experiment in theorem 4.3.4 simply as the “confidentiality” experiment.

Intuition

As discussed in Section 4.1, the main motivation behind updatable encryption is to facilitate periodic key

rotations on ciphertexts that are outsourced to a remote server. In the event that a key is compromised,

regular key rotation limits the amount of data that is vulnerable to compromise. Key rotation can also be used

to revoke a user’s access to encrypted data by updating the ciphertext with a newly generated key. Therefore,

when reasoning about confidentiality in updatable encryption, it is useful to consider adversaries that have

access to the previous keys and previous versions of a newly updated challenge ciphertext. In an updatable

encryption, any newly re-encrypted ciphertext must be indistinguishable from a freshly generated ciphertext

even to adversaries that had key-access to previous versions of a ciphertext.

This security property can be subtle. If an adversary already had access to a previous version of a ci-

phertext and its key, then it already has access to the entire data in the ciphertext. On first sight, it can be

unclear what security property an updatable encryption provides with respect to any newly updated cipher-

texts. For this, it is useful to reason about highly evolving data that is stored on a remote server. Suppose

that an adversary compromises a key for some data that is encrypted in a remote server. This means that the

adversary does have access to the snapshot of the entire data at the time of the compromise. However, once

the data evolves and the ciphertext is re-encrypted with a fresh key, the adversary should not have access to

any new version (snapshot) of the data. The same principle applies if the data is static but the adversary did

not exfiltrate all the data when it had a chance to do so.

Below, we discuss two natural but insecure updatable encryption schemes that violate our notion of con-

fidentiality in Definition 4.3.4. These schemes also fail to satisfy the security definitions of prior work. In

Section 4.4, we describe a scheme that does satisfy previous security definitions but does not satisfy ours.

Hybrid Encryption. One natural way to construct an updatable encryption is via a hybrid encryption. Let

ΠAE = (AE.KeyGen,AE.Encrypt,AE.Decrypt) be an authenticated encryption scheme with message space

M.

• KeyGen(1λ): Sample khdr ← AE.KeyGen(1λ) and return k = khdr.

• Encrypt(k,m): Sample kbody ← AE.KeyGen(1λ) and set

– ct← AE.Encrypt(khdr, kbody),

– ct← AE.Encrypt(kbody,m).


• ReKeyGen(k1, k2, ct): Given k1 = khdr,1 and k2 = khdr,2, set

∆ = AE.Encrypt(khdr,2,AE.Decrypt(khdr,1, ct)).

• ReEncrypt(∆, (ct, ct)): Given ∆ = ct′, return (ct

′, ct) as the updated ciphertext.

• Decrypt(k, (ct, ct)): Given k = khdr, let kbody ← AE.Decrypt(khdr, ct) and return AE.Decrypt(kbody, ct).

In this scheme, an AE key kbody is used to encrypt the message, and the resulting ciphertext is the ciphertext

body ct. The AE key kbody is then encrypted by another AE key khdr, which forms the ciphertext header ct.

Each key rotation then consists of simply downloading the ciphertext header ct and re-encrypting it with a

new AE key k′hdr.

By the security of the authenticated encryption scheme, as long as an adversary does not know a valid

decryption key for a challenge ciphertext or any previous version of the challenge ciphertext, the hybrid en-

cryption above is a secure updatable encryption. However, any adversary that has access to a valid decryption

key for a previous version of a challenge ciphertext can easily decrypt the challenge ciphertext since it knows

the fixed AE key kbody, which is never rotated.

In the context of Definition 4.3.4, an adversary can easily win the security game by generating a ciphertext

using one of the dishonest encryption keys that it has access to and then submitting that ciphertext as part

of its challenge to the challenge oracle. Since the adversary knows kbody of the ciphertext that it generated,

it can decrypt any re-encryption of this ciphertext. Therefore, the hybrid encryption above is insecure as an

updatable encryption.

Insecure nested construction. Another natural way to construct an updatable encryption scheme is to nest

multiple layers of encryption.

• KeyGen(1λ): Sample khdr ← AE.KeyGen(1λ) and return k = khdr.

• Encrypt(k,m): Sample kinner, kouter ← AE.KeyGen(1λ) and set

– ct← AE.Encrypt(khdr, (kouter, kinner)),

– ct← AE.Encrypt(kouter,AE.Encrypt(kinner,m)).

• ReKeyGen(k1, k2, ct): Given k1 = khdr,1 and k2 = khdr,2, first decrypt

(kouter, kinner)← AE.Decrypt(khdr,1, ct)

and sample a new k′outer ← AE.KeyGen(1λ). Then, set

ct′

= AE.Encrypt(khdr,2, (k′outer, kinner))

and output ∆← (ct′, kouter, k

′outer).


• ReEncrypt(∆, (ct, ct)): Given ∆ = (ct′, kouter, k

′outer), compute

ct′ ← AE.Encrypt(k′outer,AE.Decrypt(kouter, ct)).

Return (ct′, ct′) as the updated ciphertext.

• Decrypt(k, (ct, ct)): Given k = khdr, let (kouter, kinner)← AE.Decrypt(khdr, ct) and return

AE.Decrypt(kinner,AE.Decrypt(kouter, ct)).

Now an adversary that has access to an old key and an old version of the ciphertext can still learn kinner, but it

cannot decrypt an updated ciphertext as it does not know kouter. However, if the adversary can gain access to

just the most recent update token, it can learn kouter and still decrypt the plaintext. The security of updatable

encryption requires that an adversary learns nothing about a new ciphertext even when it gains access to any

old versions of a challenge ciphertext, valid decryption keys for any of the old versions of the ciphertext, and

all but one of subsequent update tokens. Therefore, the nested construction above is insecure as an updatable

encryption scheme.

An attack on the scheme in the context of Definition 4.3.4 is more subtle. To win the security game,

an attacker first generates a ciphertext using one of the dishonest encryption keys that it has access to and

makes note of the key kouter. It submits that ciphertext as part of its challenge to the challenge oracle. Next,

it re-encrypts the challenge ciphertext under another honest key, using the ReKeyGen oracle to get an update

token (ct′, k∗outer, k

′outer). If k∗outer = kouter, then the adversary knows that the ciphertext it submitted was the

one chosen by the challenge oracle and can win the game.

In Section 4.4, we show how to properly construct an updatable encryption scheme by nesting multiple

layers of encryption.

Update independence

In Construction 4.4.2, we present a UAE scheme that satisfies the strong compactness property of theo-

rem 4.3.5 as well as the message confidentiality (Definition 4.9.1) and re-encryption indistinguishability

(Definition 4.9.2) definitions from prior work, but does not fully satisfy the stronger notion of confidential-

ity as defined in theorem 4.3.4. Therefore, we define a slight relaxation of the confidentiality requirement

as formulated in theorem 4.3.4 that we call update independence and show that Construction 4.4.2 satisfies

this security definition. An update independence security experiment is defined identically to the confiden-

tiality security experiment but without the re-encryption key generation oracle OReKeyGen. Since this oracle

is removed, update independence does not suffice to imply message confidentiality and re-encryption in-

distinguishability on its own, whereas our stronger confidentiality definition above implies both. However,

update independence still suffices to guarantee that fresh ciphertexts are indistinguishable from re-encrypted

ciphertexts as long as update tokens are hidden from an adversary.


Definition 4.3.6 (Update Independence). Let ΠUAE = (KeyGen,Encrypt,ReKeyGen,ReEncrypt,Decrypt)

be an updatable authenticated encryption scheme for a message spaceM = (Mλ)λ∈N. Then, for a security

parameter λ, positive integers h, d ∈ N, an adversary A, and a binary bit b ∈ 0, 1, we define the update

independence experiment Exptupd-indΠUAE

(λ, h, d,A, b) and oracles O = (OEncrypt,OReEncrypt,OChallenge) as in

Figure 4.1 with the OReKeyGen oracle omitted. The experiment maintains a look-up table T, accessible by all

the oracles, that maps key index and ciphertext header pairs to ciphertext bodies.

We say that an updatable authenticated encryption scheme ΠUAE satisfies update independence if there

exists a negligible function negl(·) such that for all h, d ≤ poly(λ) and efficient adversaries A, we have∣∣∣Pr[Exptupd-ind

ΠUAE(λ, h, d,A, 0) = 1

]− Pr

[Exptupd-ind

ΠUAE(λ, h, d,A, 1) = 1

]∣∣∣ ≤ negl(λ).

In combination with the message confidentiality and re-encryption indistinguishability properties, this

relaxed requirement of update independence suffices for many practical scenarios. Since update tokens are

generally sent over secure channels (e.g. TLS connection) from a client to a server, no malicious eavesdrop-

per can gain access to them. For malicious servers that have access to update tokens, on the other hand,

hiding how many times a re-encryption operation was previously applied on a ciphertext is less useful since

the storage metadata of the ciphertexts already reveal this information to the server. In essence, update in-

dependence, when combined with message confidentiality and re-encryption indistinguishability, seems to

satisfy the two properties we wanted from our new confidentiality definition without the convenient benefit

of a single unified definition.

4.3.4 Integrity

The final security property that an updatable authenticated encryption scheme must provide is ciphertext

integrity. The ciphertext integrity experiment for UAE is analogous to the standard ciphertext integrity ex-

periment of an authenticated encryption scheme. As in the confidentiality experiment, the challenger starts

the experiment by generating a set of honest keys, which are kept private from the adversary, and dishonest

keys, which are provided to the adversary. Then, given oracle access to OEncrypt, OReEncrypt, and OReKeyGen,

the adversary’s goal is to generate a new valid ciphertext that was not (1) previously output by OEncrypt or

OReEncrypt, and (2) cannot be trivially derived via update tokens output by OReKeyGen.

Our integrity definition is similar to that of Everspaugh et al. [66] (rewritten in Section 4.9), except the

previous definition does not include the re-encryption oracle OReEncrypt, which we add. Giving the adver-

sary access to a re-encryption oracle captures scenarios that are not covered by the previous definition. For

instance, security with respect to our stronger integrity experiment guarantees that an adversary who com-

promises the key for a ciphertext cannot tamper with the data after the key has been rotated and the data

re-encrypted.


ExptintΠUAE(λ, h, d,A):

k1, . . . , kh+d ← KeyGen(1λ)

(i, (ct, ct))← AO(kh+1, ..., kh+d)

if i > h:

Output 0

m← Decrypt(ki, (ct, ct)

)if m = ⊥ or T[i, ct] = ct:

Output 0

else:

Output 1

OEncrypt(i,m):

(ct, ct)← Encrypt(ki,m)

T[i, ct]← ct

Output (ct, ct)

OReEncrypt

(i, j, (ct, ct)

):




)if j ≤ h:




if i > h and j ≤ h:


if T[i, ct] 6= ⊥:



)T[j, ct

′]← ct′

Output ∆i,j,ct

Figure 4.2: Security experiment for integrity (theorem 4.3.7)

Definition 4.3.7 (Integrity). Let ΠUAE = (KeyGen,Encrypt,ReKeyGen,ReEncrypt,Decrypt) be an updat-

able authenticated encryption scheme for a message space M = (Mλ)λ∈N. Then, for a security param-

eter λ, positive integers h, d ∈ N, and an adversary A, we define the re-encryption integrity experiment

ExptintΠUAE(λ, h, d,A) and oracles O = (OEncrypt,OReKeyGen,OReEncrypt) in Figure 4.2. The experiment main-

tains a look-up table T, accessible by all the oracles, that maps key index and ciphertext header pairs to

ciphertext bodies.

We say that an updatable authenticated encryption scheme ΠUAE satisfies re-encryption integrity if there

exists a negligible function negl(·) such that for all h, d ≤ poly(λ) and any efficient adversary A, we have

Pr[ExptintΠUAE

(λ, h, d,A) = 1]≤ negl(λ).

Although our UAE construction in section 4.4 can be shown to satisfy the strong notion of integrity formulated

above, the construction in section 4.5 that relies on almost key-homomorphic PRFs is not sufficient to satisfy

the stronger notion. In section 4.5, we formulate a relaxation of the notion of integrity that we call relaxed

integrity and show that Construction 4.5.2 satisfies this weaker variant.

4.4 UAE with Bounded Updates

We begin this section by presenting an insecure UAE scheme that demonstrates the importance of the new

definitions presented in Section 4.3. This scheme leaks the age of ciphertexts but nonetheless satisfies all


security definitions for ciphertext-dependent UAE from prior work.

Next, we extend the insecure scheme to hide the age of ciphertexts, thereby satisfying the definition of

update independence (Section 4.3.3, theorem 4.3.6). This upgrade comes at the cost of relaxing the correct-

ness requirement of an updatable encryption scheme: the correctness of decryption is guaranteed only for an

a priori bounded number of key updates.

4.4.1 A Simple Nested Construction

In this section, we provide a simple updatable authenticated encryption scheme using any authenticated en-

cryption scheme. Our simple construction inherently leaks information about the message; namely, the con-

struction leaks how many re-encryption operations were previously performed on a given ciphertext, thereby

leaking information about the age of the encrypted message. Despite this information leakage, the construc-

tion satisfies all the UAE security definitions of Everspaugh et al. [66]. Hence, this construction demonstrates

that prior security definitions did not yet capture all the necessary security properties that an updatable en-

cryption scheme must provide.

The construction uses an authenticated encryption (AE) scheme. A key for this UAE scheme is a standard

AE key k, which we call the header key. The UAE encryption algorithm implements standard chained

encryption. To encrypt m using k, first generate a fresh body key kae and then encrypt the plaintext ct ←AE.Encrypt(kae,m). Next, the body key kae is encrypted under the header key ct ← AE.Encrypt(k, kae) to

form the ciphertext header. Finally, output the UAE ciphertext (ct, ct).

To update a ciphertext, the client and server proceed as follows:

• Client: The client downloads the ciphertext header ct to recover the body key kae. It then generates

fresh header and body keys k′ and k′ae, and sends a new ciphertext header ct′ ← AE.Encrypt(k′, (k′ae, kae)

)along with k′ae to the server.

• Server: The server replaces the old ciphertext header ct with the new header ct′. It also generates a

new ciphertext body by encrypting the original ciphertext as ct′ ← AE.Encrypt(k′ae, (ct, ct)

).

Now, even with many such key updates, the client can still recover the original ciphertext. Specifically, the

client can first use its current header key k to decrypt the ciphertext header and recover a body key kae and the

old header key k′. It uses kae to remove the outer layer of encryption and recover the old ciphertext (ct′, ct′).

The client repeats the same procedure with the old header key k′ and the old ciphertext (ct′, ct′). Note that

decryption time grows linearly in the number of re-encryption operations.

To prove security, we must introduce an additional step during a ciphertext update. Namely, instead of set-

ting the new ciphertext body as the encryption of the old ciphertext header and body ct′ ← AE.Encrypt(k′ae, (ct, ct)

),

the server replaces ct with a new ciphertext header cthistory that the client provides to the server encrypted

under a new key khistory. The main intuition of the construction, however, remains unchanged from the de-

scription above. Since the construction is a simpler form of the one formalized in Construction 4.4.2, we

defer the formal statement of the construction and its associated security theorems for strong compactness,


correctness, update independence, message confidentiality, re-encryption indistinguishability, and ciphertext

integrity to Section 4.11.

4.4.2 Bounded Correctness

We now define a variation of correctness that we call bounded correctness. The bounded correctness condition

is defined in a natural way and analogously to theorem 4.3.3 (correctness). However, we do modify the syntax

of the key generation algorithm KeyGen to additionally take in a parameter t ∈ N that specifies an upper

bound on the number of key updates that a scheme can support. This allows the key generator to flexibly set

this parameter according to its needs.

Definition 4.4.1 (Bounded Correctness). We say that an updatable authenticated encryption scheme ΠUAE =

(KeyGen,Encrypt,ReKeyGen,ReEncrypt,Decrypt) for a message spaceM = (Mλ)λ∈N satisfies bounded

correctness if for any λ, t ∈ N, and m ∈Mλ, we have (with probability 1)

Pr[Decrypt(kt, (ctt, ctt)) = m

]≥ 1− negl(λ),

where k1, . . . , kt ← KeyGen(1λ, 1t), (ct1, ct1)← Encrypt(k1,m), and


),

for i = 1, . . . , t− 1.

4.4.3 Nested Construction with Padding

Our modification of the nested construction is straightforward: we pad the ciphertexts such that as long as

the number of key updates is bounded, their lengths are independent of the number of key updates that are

performed on the ciphertexts. However, executing this simple idea requires some care. First, padding the

(original) ciphertexts with structured strings reveals information about how many updates were previously

performed on the ciphertexts. Therefore, we modify the encryption algorithm such that it pads the ciphertexts

with random strings. If the underlying authenticated encryption scheme satisfies ciphertext pseudorandom-

ness (theorem 4.2.10), an adversary cannot determine which component of a ciphertext corresponds to the

original ciphertext and which component corresponds to a pad.2

However, simply padding the (original) ciphertexts with random strings also makes them highly malleable

and easy to forge. To achieve integrity, we modify the encryption and re-encryption algorithms to additionally

sample a pseudorandom generator (PRG) seed and include it as part of the UAE ciphertext header. The

encryption and re-encryption algorithms then generate the ciphertext pads from an evaluation of the PRG. By

2As discussed in section 4.2.3, authenticated encryption schemes that satisfy pseudorandomness can be constructed from pseudo-random functions or block ciphers in a standard way. Widely-used modes for authenticated encryption such as AES-GCM also satisfypseudorandomness.


PRG security, the original ciphertext components and the pads are still computationally indistinguishable to

an adversary, but now the adversary cannot easily forge ciphertexts as the decryption algorithm can verify the

validity of a pad using the PRG seed.

The only remaining issue is correctness. Since the ciphertexts of our UAE scheme are pseudorandom, the

re-encryption algorithm also does not have information about where the original ciphertext ends and padding

begins. Therefore, we include this information as part of the re-encryption key (update token). This is the

reason why this scheme satisfies update independence instead of our full confidentiality definition – even

though ciphertexts fully hide their age, update tokens reveal information about the age of the ciphertext they

are updating. The re-encryptor can now apply the re-encryption on the original ciphertext and adjust the

padding length accordingly. We formalize the construction below.

Construction 4.4.2 (Nested Authenticated Encryption). Our construction uses the following building blocks:

• An authenticated encryption scheme ΠAE = (KeyGen,Encrypt,Decrypt) with message space M =

(Mλ)λ∈N. We additionally assume that AE.Encrypt satisfies εrandae -ciphertext pseudorandomness, i.e.,

that encryptions under AE are indistinguishable from random strings.

For the construction description below, we let ρ = ρλ denote the maximum size of an authenticated

encryption key and we let ν = poly(λ) be an additive overhead incurred by the encryption algorithm.

For any key kae ← AE.KeyGen(1λ) and any message m ∈Mλ, we have |kae| = ρ and |ct| ≤ |m|+ ν,

where ct← AE.Encrypt(kae,m).

• A pseudorandom generator G : 0, 1λ → 0, 1∗. To simplify the presentation of the construction,

we assume that G has unbounded output that is truncated to the required length on each invocation.

We construct an updatable authenticated encryption scheme ΠUAE = (KeyGen,Encrypt,ReKeyGen,ReEncrypt,

Decrypt) for message spaceM = (Mλ)λ∈N in Figure 4.3.

We formally state the strong compactness, correctness, and security properties of Construction 4.4.2 in the

following theorem. We provide the formal proof in section 4.13.

Theorem 4.4.3. Suppose the authenticated encryption scheme ΠAE satisfies correctness, εconfae -confidentiality,

εintae -integrity, and εrandae -ciphertext pseudorandomness, and G satisfies εprg PRG security. Then the updatable

authenticated encryption scheme ΠUAE in Construction 4.4.2 satisfies strong compactness, correctness, up-

date independence, message confidentiality, and re-encryption indistinguishability.

For confidentiality, we have the following concrete security bounds for all h, d = poly(λ) and efficient

adversaries A that make at most Q oracle queries:

∣∣∣Pr[Exptupd-ind

ΠUAE(λ, h, d,A, 0) = 1

]− Pr

[Exptupd-ind

ΠUAE(λ, h, d,A, 1) = 1

]∣∣∣≤ 2h · εconfae (λ) + 2h · εintae (λ) + 2Q · εprg(λ) + 4Q · εrandae (λ)


KeyGen(1λ, 1t):

k← AE.KeyGen(1λ)

k← (k, t)

Output k

Encrypt(k,m)

(k, t)← k

kae ← AE.KeyGen(1λ)

s←R 0, 1λ

ctpayload ← AE.Encrypt(kae,m)

ctpad ← G(s) such that ctpad ∈ 0, 1t·(2ρ+ν)

ct← AE.Encrypt(k, (s, |ctpayload|, kae,⊥))

ct← (ctpayload, ctpad)

Output (ct, ct)

ReKeyGen(k1, k2, ct):

(k1, t)← k1

(k2, t)← k2

(s, `, kae, khistory)← AE.Decrypt(k1, ct)

if (s, `, kae, khistory) = ⊥, output ⊥k′history ← AE.KeyGen(1λ)

cthistory ← AE.Encrypt(k′history, (kae, khistory))

k′ae ← AE.KeyGen(1λ)

s′ ←R 0, 1λ

`′ ← `+ |cthistory|ct′ ← AE.Encrypt

(k2, (s

′, `′, k′ae, k′history)

)∆1,2,ct ← (ct

′, cthistory, `, k

′ae, s

′)

Output ∆1,2,ct

ReEncrypt(∆1,2,ct, (ct, ct)

):

(ct′, cthistory, `, k

′ae, s

′)← ∆1,2,ct

(ctpayload, ctpad)← ct ∈ 0, 1` × 0, 1|ct|−`

if |ct| < `, output ⊥ct′payload ← AE.Encrypt

(k′ae, (ctpayload, cthistory)

)if |ct′payload| > |ct|, output ⊥ct′pad ← G(s′)

[1, ..., |ct| − |ct′payload|

]ct′ ← (ct′payload, ct

′pad) ∈ 0, 1|ct|


Decrypt(k, (ct, ct)

):

(k, t)← k

(s, `, k′ae, k′history)← AE.Decrypt(k, ct)

if (s, `, k′ae, k′history) = ⊥, output ⊥

if |ct| < `, output ⊥(ctpayload, ctpad)← ct ∈ 0, 1` × 0, 1|ct|−`

ct′pad ← G(s) such that |ct′pad| = |ctpad|if ct′pad 6= ctpad, output ⊥

(ct′, ct′history)← AE.Decrypt(k′ae, ctpayload)

if (ct′, ct′history) = ⊥, output ⊥

while k′history 6= ⊥:

kae ← k′ae

khistory ← k′history

ct← ct′

cthistory ← ct′history

(k′ae, k′history)← AE.Decrypt(khistory, cthistory)

if (k′ae, k′history) = ⊥, output ⊥

(ct′, ct′history)← AE.Decrypt(kae, ct)

if (ct′, ct′history) = ⊥, output ⊥

m← AE.Decrypt(k′ae, ct′)

Output m

Figure 4.3: Our nested scheme.

∣∣∣Pr[Exptmsg-conf

ΠUAE(λ, h, d,A, 0) = 1

]− Pr

[Exptmsg-conf

ΠUAE(λ, h, d,A, 1) = 1

]∣∣∣≤ (2h+ 4Q) · εconfae (λ) + 2h · εintae (λ)


∣∣∣Pr[Exptre-enc-ind

ΠUAE(λ, h, d,A, 0) = 1

]− Pr

[Exptre-enc-ind

ΠUAE(λ, h, d,A, 1) = 1

]∣∣∣≤ (2h+ 4Q) · εconfae (λ) + 2h · εintae (λ)

For integrity, we have the following bound for all h, d = poly(λ) and efficient adversaries A that make

at most Q challenge, ReKeyGen, or ReEncrypt queries:

Pr[ExptintΠUAE

(λ, h, d,A) = 1]≤ (h+Q) · εintae (λ) + (h+Q) · εconfae (λ) +Q/2λ

4.5 UAE from Key-Homomorphic PRFs

In this section, we generalize the updatable authenticated encryption construction of Everspaugh et al. [66]

that is built from a perfectly key-homomorphic PRF to also work using an almost key-homomorphic PRF.

We do this by incorporating a plaintext encoding scheme into the construction such that encrypted messages

can still be decrypted correctly after noisy key rotations. We show that this generalized UAE construction

satisfies our notion of confidentiality (theorem 4.3.4), but only satisfies a relaxed integrity property.

4.5.1 Encoding Scheme

Our construction of an updatable authenticated encryption scheme relies on an almost key-homomorphic PRF

for which key-homomorphism holds under small noise. To cope with the noise in our updatable encryption

scheme in section 4.5.2, we must encode messages prior to encrypting them such that they can be fully

recovered during decryption. A simple way of encoding the messages is to pad them with additional least-

significant bits. However, more sophisticated ways of encoding the messages are possible with general error-

correcting codes. In our construction description in section 4.5.2, we use the syntax of a general encoding

scheme that is described in Fact 4.5.1 below. In section 4.7, we test the performance of our construction

in section 4.5.2 with simple padding.

Fact 4.5.1. Let n, q, γ be positive integers such that γ < q/4, µ = µ(λ) be a polynomial in λ, and

M =(0, 1µ(λ)

)λ∈N be a message space. Then there exists a set of algorithms (Encode,Decode) with

the following syntax:

• Encode(m) → (m1, . . . ,m`): On input a message m ∈ Mλ, the encoding algorithm returns a set of

vectors m1, . . . ,m` ∈ Znq for some ` ∈ N.

• Decode(m1, . . . ,m`) → m: On input a set of vectors m1, . . . ,m` ∈ Znq , the decoding algorithm

returns a message m ∈Mλ.


KeyGen(1λ, 1t):

k← AE.KeyGen(1λ)

Output k


µ← AE.Decrypt(k1, ct)

if µ = ⊥, output ⊥(kprf , h)← µ

k′prf ←R KPRF

kupprf ← k′prf − kprf

ct′ ← AE.Encrypt

(k2, (k

′prf , h)

)∆1,2,ct ← (ct

′, kupprf)


):

(ct′, kupprf)← ∆1,2,ct

(ct1, . . . , ct`)← ct

for i ∈ [`]:

ct′i ← cti + F (kupprf , i)

ct′ ← (ct′1, . . . , ct′`)


Encrypt(k,m)

(m1, . . . ,m`)← Encode(m)

kprf ←R KPRF

h← H(m)

ct← AE.Encrypt(kae, (kprf , h)

)for i ∈ [`]:

cti ← mi + F (kprf , i)

ct = (ct1, . . . , ct`)

Output (ct, ct)

Decrypt(k, (ct, ct)

):

µ← AE.Decrypt(k, ct)

if µ = ⊥, output ⊥(kprf , h)← µ

(ct1, . . . , ct`)← ct

for i ∈ [`]:

mi ← cti − F (kprf , i)

m′ ← Decode(m1, . . . ,m`)

if H(m′) = h, output m′

else, output ⊥

Figure 4.4: Our UAE from almost Key-Homomorphic PRFs.

The algorithms (Encode,Decode) satisfy the following property: for all strings m ∈ Mλ and any error

vectors e = e1, . . . , e` ∈ [γ]n, if we set (m1, . . . ,m`)← Encode(m), we have

Decode(m1 + e1, . . . ,m` + e`) = m.

Due to the use of an encoding scheme, our construction can be viewed as supporting only a bounded

number of updates – the encoding can only support so much noise before decoding fails. However, for our

almost key-homomorphic PRF construction in section 4.5.2, a simple padding scheme can be used as the

encoding scheme. In this case, the bound on the number of updates grows exponentially in the size of the

parameters of the scheme and therefore, the construction can be interpreted as permitting unbounded updates.

4.5.2 Construction

We next present our UAE scheme from an almost key-homomorphic PRF. We analyze its security in the next

two subsections.


Construction 4.5.2 (UAE from almost Key-Homomorphic PRFs). Let n, q, γ, and β be positive integers.

Our construction uses the following:

• A standard authenticated encryption scheme ΠAE = (AE.KeyGen,AE.Encrypt,AE.Decrypt) with mes-

sage spaceM = (Mλ)λ∈N.

• A β-almost key-homomorphic PRF F : KPRF × 0, 1∗ → Znq where (KPRF,+) and (Znq ,+) form

groups.

• A collision resistant hash familyH =H :Mλ → 0, 1λ

. To simplify the construction, we assume

that a description of a concrete hash functionH ←R H is included in each algorithm as part of a global

set of parameters.

• An encoding scheme (Encode,Decode) that encodes messages in (M, λ)λ∈N as elements in Znq . The

Decode algorithm decodes any error vectors e ∈ [γ]n as in Fact 4.5.1 for any fixed γ = β · λω(1).


Decrypt) for message space (Mλ)λ∈N in Figure 4.4.

4.5.3 Security Under Relaxed Integrity

We will show in the next subsection that neither Construction 4.5.2 nor the construction of Everspaugh et al. [66]

satisfy our integrity definition. To prove security of either scheme we must relax the notion of integrity in

theorem 4.3.7 to obtain what we call relaxed integrity. In this section we define relaxed integrity and then

prove security of Construction 4.5.2. In the next subsection we discuss the implications of relaxed integrity

to the security of the scheme in practice.

The relaxed integrity experiment modifies theorem 4.3.7 (integrity) in two ways. First, we require that

an adversary’s queries to the re-encryption oracle are well-formed ciphertexts that do not decrypt to “⊥”.

Without this restriction, there is an attack on both Construction 4.5.2 and the Everspaugh et al. [66] scheme,

as we will discuss below.

Second, we modify the adversary’s winning condition in the integrity game. When we use an almost

key-homomorphic PRFs to instantiate Construction 4.5.2, any re-encryption incurs a small error that affects

the low-order bits of the ciphertext. Therefore, to achieve correctness, we encrypt an encoding of a message

(Fact 4.5.1) such that the decryption algorithm can still recover the full message even if the low-ordered bits

are corrupted. This forces the construction to violate traditional ciphertext integrity as an adversary can forge

new ciphertexts by adding noise to the low-order bits of a ciphertext. Our construction still guarantees that an

adversary cannot generate new ciphertexts by modifying plaintexts or the high-order bits of ciphertexts. To

capture this formally, we require that the ciphertext space CT associated with the UAE has a corresponding

metric function d : CT ×CT → Z (e.g., Euclidean distance) that gives a distance between any two ciphertexts.

Then, in our relaxed integrity definition that is parameterized with a positive integer γ ∈ N, an adversary wins


the security experiment only if it produces a valid ciphertext that differs from any of the ciphertexts that it is

given by more than γ.

The rest of the definition of relaxed integrity exactly matches theorem 4.3.7. We present the formal

definition of relaxed integrity in Section 4.12.

Security. The following theorem states the compactness, correctness, and security properties of Construc-

tion 4.5.2. The proof is presented in Section 4.14.

Theorem 4.5.3. Let ΠUAE be the updatable authenticated encryption scheme in Construction 4.5.2. If the

authenticated encryption scheme ΠAE satisfies correctness, εconfae -confidentiality and εintae -integrity, F : KPRF×0, 1∗ → Y satisfies εprf -security, and H :Mλ → 0, 1λ is a εcr-secure collision resistant hash function,

then ΠUAE satisfies strong compactness, correctness, confidentiality, and γ-relaxed integrity.

For confidentiality, we have the following concrete security bounds for all h, d = poly(λ) and efficient

adversaries A that make at most Q challenge queries:∣∣∣Pr[ExptconfΠUAE

(λ, h, d,A, 0) = 1]− Pr

[ExptconfΠUAE

(λ, h, d,A, 1) = 1]∣∣∣

≤ 2h · εconfae (λ) + 2h · εintae (λ) + 2Q · εprf(λ)

For integrity, we have the following bound for all h, d = poly(λ) and efficient adversaries A:

Pr[Exptrelaxed-int

ΠUAE(λ, h, d, γ,A) = 1

]≤ h · εintae (λ) + εcr(λ)

We note that when we instantiate Construction 4.5.2 with a perfect key-homomorphic PRF, we can use the

trivial encoding scheme for γ = 0.

4.5.4 Consequences of Relaxed Integrity

The relaxed integrity definition from section 4.5.3 places two restrictions on the adversary relative to our full

integrity definition (theorem 4.3.7). We discuss these two restrictions and their implications below.

Weakened Re-encryption oracle. The first restriction of relaxed integrity is the weakened re-encryption

oracle, which only re-encrypts well-formed ciphertexts. This relaxation of the definition is necessary to

prove security of Construction 4.5.2 as there exists a simple adversary that breaks the integrity experiment

when it is provided arbitrary access to the re-encryption oracleOReEncrypt. This attack applies equally well to

the construction of Everspaugh et al. [66].

To carry out the attack, the adversary does the following:

1. Uses encryption oracle OEncrypt to receive a ciphertext (ct, ct) ← OEncrypt(i,m) for a message m ∈Mλ and an honest key index i. For simplicity, suppose that the message m is encoded as a single

vector in Znq : Encode(m) ∈ Znq and therefore, ct ∈ Znq .


2. Subtracts an arbitrary vector m′ from the ciphertext body ct← ct−m′.

3. Submits the ciphertext (ct, ct) to the re-encryption oracleOReEncrypt to receive a new ciphertext (ct′, ct′)←

OReEncrypt

(i, j, (ct, ct)

)for an honest key index j.

4. Returns (ct′, ct′+ m′) as the ciphertext forgery.

Since the re-encryption algorithm is homomorphic, we have

OReEncrypt(i, j, ct, ct−m′) + m′ = OReEncrypt(i, j, ct, ct),

where “+m′” is interpreted as adding m′ to the ciphertext body. Therefore, the ciphertext (ct′, ct′+ m) is

a valid forgery. This attack is ruled out in the relaxed integrity experiment, where the re-encryption oracle

OReEncrypt outputs a re-encrypted ciphertext only when the input ciphertexts are well-formed.

To carry out the attack above, an adversary must have arbitrary access to a re-encryption oracle. There-

fore, Construction 4.5.2 still provides security against any active adversary that has arbitrary access to the

decryption oracle, but only observes key rotations on well-formed ciphertexts. For applications where an

adversary (e.g. a corrupted server) gains arbitrary access to the re-encryption oracle, Construction 4.5.2

provides passive security as opposed to active security. This also applies to [66].

Handling noise. The second restriction imposed on the adversary is needed due to the noise allowed in Con-

struction 4.5.2. In particular, the encoding scheme used in the construction allows an adversary to create new

ciphertexts by adding small amounts of noise to an existing ciphertext. In combination with the decryption

oracle, an adversary can take advantage of this property to gain information about the age of a ciphertext

using a chosen ciphertext attack. Namely, an adversary can take a ciphertext and incrementally add noise to

it before submitting the ciphertext to the decryption oracle. Based on how much noise an adversary can add

to the ciphertext before the decryption oracle returns⊥, the adversary can approximate the relative size of the

noise in the ciphertext. Since each key rotation in increases the noise associated with a ciphertext by a fixed

amount, an adversary can gain information about the age of the ciphertext by learning the size of the noise in

the ciphertext. Hence, the age of a ciphertext can be exposed using a chosen ciphertext attack.

For applications where the age of a ciphertext is not sensitive information, Construction 4.5.2 can be used

as an efficient alternative to existing UAE schemes. When combined with confidentiality (theorem 4.3.4), the

relaxed integrity definition provides an “approximate” analogue of the traditional chosen-ciphertext security.

To see this, take any CCA-secure encryption scheme ΠEnc and modify it into a scheme Π′Enc that is identical to

ΠEnc, but the encryption algorithm appends a bit 0 to every resulting ciphertext, and the decryption algorithm

discards the last bit of the ciphertext before decrypting. The scheme Π′Enc is no longer CCA-secure as an

adversary can take any ciphertext and flip its last bit to produce different valid ciphertext. However, the

introduction of the last bit does not cause the scheme Π′Enc to be susceptible to any concrete attack that

violates security. Similarly, Construction 4.5.2 does not satisfy full ciphertext integrity due to its noisy nature;

however, it still suffices to guarantee CCA security in practice.


These variants of CCA security were previously explored under the name of Replayable CCA and De-

tectable CCA [40,83], where it was argued that they are sufficient to provide security against an active attacker

in practice.

4.6 Almost Key-Homomorphic PRFs from Lattices

In this section, we construct an almost key-homomorphic PRF from the Learning with Errors (LWE) assump-

tion [131]. There are a number of standard variants of the LWE assumption in the literature that give rise to

efficient PRF constructions. For instance, using the Learning with Rounding (LWR) [18,28] assumption, one

can construct an almost key-homomorphic PRF in both the random-oracle and standard models. However,

any LWR-based PRF involves a modular rounding step [18] that forces the output space of the PRF to be

quite small compared to the key space. Hence, these PRFs are less optimal for the application of updatable

encryption as the noise that is incurred by each key update grows faster in the smaller output space. In this

work, we modify the existing LWR-based KH-PRF constructions to work over the ring variant of the LWE

problem called the Ring Learning with Errors (RLWE) problem [107]. We provide the precise definition in

theorem 4.6.1. The use of RLWE as opposed to LWR (or Ring-LWR) allows us to construct almost KH-PRFs

that can support more key updates when applied to Construction 4.5.2.

4.6.1 Ring Learning with Errors.

The Ring Learning with Errors (RLWE) problem works over a polynomial ring of the form R = Z[X]/(φ)

andRq = R/qR for some polynomial φ ∈ Z[X]. The degree of the polynomial φ, denoted by n, works as a

security parameter for the problem. For simplicity in this work, we restrict to power-of-two positive integers

n and cyclotomic polynomials φ = Xn + 1 ∈ Z[X]. A ring element b ∈ R (Rq) can be represented as a

vector of its polynomial coefficients in Z (Zq). Then, for a ring element b ∈ R with vector representation

b = (b1, . . . , bn), we define its norm ‖b‖ as the infinity norm of its vector representation maxi∈[n] |bi|. For a

positive integer B ∈ N, we let EB ⊆ R to denote the set of all elements inR with norm at most B.

Definition 4.6.1 (Ring Learning with Errors [107, 131, 146]). Let n, q, B be positive integers, let R =

Z[X]/(φ) be a polynomial ring for some φ ∈ Z[X], and Rq = R/qR. Then, for an error distribution χ

over EB ⊆ R, the (decisional) Ring Learning with Errors (RLWE) problem RLWEn,q,χ asks an adversary to

distinguish the following two distributions:

• OReals : On its invocation, the oracle samples a random ring element a ←R Rq , noise element e ← χ,

and returns (a, a · s+ e) ∈ Rq ×Rq .

• OIdeal: On its invocation, the oracle samples random ring elements a, u ←R Rq and returns (a, u) ∈Rq ×Rq .


More precisely, we say that RLWEn,q,χ is εRLWE-secure if for all efficient adversaries A, we have

∣∣Pr[AO

Reals (1λ) = 1

]− Pr

[AO

Ideals (1λ) = 1

]∣∣ = εRLWE(λ),

where s←R Rq .

For certain choices of the parameters n, q,B and error distribution χ, the Ring Learning with Errors problem

is hard assuming that certain worst-case lattice problems such as approx-SVP on n-dimensional ideal lattices

are hard to approximate within poly(n · q/B) by a quantum algorithm. [14, 35, 100, 107, 108, 118, 119, 126,

131].

4.6.2 Almost Key-Homomorphic PRFs from RLWE

We construct an almost key-homomorphic PRF from the hardness of the Ring Learning with Errors problem

as follows.

Construction 4.6.2. Let n, q,B, r, ` be positive integers, R = Z[X]/(φ) a polynomial ring for φ ∈ Z[X],

Rq = Zq[X]/(φ), and χ an error distribution over EB ⊆ R. We let Sampχ : 0, 1r → EB be a sampler for

the error distribution χ that takes in a uniformly random string in 0, 1r and produces a ring element in EBaccording to the distribution χ. For our construction, we set X = 0, 1` to be the domain of the PRF and

use two hash functions that are modeled as random oracles:

• H0 : 0, 1` → Rq ,• H1 : Rq × 0, 1` → 0, 1r.

We define our pseudorandom function F : Rq × 0, 1` → Rq as follows:

F (s, x):

1. Evaluate a← H0(x), ρ← H1(s, x).

2. Sample e← Sampχ(ρ).

3. Output y ← a · s+ e.

We summarize the security and homomorphic properties of the PRF construction above in the following

theorem. We provide its proof in section 4.15.

Theorem 4.6.3. Let n, q,B, r, ` be positive integers,R = Z[X]/(φ) a polynomial ring for φ ∈ Z[X],Rq =

Zq[X]/(φ), and χ an error distribution over EB ⊆ Rq . Then, assuming that RLWEn,q,χ (theorem 4.6.1) is

εRLWE-secure, the pseudorandom function in Construction 4.6.2 is a εprf -secure 2B-almost key-homomorphic

PRF (theorem 4.2.5) with key space and range (Rq,+) such that εprf(λ) = εRLWE(λ).


4.6.3 Implementation Considerations

In section 4.7, we implement our updatable authenticated encryption schemes in Constructions 4.4.2 and 4.5.2.

For the scheme in Construction 4.5.2, we instantiate the (almost) key-homomorphic PRF with the lattice-

based PRF in Construction 4.6.2. For the implementation of Construction 4.6.2, there are a number of design

decisions that must be taken into account. We now discuss a subset of these issues and provide the actual

evaluation numbers in section 4.7.

Modulus. An important parameter to consider when implementing the key-homomorphic PRF in Construc-

tion 4.6.2 is the modulus q that defines the ring Rq . Naturally, the smaller the modulus q is, the faster the

ring operations become and therefore, it is preferable to set q to be as small as possible to optimize the speed

of the PRF evaluation. At the same time, since Construction 4.6.2 is an almost key-homomorphic PRF, it is

beneficial to set q to be as big as possible to minimize the padding that must be added on to the messages

before their encryption, thereby minimizing the space required to store these ciphertexts. In section 4.7, to

test for the optimal trade-offs between speed and space, we test Construction 4.6.2 with a number of different

moduli to evaluate their performance.

Number-Theoretic Transform. An evaluation of the PRF in Construction 4.6.2 consists of a polynomial

y = a · s + e where s ∈ Rq is the PRF key and a ∈ Rq , e ∈ R are polynomials that are derived from the

input to the PRF x ∈ 0, 1`. Then to multiply two polynomials a and s, it is natural to use fast multiplication

via the number-theoretic transform (NTT). Since the polynomial a is derived from the hash of the PRF input,

a ← H(x), one can directly interpret the hash H(x) as a representation of a polynomial already in the

NTT representation. Since s is re-used for multiple PRF evaluations, its NTT representation can also be pre-

processed once at setup. This allows the PRF evaluation to require only a single NTT conversion as opposed

to the three required to convert a, s to NTT form and convert their product back.

Noise distribution and message encodings. Finally, when instantiating Construction 4.5.2 with Construc-

tion 4.6.2, an important factor to consider is the noise distribution χ and the message encoding scheme. For

the evaluations in section 4.7, we chose to use the uniform distribution over a bounded space. We set the

norm bounds for the uniform distribution based on the best known attacks on the RLWE problem.

For the message encodings, we chose to trivially pad the messages with additional insignificant bits to

cope with noise growth during key rotation. It is possible to use more sophisticated error correcting codes

to achieve better message-to-ciphertext ratios. We considered a number of options such as BCH codes and

LDPC codes [72]; however, the actual savings in the ciphertext size appeared to be minimal compared to

other optimizations.

4.7 Evaluation

In this section we evaluate the performance of our nested and KH-PRF based UAE constructions (Construc-

tions 4.4.2 and 4.5.2), comparing their performance to that of the ReCrypt scheme of Everspaugh et al. [66]


RLWE Parameters

|q| = 28 |q| = 60 |q| = 120 |q| = 128

n 1024 2048 4096 4096B 352 498 704 704

Figure 4.5: RLWE parameters for each value of |q| (length of q in bits) used in our evaluation.

Encrypt and ReEncrypt Throughput (MB/sec)

KH-PRF UAE ReCrypt Nested|q| = 28 |q| = 28 (AVX) |q| = 60 |q| = 120 |q| = 128 [66] t = 128

4KB MessagesEncrypt 24.85 31.97 20.32 0.76 0.70 0.12 406.69ReEncrypt 29.80 41.03 32.13 0.82 0.74 0.14 706.37



Figure 4.6: Comparing the throughput of our KH-PRF, ReCrypt, and our nested construction configured to allow 128 re-encryptions, for messages of length 4KB, 32KB, and 100KB. Higher numbers are better. Our KH-PRF is evaluated withfour choices of q. The AVX column refers to an implementation that takes advantage of Intel’s AVX vector instructions.

both in terms of running time and ciphertext size. We find that our constructions dramatically improve on

the running time of the Everspaugh et al. [66] UAE at the cost of an increase in ciphertext size (albeit our

ciphertext sizes are still smaller than those of ciphertext-independent schemes [32, 93, 104]).

We implemented our constructions in C and evaluated their performance on an 8-core Ubuntu virtual

machine with 4GB of RAM running on a Windows 10 computer with 64GB and a 12-core AMD 1920x

processor @3.8GHz. We use AES-NI instructions to accelerate AES and AVX instructions for applicable

choices of lattice parameters. Our implementation is single-threaded and does not take advantage of oppor-

tunities for parallelism beyond a single core. We rely on OpenSSL for standard cryptographic primitives

and rely on prior implementations of NTT and the SHAKE hash function [7, 137]. All numbers reported are

averages taken over at least 1,000 trials. Our choice of lattice parameters for each modulus size |q| (the length

of q in bits) is based on the best known attacks on RLWE [6], as shown in Figure 4.5. Our implementation is

open source and available at [2].

Encryption and Re-encryption Costs. Figure 4.6 shows encryption and re-encryption times for our KH-

PRF based UAE construction for various block sizes of the underlying KH-PRF as well as the ReCrypt

scheme [66] and our nested construction with padding configured to support up to 128 re-encryptions. Our

lattice-based KH-PRF scheme, when run with the best parameters, has from 250× to over 500× higher

encryption throughput than ReCrypt as the message size increases from 4KB to 100KB. We note that, since

KH-PRFs imply key exchange [5], we should not expect to be able to instantiate the KH-PRF approach


KeyGen and ReKeyGen Time (µsecs)

KH-PRF UAE ReCrypt Nested|q| = 60 [66] t = 128

32KB MessagesKeyGen 3.0 1.0 2.6ReKeyGen 72.7 308.8 10.1

Figure 4.7: KeyGen and ReKeyGen costs. The main differences in performance are caused by whether the ReKeyGenalgorithm needs to sample only AES keys or also KH-PRF keys, the type of KH-PRF used, and the number of ciphertextscontained in the update token.

with performance any better than that of public key primitives. The nested AES construction, on the other

hand, has 13− 47× the encryption throughput of our KH-PRF based construction. The nested AES scheme

approaches the machine’s peak AES throughput of 4.45GB/sec as the message size increases.

We find that for small messages (4KB), our KH-PRF with 28 bit output space (and accelerated with AVX

instructions) performs the best, but as messages grow larger the KH-PRF with 60 bit output space outperforms

other categories. Larger block sizes tend to perform worse because the output of the PRF no longer fits into

compiler provided primitive types, causing arithmetic operations to become less efficient. Increasing the

message size improves performance because the proportion of total time occupied by fixed-cost operations

decreases, e.g., due to the large blocks in which the KH-PRF output is generated. We run our remaining

experiments with |q| = 60 because it has the overall best performance.

Key generation. Key generation is a faster and less time-sensitive operation than encryption, re-encryption,

and decryption because it only occurs once for a small ciphertext header before an entire ciphertext is en-

crypted or re-encrypted. We show the performance of our KH-PRF based UAE as well as ReCrypt and nested

encryption on KeyGen and ReKeyGen operations in Figure 4.7. Generating a key in all three schemes is very

fast because it only requires generating a random 128-bit symmetric key. The cost of rekeying depends on the

underlying tool used to re-encrypt. ReKeyGen runs very quickly in the nested construction because it only

consists of a couple AES-GCM encryptions of a fixed-size ciphertext header. The other two constructions

rely on different types of KH-PRFs and incur most of their costs in generating the update keys for those PRFs.

Decryption Costs. Figure 4.8 shows decryption costs for our two main constructions and the tradeoffs

between them. We omit the decryption performance of ReCrypt from this graph because it is 500× slower

than our KH-PRF based construction and is strictly dominated by both schemes for the range of parameters we

measured. Decryption time for the nested AES construction depends linearly on the number of re-encryptions

that have occurred because decryption needs to remove each layer of encryption to reach the plaintext. As

such, it begins much faster than the KH-PRF construction, as it only requires standard symmetric primitives

for which hardware acceleration is available, but becomes slower after about 50 re-encryptions. The KH-

PRF construction could also vary its performance slightly based on the number of expected re-encryptions

by varying the amount of padding applied in the message encoding process. However, we chose to evaluate


25 50 75 100 1250

500

1,000

Number of Re-encryptions

Tim

e[µ

s]

Decryption Time32KB Messages

KH-PRFNested

Ciphertext Expansion32KB Messages

KH-PRF UAE|q| = 28 133%|q| = 60 36%|q| = 120 20%|q| = 128 19%

Nested UAEt = 20 3%t = 128 19%

ReCrypt [66] 3%

Figure 4.8: KH-PRF based UAE (|q| = 60) and nestedUAE (t = 128) decryption times. The KH-PRF construc-tion decrypts faster than nested AES when there are morethan 50 re-encryptions. ReCrypt is not depicted as it takes500× longer than our KH-PRF based UAE to decrypt.

Figure 4.9: Ciphertext body expansion for the KH-PRFbased UAE, Nested UAE, and ReCrypt. Our constructionsgenerally have larger ciphertext expansion than ReCrypt,although the Nested UAE matches ReCrypt for some set-tings, e.g., annually re-keying data for 20 years.

the scheme with a fixed amount of padding that is enough to support about 128 re-encryptions.

Ciphertext Size. The ciphertext size of a ciphertext-dependent UAE scheme consists of two parts: a fixed-

size header and the body, whose size depends on the plaintext. Figure 4.9 compares ciphertext body expansion

between our constructions and ReCrypt. Our KH-PRF based scheme and ReCrypt have 80-Byte headers,

while our nested construction has a 116-Byte header. Our KH-PRF based construction is implemented with

padding on each block depending on the size |q|. For example, a 60-bit block contains 44 bits of plaintext and

16 bits of padding. This corresponds to a 36% ciphertext size expansion. The lowest ciphertext expansion for

our evaluation of the KH-PRF based scheme occurred when |q| = 128, with 19% expansion. ReCrypt has

lower ciphertext expansion, at 3%. The ciphertext size of our nested construction depends on the expected

number of encryptions. It has a constant 32-Byte overhead on top of the plaintext, followed by another

48 Bytes for each re-encryption. For a 32KB message, a ReCrypt ciphertext takes 33KB and a ciphertext

under our KH-PRF scheme takes 43.6KB. A ciphertext under our nested construction will match the size of

a ReCrypt ciphertext after 19 re-encryptions. This fits well with a ciphertext that is re-encrypted once a year

over a 20-year lifetime. Supporting 128 re-encryptions still only requires a 38.3KB ciphertext, matching the

expansion of the KH-PRF based PRF when |q| = 128.

Recommendations. Based on the performance of the schemes we evaluated, we can make the following

recommendations:

• If a ciphertext is to be re-encrypted only 10 or 20 times over the course of its lifetime, say once a year

for twenty years to satisfy NIST recommendations [19] and PCI DSS [125] requirements, then one

should use the nested construction, as it will provide the best performance and ciphertext size. This is

especially true of ciphertexts that are decrypted infrequently.


• If a ciphertext is to be re-encrypted more frequently and its age is sensitive information, then Re-

crypt [66] should be used.

• If a ciphertext is to be re-encrypted frequently, but its age is less sensitive, then our almost KH-PRF

based scheme can be used for high performance.

4.8 Conclusion and Future Work

We have presented new security definitions for updatable encryption in the ciphertext-dependent setting that

provide stronger protections than prior work. Most importantly, our definitions capture the requirement that

updatable ciphertexts hide the age of the ciphertext, i.e., how many times it has been re-encrypted. We have

also constructed two performant updatable encryption schemes, one based on authenticated encryption and

another based on RLWE, that outperform prior work. The implementations of both our constructions are

open source and available at [2].

Future work. Our scheme based on authenticated encryption satisfies security guarantees that should suffice

for typical use-cases of updatable encryption, but it does not satisfy our strongest confidentiality definition

(Definition 4.3.4). Our scheme based on RLWE satisfies a relaxed integrity notion (Definition 4.12.1). Our

work suggests two open problems for future work. First, is there a practical UAE scheme that simultaneously

satisfies our strongest confidentiality and integrity definitions? Second, can we build a UAE scheme from our

RLWE-based almost key homomorphic PRF that satisfies our strongest integrity definition, with decryption

time independent of ciphertext age? We hope that future work will result in such constructions.

The remaining sections in this chapter provide additional background information, details that were omit-

ted from the initial exposition of our work, and full security proofs for our constructions.

4.9 Everspaugh et al. [66] Security Definitions

This section states the message confidentiality, re-encryption indistinguishability, and ciphertext integrity

definitions of Everspaugh et al. [66].

The confidentiality security definitions stated here are in fact slight modifications of the definitions of

Everspaugh et al. [66]. The difference between the two sets of definitions is in the way the challenger handles

trivial wins. In both sets of definitions (the originals and the ones presented here), an adversary is prohibited

from ever receiving a re-encryption of the challenge ciphertext under any of the dishonest keys. Allowing

the adversary to do so makes the security game trivial as the adversary can use these keys to decrypt the

challenge ciphertext and always win the game. In Definitions 4.9.1 and 4.9.2, we define the re-encryption

oracleOReEncrypt to take in a pair of indices i, j and a ciphertext (ct, ct), and output “⊥” if both the target index

j is a compromised key (i.e. j > h) and (ct, ct) is either a challenge ciphertext or one of its derivations via re-

encryption. In the definitions of Everspaugh et al. [66], if an adversary submits a re-encryption oracle query


that satisfies these conditions, the challenger still returns the ciphertext header “ct′” (but not the ciphertext

body ct′) of the re-encrypted ciphertext instead of outputting ⊥.

The original [66] definitions provide theoretically stronger security as an adversary in their security exper-

iments receives more power from the re-encryption oracle. However, it is difficult to deduce what additional

security property the stronger variant of the definition captures. In the stronger confidentiality experiments, an

adversary has the power to essentially decrypt the ciphertext headers from a challenge ciphertext. Although

ciphertext headers are necessarily transmitted during key updates and therefore more likely to be exposed to

attackers, these headers are still ciphertexts that are designed precisely to provide confidentiality when they

are exposed over public channels. Therefore, assuming that an adversary may decrypt a challenge ciphertext

header without compromising an honest key in the process is unrealistic and appears to add unnecessary com-

plication to the definition. For this work, we choose to present the simpler and clear variant of the original set

of definitions. The limitations of the definitions that we discuss in Section 4.3 are more fundamental to the

way the existing confidentiality experiments are designed and are orthogonal to the issue of handling trivial

wins.

We do note that Everspaugh et al. [66] showed an elegant way of upgrading an updatable encryption

scheme that satisfies the simpler variant of the confidentiality security definitions (Definitions 4.9.1 and 4.9.2)

to the stronger variant of [66] via a secret-sharing technique. This transformation incurs minimal efficiency

overhead and can also be applied to the constructions in this work. We present our constructions without this

transformation for simplicity in the notations and proofs.

Definition 4.9.1 (Message Confidentiality [28,66]). Let ΠUAE = (KeyGen,Encrypt,ReKeyGen,ReEncrypt,

Decrypt) be an updatable authenticated encryption scheme for a message spaceM = (M)λ∈N. Then, for

a security parameter λ, positive integers h, d ∈ N, an adversary A, and a binary bit b ∈ 0, 1, we define

the message confidentiality experiment Exptmsg-confΠUAE

(λ, h, d,A, b) and oracles O = (OEncrypt,OReKeyGen,

OReEncrypt,OChallenge) in Figure 4.10. The experiment maintains a look-up table T, accessible by all the

oracles, that maps key index and ciphertext header pairs to ciphertext bodies.

We say that an updatable authenticated encryption scheme ΠUAE satisfies message confidentiality if there

exists a negligible function negl(·) such that for all h, d ≤ poly(λ) and efficient adversaries A, we have∣∣∣Pr[Exptmsg-conf

ΠUAE(λ, h, d,A, 0) = 1

]− Pr

[Exptmsg-conf

ΠUAE(λ, h, d,A, 1) = 1

]∣∣∣ ≤ negl(λ).

Definition 4.9.2 (Re-Encryption Indistinguishability [66]). Let ΠUAE = (KeyGen,Encrypt,ReKeyGen,ReEncrypt,

Decrypt) be an updatable authenticated encryption scheme for a message spaceMλ. Then, for a security

parameter λ, positive integers h, d ∈ N, an adversary A, and a binary bit b ∈ 0, 1, we define the re-

encryption indistinguishability experiment Exptre-enc-indΠUAE

(λ, h, d,A, b) and oracles O = (OEncrypt,OReKeyGen,

OReEncrypt,OChallenge) in Figure 4.11. The experiment maintains a look-up table T, accessible by all the

oracles, that maps key index and ciphertext header pairs to ciphertext bodies.


Exptre-enc-indΠUAE

(λ, h, d,A, b):

k1, . . . , kh+d ← KeyGen(1λ)

b′ ← AO(kh+1, ..., kh+d)

Output b′ = b

OEncrypt(i,m):



if j > h and T [i, ct] 6= ⊥:


if T [i, ct] 6= ⊥:



)T[j, ct

′]← ct′

Output ∆i,j,ct

OReEncrypt

(i, j, (ct, ct)

):




)if j > h and T[i, ct] 6= ⊥:




OChallenge

(i,m0,m1

):

if i > h or |m0| 6= |m1|:Output ⊥

(ct, ct)← Encrypt(ki,mb)

T[i, ct]← ct

Output (ct, ct)

Figure 4.10: Simplified confidentiality definition of Everspaugh et al. [66] (theorem 4.9.1)

We say that an updatable authenticated encryption scheme ΠUAE satisfies re-encryption indistinguisha-

bility if there exists a negligible function negl(·) such that for all h, d ≤ poly(λ) and efficient adversaries A,

we have ∣∣∣Pr[Exptre-enc-ind

ΠUAE(λ, h, d,A, 0) = 1

]− Pr

[Exptre-enc-ind

ΠUAE(λ, h, d,A, 1) = 1

]∣∣∣ ≤ negl(λ).

The Everspaugh et al. integrity definition differs from ours in that instead of having the adversary submit

one forgery at the end of the game, the adversary is given ongoing access to a Try oracle to which it can

submit attempted forgeries. This does not materially impact the definition as the two definitions imply each

other. The reduction from our definition to one with a Try oracle uses a guessing argument and simulates

the Try oracle by always returning ⊥ except for on one randomly chosen query which is forwarded as the

reduction’s attempt to forge.

Definition 4.9.3 (Ciphertext Integrity [66]). Let ΠUAE = (KeyGen,Encrypt,ReKeyGen,ReEncrypt,Decrypt)

be an updatable authenticated encryption scheme for a message spaceM = (Mλ)λ∈N. Then, for a security

parameter λ, positive integers h, d ∈ N, and an adversary A, we define the ciphertext integrity experiment


Exptre-enc-indΠUAE

(λ, h, d,A, b):

k1, . . . , kh+d ← KeyGen(1λ)

b′ ← AO(kh+1, ..., kh+d)

Output b′ = b

OEncrypt(i,m):



if j > h and T [i, ct] 6= ⊥:


if T [i, ct] 6= ⊥:



)T[j, ct

′]← ct′

Output ∆i,j,ct

OReEncrypt

(i, j, (ct, ct)

):




)if j > h and T[i, ct] 6= ⊥:




OChallenge

(i, j, (ct0, ct0), (ct1, ct1)

):

if j > h or |(ct0, ct0)| 6= |(ct1, ct1)|:Output ⊥

for β ∈ 0, 1:∆i,j,ctβ

← ReKeyGen(ki, kj , ctβ)

(ct′β , ct

′β)← ReEncrypt(∆i,j,ctβ

, (ctβ , ctβ))

if ∆i,j,ctβ= ⊥ or (ct

′β , ct

′β) = ⊥:

Output ⊥T[j, ct

′b]← ct′b

Output (ct′b, ct

′b)

Figure 4.11: Simplified re-encryption indistinguishability definition of Everspaugh et al. [66] theorem 4.9.2

Exptctxt-intΠUAE(λ, h, d,A) and oracles O = (OEncrypt,OReKeyGen,OTry) in Figure 4.12. The experiment main-

tains a look-up table T, accessible by all the oracles, that maps key index and ciphertext header pairs to

ciphertext bodies. The oracles also have access to the variable win.

We say that an updatable authenticated encryption scheme ΠUAE satisfies ciphertext integrity if there

exists a negligible function negl(·) such that for all h, d ∈ N and any efficient adversary A, we have

Pr[Exptctxt-intΠUAE

(λ, h, d,A) = 1]≤ negl(λ).


Exptctxt-intΠUAE(λ, h, d,A):

win← false

k1, . . . , kh+d ← KeyGen(1λ)

AO(kh+1, ..., kh+d)

Output win

OEncrypt(i,m):


T[i, ct]← ct

Output (ct, ct)




if T[i, ct] 6= ⊥:



)T[j, ct

′]← ct′

Output ∆i,j,ct

OTry(i, (ct, ct)):

if i > h:

Output ⊥m← Decrypt

(ki, (ct, ct)

)if m = ⊥ or T[i, ct] = ct:

Output ⊥else:

win← true

Output m

Figure 4.12: Ciphertext integrity definition of Everspaugh et al. [66] (theorem 4.9.3)

4.10 Comparison to the Ciphertext-Independent Setting

Adaptive vs. Static corruption. Security definitions in the ciphertext-independent setting are largely defined

analogously to those in ciphertext-dependent setting. One distinction, however, is in the way an adversary

can query the oraclesOReKeyGen andOReEncrypt. In the security definitions for ciphertext-dependent updatable

encryption, an adversary can query these oracles arbitrarily in any order, as long as the adversary does not

make a sequence of queries that allows it to trivially win the game. In the ciphertext-independent setting as

formulated in [104], the confidentiality security experiment is divided into epochs that must be executed in

a fixed order. Each key that is generated in the experiment is associated with a unique epoch and therefore,

an adversary is required to query these keys in a fixed order. Furthermore, the security definitions in the

ciphertext-independent setting allow for separate compromises of keys and update tokens. These distinctions

allow the existing updatable encryption constructions in the ciphertext-independent setting to satisfy adaptive

security where the adversary can corrupt additional malicious keys throughout the progression of the exper-

iment. In contrast, all existing constructions in the ciphertext-dependent setting, including the constructions

in this work, satisfy static security.

Integrity. The first work that considers integrity for updatable encryption in the ciphertext-independent

setting is that of Klooß et al. [93], which provides two integrity definitions. In the first definition, the re-

encryption oracle only accepts the ciphertexts that are honestly derived from ciphertexts that were previously

provided by the challenger. The second integrity definition removes this restriction on re-encryption oracle

queries. The first definition is analogous to the relaxed integrity notion that we describe in theorem 4.12.1,


and their stronger integrity definition is analogous to the integrity described in theorem 4.3.7. Klooß et al. [93]

also provide two constructions that each satisfy one of these definitions: a practical updatable encryption con-

struction that satisfies the weaker integrity definition, and a theoretical construction that satisfies the stronger

definition. The SHINE [32] constructions satisfy a slightly modified version of the stronger Klooß et al.

definition.

Efficiency. Although none of the existing updatable encryption schemes in the ciphertext-independent setting

have yet been implemented, we can compare their asymptotic performance with those of the constructions in

this work. The most efficient family of ciphertext-independent updatable encryption schemes, SHINE [32],

requires a similar number of symmetric and group operations as the ReCrypt updatable encryption scheme

of [66], which works in the ciphertext-dependent setting. In section 4.7, we show that the constructions in

this work further improve the performance of ReCrypt and therefore, they would also outperform the existing

updatable encryption schemes in the ciphertext-independent setting.

4.11 Full Construction of Simple Nested Scheme

Construction 4.11.1. Our construction uses the following building block:

• A standard authenticated encryption scheme ΠAE = (KeyGen,Encrypt,Decrypt) with message spaceM =

(Mλ)λ∈N.


Decrypt) for message spaceM = (Mλ)λ∈N in Figure 4.13.

We state the compactness, correctness, and the security properties of Construction 4.11.1 as follows.

Theorem 4.11.2 (Compactness). The updatable authenticated encryption scheme ΠUAE in Construction 4.11.1

satisfies compactness (theorem 4.3.2).

Theorem 4.11.3 (Correctness). Suppose that ΠAE satisfies correctness (theorem 4.2.7). Then, the updatable

authenticated encryption scheme ΠUAE in Construction 4.11.1 satisfies correctness (theorem 4.3.3).

Theorem 4.11.4 (Message Confidentiality). Let ΠUAE be the updatable authenticated encryption scheme in

Construction 4.11.1. If ΠAE satisfies correctness, εconfae -confidentiality, and εintae -integrity, then for all h, d =

poly(λ) and efficient adversaries A that make at most Q oracle queries, we have

∣∣∣Pr[Exptmsg-conf

ΠUAE(λ, h, d,A, 0) = 1

]− Pr

[Exptmsg-conf

ΠUAE(λ, h, d,A, 1) = 1

]∣∣∣≤ (2h+ 4Q) · εconfae (λ) + 2h · εintae (λ).

In particular, if ΠAE satisfies correctness, confidentiality, and integrity, then ΠUAE satisfies message confi-

dentiality (theorem 4.9.1).


KeyGen(1λ):

k← AE.KeyGen(1λ)

Output k

Encrypt(k,m)

kae ← AE.KeyGen(1λ)

ct← AE.Encrypt(k, (kae,⊥)

)ct← AE.Encrypt

(kae, (m,⊥)

)Output (ct, ct)


khistory ← AE.KeyGen(1λ)

k′ae ← AE.KeyGen(1λ)

cthistory ← AE.Encrypt(khistory,AE.Decrypt(k1, ct)

)ct← AE.Encrypt

(k2, (k

′ae, khistory)

)∆1,2,ct ← (k′ae, ct

′, cthistory)

Output ∆1,2,ct


):

(k′ae, ct′, cthistory)← ∆1,2,ct

ct′ ← AE.Encrypt(k′ae, (ct, cthistory)

)Output (ct

′, ct′)

Decrypt(k, (ct, ct)

):

1. k← k

2. (k′ae, k′history)← AE.Decrypt(k, ct)

3. if (k′ae, k′history) = ⊥, output ⊥

4. (ct′, ct′history)← AE.Decrypt(k′ae, ct)

5. if (ct′, ct′history) = ⊥, output ⊥

6. if k′history 6= ⊥:

7. k← k′history

8. ct← ct′

9. ct← ct′history

10. goto step 2

11. m← ct′

12. Output m

Figure 4.13: Our simple nested scheme.

Theorem 4.11.5 (Re-Encryption Indistinguishability). Let ΠUAE be the updatable authenticated encryption

scheme in Construction 4.11.1. If ΠAE satisfies correctness, εconfae -confidentiality, and εintae -integrity, then for

all h, d = poly(λ) and efficient adversaries A that make at most Q oracle queries, we have

∣∣∣Pr[Exptre-enc-ind

ΠUAE(λ, h, d,A, 0) = 1

]− Pr

[Exptre-enc-ind

ΠUAE(λ, h, d,A, 1) = 1

]∣∣∣≤ (2h+ 4Q) · εconfae (λ) + 2h · εintae (λ).

In particular, if ΠAE satisfies correctness, confidentiality, and integrity, then ΠUAE satisfies confidentiality


(theorem 4.9.2).

Theorem 4.11.6 (Ciphertext Integrity). Let ΠUAE be the updatable authenticated encryption scheme in Con-

struction 4.11.1. If ΠAE satisfies correctness, εconfae -confidentiality, εintae -integrity, then for all h, d = poly(λ)

and efficient adversaries A that make at most Q challenge, ReKeyGen, or ReEncrypt queries, we have

Pr[Exptctxt-intΠUAE

(λ, h, d,A) = 1]≤ (h+Q) · εintae (λ) + (h+Q) · εconfae (λ) +Q/2λ.

In particular, if ΠAE satisfies correctness, confidentiality, and integrity then ΠUAE satisfies integrity (theo-

rem 4.3.7).

In section 4.4 (Construction 4.4.2), we augment Construction 4.11.1 such that it achieves our new security

definitions of body compactness (theorem 4.3.5) and update independence (theorem 4.3.6). As the proofs

of compactness, correctness, and security for Construction 4.11.1 are identical to the proofs of compactness,

correctness, and security for Construction 4.4.2, we refrain from duplicating the proofs.

4.12 Full Definition of Relaxed Integrity

For completeness, this section states the full definitions relaxed integrity, which was omitted from the body

of the text due to its similarity to the integrity definition already described earlier.

Definition 4.12.1 (γ-Relaxed Integrity). Let n and q be a positive integers, and let ΠUAE = (KeyGen,

Encrypt,ReKeyGen,ReEncrypt,Decrypt) be an updatable authenticated encryption scheme for a message

space M and ciphertext space CT with an associated metric function d : CT × CT → Z. Then, for a

security parameter λ, positive integers h, d ∈ N, noise bound γ ∈ N, and an adversary A, we define the

relaxed integrity experiment Exptrelaxed-intΠUAE

(λ, h, d, γ,A) and oracles O = (OEncrypt,OReKeyGen,OReEncrypt)

in Figure 4.14. The experiment maintains a look-up table T, accessible by all the oracles, that maps key

index and ciphertext header pairs to ciphertext bodies.

We say that an updatable authenticated encryption scheme ΠUAE satisfies γ-relaxed integrity if there

exists a negligible function negl(·) such that for all h, d ∈ N and any efficient adversary A, we have

Pr[Exptrelaxed-int

ΠUAE(λ, h, d, γ,A) = 1

]≤ negl(λ).


Exptrelaxed-intΠUAE

(λ, h, d, γ,A):

k1, . . . , kh+d ← KeyGen(1λ)

(i, (ct, ct))← AO(kh+1, ..., kh+d)

if i > h:

Output 0


)Interpret ct = (ct1, . . . , ct`) ∈ (Znq )`

(ct′,m′)← T[i, ct]

Interpret ct′ = (ct′1, . . . , ct′`′) ∈ (Znq )`

FarFromTable← false

for j ∈ [`]:

if d(ctj , ct′j) γ:

FarFromTable← true

if m′ 6= m or ` 6= `′

FarFromTable← false

if m = ⊥ or FarFromTable:

Output 0

else:

Output 1

OEncrypt(i,m):


T[i, ct]← ct

Output (ct, ct)




if T[i, ct] 6= ⊥:



)T[j, ct

′]← ct′

Output ∆i,j,ct

OReEncrypt

(i, j, (ct, ct)

):


)if m = ⊥:




)if j ≤ h:



Figure 4.14: Security experiment for relaxed integrity (theorem 4.12.1)

4.13 Proof of theorem 4.4.3

4.13.1 Proof of Strong Compactness

Fix the security parameter λ, number of updates N ∈ N, and any message m ∈ Mλ. Let k0, . . . , kN ←KeyGen(1λ, 1N ), (ct0, ct0)← Encrypt(k0,m),

∆i,i+1,cti ← ReKeyGen(ki, ki+1, cti), and

(cti+1, cti+1)← ReEncrypt(∆i,i+1,cti , (cti, cti)

),

for i = 0, . . . , N − 1.

Ciphertext header: By the specification of Encrypt and ReKeyGen, we have that for all i, cti = AE.Encrypt(ki, (s, `, kae,


khistory)). Here, kae, khistory are authenticated encryption keys and s is a PRG seed whose lengths depend only

on the security parameter λ. The positive integer ` specifies the length of the ciphertext body, whose length

can fixed to be poly(λ). Thus every ciphertext header has the same fixed length.

Ciphertext body: By construction, the ciphertext body cti for i > 0 always has the same size |cti−1| as the

preceding ciphertext because padding is added until the new ciphertext matches the length of the previous

ciphertext.

Re-encryption key: The re-encryption key ∆i,i+1,ct consists of a new ciphertext header ct′, a ciphertext

cthistory ← AE.Encrypt(k′history, (kae, khistory)), length bound `, a PRG seed s′, and an encryption key k′ae. As

described above, the lengths of ct′, `, kae, and s′ are all either fixed or depend only on λ. This is also true of

|cthistory| because it is an encryption of two encryption keys, each of which has a length that depends only on

λ. Thus every re-encryption key also has the same fixed length.

4.13.2 Proof of Correctness

Fix the security parameter λ, number of updates N ∈ N, and any message m ∈ Mλ. Let k1, . . . , kN ←KeyGen(1λ), (ct1, ct1)← Encrypt(k1,m), and


),

for i = 1, . . . , N − 1. We must show that

Decrypt(kN , (ctN , ctN )

)= m.

We will prove correctness of Construction 4.4.2 by induction on i, the number of layers of encryption on

the ciphertext body ct. First we consider the base case of i = 1, where (ct1, ct1) ← Encrypt(k1,m). In this

case we have

- ctpayload ← AE.Encrypt(kae,m)

- ctpad ← G(s) such that ctpad ∈ 0, 1t·(2ρ+ν)

- ct1 ← (ctpayload, ctpad)

- ct1 ← AE.Encrypt(k1, (s, |ctpayload|, kae,⊥))

During decryption, by the correctness of ΠAE, we have that AE.Decrypt(k1, ct1) = (s, |ctpayload|, kae,⊥).

Thus the Decrypt algorithm correctly regenerates G(s) = ctpad and strips it from ct1. Finally, again using

the correctness of ΠAE, AE.Decrypt(kae, ctpayload) = m.

Next, assuming Decrypt(ki, (cti, cti)) = m, and that decryption of ctpayload ,i under kae ,i outputs m, we

show that Decrypt(ki+1, (cti+1, cti+1)) = m as well. For consistency of notation, we will denote ciphertexts

corresponding to the encryption under ki without a subscript and denote ciphertexts corresponding to the

encryption under ki+1 with a prime, e.g., ct′. Now we have


- cthistory ← AE.Encrypt(k′history, (kae, khistory))

- ct′payload ← AE.Encrypt(k′ae, (ctpayload, cthistory)

)- ct′pad ← G(s′)

- ct′ ← (ct′payload, ct′pad)

- ct′ ← AE.Encrypt

(ki+1, (s

′, `, k′ae, k′history)

)As above, during decryption, by the correctness of ΠAE, we have that AE.Decrypt(k′, ct′) = (s′, `, k′ae, k

′history).

Thus the Decrypt algorithm correctly regeneratesG(s′) = ctpad and strips it from ct1. By again using the cor-

rectness of ΠAE, we have that AE.Decrypt(k′ae, ct′payload) = (ctpayload, cthistory) and that AE.Decrypt(k′history, cthistory) =

(kae, khistory). Now, by the induction hypothesis, we have ctpayload under kae decrypts to m.

4.13.3 Proofs of Update Independence, Message Confidentiality, and Re-encryptionIndistinguishability

The proofs of update independence, message confidentiality, and re-encryption indistinguishability are almost

identical. Therefore, we provide a full proof of update independence and discuss the minor modifications that

are required to adapt the proof for message confidentiality and re-encryption indistinguishability.

Update independence. We proceed via a sequence of hybrid experiments that are defined as follows:

• Hyb0: This hybrid experiment corresponds to the real updatable authenticated encryption update inde-

pendence experiment Exptupd-indΠUAE

(λ, h, d,A, 0) that is instantiated with Construction 4.4.2.

• Hyb1: In this hybrid experiment, we introduce an additional abort condition to the challenger’s simu-

lation. Namely, throughout the query phase of the experiment, the challenger maintains an additional

look-up table Theader that keeps track of all of the “well-formed” ciphertext headers under honest keys

that A receives from the challenger throughout the experiment. The table is initially set to be empty,

and the challenger answers each of A’s oracle queries as follows:

– OEncrypt(i,m): The challenger answers the oracle exactly as in Hyb0 by generating the ciphertext

header

ct← AE.Encrypt(ki, (s, |ctpayload|, kae,⊥)

),

and the ciphertext body as specified in construction 4.4.2. However, after returning the ciphertext

(ct, ct) to A, it additionally adds the mapping Theader[i, ct] ← (s, |ctpayload|, kae,⊥) to the table

if i < h.

– OReEncrypt

(i, j, (ct, ct)

): The challenger first checks if Theader[i, ct] = ⊥ and outputs⊥ if so. This

check is skipped if i > h (if i does not correspond to an honest key). If it does not abort, then

the challenger proceeds exactly as in Hyb0 by setting ct′ ← AE.Encrypt

(kj , (s

′, l, k′ae, k′history)

),

computing ∆i,j,ct, and returning ReEncrypt(∆i,j,ct, (ct, ct)

)to A. However, after returning the

updated ciphertext to A, it adds the mapping Theader[j, ct′]← (s′, l, k′ae, k

′history) to the table.


– OChallenge(i, j,m, (ct, ct)): The challenger first checks if Theader[i, ct] = ⊥ and outputs ⊥ if so.

This check is skipped if i > h (if i does not correspond to an honest key). If it does not abort, then

the challenger answers the oracle query exactly as in Hyb0 by generating the ciphertext header


(kj , (s, |ctpayload|, kae,⊥)

),

and the ciphertext body ct′ according to the specification of Encrypt(kj ,m) when b = 0 or by

generating the ciphertext header


(kj , (s


)and ciphertext body ct′ according to ReEncrypt


)when b = 1. However, af-

ter returning the ciphertext (ct′, ct′) to A, it additionally adds the mapping Theader[j, ct

′] ←

(s, |ctpayload|, kae,⊥) to the table when b = 0 or Theader[j, ct′]← (s′, l, k′ae, k

′history) when b = 1.

The rest of the experiment remains unchanged from Hyb0.

In theorem 4.13.1 below, we show that the hybrid experiments Hyb0 and Hyb1 are computationally

indistinguishable assuming that ΠAE satisfies integrity.

• Hyb2: In this hybrid experiment, we erase the decryption algorithm AE.Decrypt from the challenger’s

simulation for honest keys in ciphertext headers. Namely, the challenger answers A’s re-encryption

oracle and challenge oracle as follows when i ≤ h:

– OReEncrypt

(i, j, (ct, ct)

): The challenger answers the oracle exactly as in Hyb1, but instead of

decrypting the ciphertext header µ ← AE.Decrypt(ki, ct), it sets µ ← Theader[i, ct]. If no such

entry exists in Theader, then it immediately aborts the experiment and outputs ⊥.

– OChallenge(i, j,m, (ct, ct)): The challenger answers the oracle exactly as in Hyb1, but instead

of decrypting the ciphertext header µ ← AE.Decrypt(ki, ct) in the call to ReKeyGen, it sets

µ ← Theader[i, ct]. If no such entry exists in Theader, then it immediately aborts the experiment

and outputs ⊥.


In theorem 4.13.2 below, we show that the hybrid experiments Hyb1 and Hyb2 are perfectly indistin-

guishable assuming that ΠAE is correct.

• Hyb3: In this hybrid experiment, we erase the contents of ciphertext headers for honest keys. Namely,

the challenger answers each of A’s oracle queries as follows, where intlen represents the number of

bits required to represent an integer:


– OEncrypt(i,m): If i ≤ h, the challenger answers the oracle query exactly as in Hyb2, but it sets

the ciphertext header ct to be

ct← AE.Encrypt(ki, (0

|s|, 0intlen, 0|kae|, 0λ)).

The rest of the simulation in answering A’s queries remain unchanged.

– OReEncrypt

(i, j, (ct, ct)

): If j ≤ h, the challenger answers the oracle query exactly as in Hyb2,

but it sets the ciphertext header ct′ to be


(kj , (0

|s′|, 0intlen, 0|k′ae|, 0|k

′history|)

).


– OChallenge(i, j,m, (ct, ct)): If j ≤ h, the challenger answers the oracle query exactly as in Hyb2,



(kj , ((0

|s|, 0intlen, 0|kae|, 0λ))

when b = 0 or


(kj , ((0

|s′|, 0intlen, 0|k′ae|, 0k

′history)

)when b = 1. The rest of the simulation in answering A’s queries remain unchanged.



indistinguishable assuming that ΠAE satisfies confidentiality.

• Hyb4: In this hybrid experiment, we replace the output of G(·) with a random string. Namely, the

challenger answers each of A’s oracle queries as follows:

– OEncrypt(i,m): If i ≤ h, the challenger answers the oracle exactly as in Hyb3, but instead of

evaluating ctpad ← G(s), it sets ctpad ←R 0, 1t(2ρ+ν). The rest of the simulation in answering

A’s queries remains unchanged.

– OReEncrypt

(i, j, (ct, ct)

): If j ≤ h, the challenger answers the oracle exactly as in Hyb3, but

instead of evaluating ct′pad ← G(s′), it sets ct′pad ←R 0, 1|ct|−|ct

′payload|. The rest of the simulation

in answering A’s queries remains unchanged.

– OChallenge(i, j,m, (ct, ct)): If j ≤ h, the challenger answers the oracle exactly as in Hyb3, but

instead of evaluating ct′pad ← G(s′) when b = 1, it sets ct′pad ←R 0, 1|ct|−|ct

′payload|. The rest of

the simulation in answering A’s queries remains unchanged.




indistinguishable assuming that G satisfies PRG security.

• Hyb5: In this hybrid we replace AE.Encrypt(k′history, ·) in oracle queries made under honest keys with

a completely random function. Namely, the challenger answers each of A’s oracle queries as follows:

– OReEncrypt

(i, j, (ct, ct)

): If j ≤ h, the challenger answers the oracle exactly as in Hyb4, but in-

stead of setting cthistory ← AE.Encrypt(k′history, (kae, khistory)), it sets cthistory ← fk′history((kae, khistory)),

for a random function fk′history(·). The rest of the simulation in answering A’s queries remains un-

changed.


instead of setting cthistory ← AE.Encrypt(k′history, (kae, khistory)) when b = 1, it sets cthistory ←fk′history

((kae, khistory)), for a random function fk′history(·). The rest of the simulation in answering

A’s queries remains unchanged.


indistinguishable assuming that AE.Encrypt has ciphertext pseudorandomness.

• Hyb6: In this hybrid experiment, we replace the output of AE.Encrypt(kae, ·) in oracle queries made

under honest keys with that of a completely random function. Namely, the challenger answers each of

A’s oracle queries as follows:

– OEncrypt(i,m): If i ≤ h, the challenger answers the oracle exactly as in Hyb5, but instead of

setting ctpayload ← AE.Encrypt(kae,m), it sets ctpayload ← fkae(m) for a random function fkae(·).

The rest of the simulation in answering A’s queries remains unchanged.

– OReEncrypt

(i, j, (ct, ct)

): If j ≤ h, the challenger answers the oracle exactly as in Hyb5, but in-

stead of setting ct′payload ← AE.Encrypt(k′ae, (ctpayload, cthistory)), it sets ct′payload ← fk′ae((ctpayload, cthistory))

for a random function fk′ae(·). The rest of the simulation in answering A’s queries remains un-

changed.


instead of setting ct′payload ← AE.Encrypt(k′ae, (ctpayload, cthistory)) when b = 1, it sets ct′payload ←fk′ae((ctpayload, cthistory)) for a random function fk′ae(·). The rest of the simulation in answeringA’s

queries remains unchanged.



• Hyb7: In this hybrid experiment, we modify the challenger from directly encrypting the message m to

re-encrypting the ciphertext (ct, ct) when answering A’s challenge query OChallenge

(i, j,m, (ct, ct)

).

Namely, on a query OChallenge

(i, j,m, (ct, ct)

), instead of proceeding with b = 0, the challenge is

handled with b = 1. The rest of the experiment remains unchanged from Hyb6.



guishable.

• Hyb8: Starting from this hybrid, we start unrolling back the changes that we made from Hyb0. In this

hybrid experiment, we undo the changes that we made in hyb6 by replacing the evaluations of random

functions fkae and fk′ae with evaluations of AE.Encrypt(kae, ·) and AE.Encrypt(k′ae, ·) respectively.

In theorem 4.13.11 below, we show that the hybrid experiments hyb7 and hyb8 are computationally


• Hyb9: In this hybrid experiment, we undo the changes that we made in Hyb5 by replacing the evalua-

tions of random functions fk′history with evaluations of AE.Encrypt(k′history, ·).



• Hyb10: In this hybrid experiment, we undo the changes that we made in Hyb4 by replacing the random

strings in oracle responses under honest keys with true PRG outputs.


indistinguishable assuming that G : 0, 1λ → 0, 1∗ is a secure PRG.

• Hyb11: In this hybrid experiment, we undo the changes that we made in Hyb3 by including the real

contents of the ciphertext headers instead of encryptions of zero.



• Hyb12: In this hybrid experiment, we undo the changes that we made in Hyb2 by re-introducing the

decryption algorithm AE.Decrypt in the challenger’s simulation.

In theorem 4.13.15 below, we show that the hybrid experiments Hyb11 and Hyb12 are perfectly indis-

tinguishable assuming that ΠAE is correct.

• Hyb13: In this hybrid experiment, we undo the changes that we made in Hyb1 by removing the addi-

tional abort condition.



This hybrid experiment corresponds to the real updatable authenticated encryption update indepen-

dence experiment Exptupd-indΠUAE

(λ, h, d,A, 1).

We now show that each of the consecutive hybrid experiments are indistinguishable. For a hybrid experi-

ment Hyb and an adversary A, we use Hyb(A) to denote the random variable that represents the output of

experiment Hyb with adversary A.


Lemma 4.13.1. Suppose that ΠAE satisfies εintae -integrity (Definition 4.2.9). Then, for all efficient adversaries

A, we have ∣∣Pr[Hyb0(A) = 1]− Pr[Hyb1(A) = 1]∣∣ ≤ h · εintae (λ).

Proof. Let A be an adversary that distinguishes experiments Hyb0 and Hyb1. We construct an algorithm Bthat uses A to break the integrity of ΠAE (theorem 4.2.9). Algorithm B works as follows:

• Setup phase: At the start of the experiment, algorithmB samples a random index i∗ ←R [h]. It generates

the keys ki for i ∈ [h+ d]\ i∗ according to the (identical) specifications of Hyb0 and Hyb1. For ki∗ ,

algorithm B leaves it unspecified.

• Query phase: Algorithm B simulates the responses to A’s oracle queries as follows:

– OEncrypt(i,m): If i 6= i∗, algorithm B proceeds according to Hyb0. If i = i∗, it proceeds ac-

cording to the specification in Hyb1. Whenever B must use ki∗ to generate the ciphertext header

ct← AE.Encrypt(ki∗ , (s, |ctpayload|, kae,⊥)), it uses the encryption oracle Ok∗i

(·) for ΠAE.

– OReEncrypt

(i, j, (ct, ct)

): If i = i∗, algorithm B proceeds according to the specification in Hyb1.

Otherwise, it proceeds according to Hyb0. In both cases, whenever B must use ki∗ to generate the

ciphertext header ct′ ← AE.Encrypt(ki∗ , (s


), it uses the encryption oracleOk∗i

(·)for ΠAE (theorem 4.2.9). If i = i∗ and B must abort, it submits ct as a forgery for ΠAE.

– OChallenge(i, j,m, (ct, ct)): If i = i∗, algorithm B proceeds according to the specification in Hyb1.


ciphertext header ct′ ← AE.Encrypt(ki∗ , (s


), it uses the encryption oracleOk∗i

(·)for ΠAE (theorem 4.2.9). If i = i∗ and B must abort, then it submits ct as a forgery for ΠAE.

• Output phase: At the end of the experiment, adversary A outputs a bit b ∈ 0, 1, which algorithm Breturns as the output of the experiment.

By definition, the only difference between the hybrid experiments Hyb0 and Hyb1 is the additional abort

condition when the challenger answers an adversary’s re-encryption or challenge queries in Hyb1. Therefore,

by definition, algorithm B perfectly simulatesA’s views of the experiments Hyb0 and Hyb1 modulo the abort

conditions. Furthermore, by the specification of B, if A forces B to abort in any of these queries, then Bsuccessfully forges a new ciphertext for ΠAE.

To formally analyze the probability that B successfully forges a new ciphertext, let us define the following

set of random variables:

• Let Z denote the event that B successfully forges a ciphertext at the end of the simulation above.

• Let Xi for i ∈ [h] denote the event that i = i∗ during B’s simulation above.

• Let Yi for i ∈ [h] denote the event that adversaryA forces the challenger to abort in Hyb1 by submitting

a query OReEncrypt

(i, j, (ct, ct)

)or OChallenge(i, j,m, (ct, ct)).


Then, by definition, algorithm B successfully forges a new authenticated encryption ciphertext whenA forces

algorithm B to abort on a query OReEncrypt

(i∗, j, (ct, ct)

)or OChallenge(i

∗, j,m, (ct, ct)):

Pr[Z]

=∑i∈[h]

Pr[Xi ∩ Yi

]=∑i∈[h]

Pr[Xi | Yi

]· Pr

[Yi]

=∑i∈[h]

1

h· Pr

[Yi]

=1

h

∑i∈[h]

Pr[Yi]

≥ 1

h· Pr

[Y1 ∪ . . . ∪ Yh

],

where the last inequality follows by the union bound. Now, since the only difference between the hybrid ex-

periments Hyb0 and Hyb1 is the additional abort condition when the challenger answersOReEncrypt

(i, j, (ct, ct)

)or OChallenge(i, j,m, (ct, ct)), an adversary’s advantage in distinguishing the two experiments is bounded by

the probability of the event Y1 ∪ . . . ∪ Yh:

∣∣Pr[Hyb0(A) = 1]− Pr[Hyb1(A) = 1]∣∣ ≤ Pr

[Y1 ∪ . . . ∪ Yh

].

Putting the two inequalities together, we have

∣∣Pr[Hyb0(A) = 1]− Pr[Hyb1(A) = 1]∣∣ ≤ Pr

[Y1 ∪ . . . ∪ Yh

]≤ h · Pr

[Z]

≤ h · εintae (λ),

and the lemma follows.

Lemma 4.13.2. Suppose that ΠAE is correct (theorem 4.2.7). Then, for all (unbounded) adversaries A, we

have ∣∣Pr[Hyb1(A) = 1]− Pr[Hyb2(A) = 1]∣∣ = 0.

Proof. The only difference between the two hybrid experiments is in the way the challenger decrypts the

ciphertext headers. For each query to OReEncrypt

(i, j, (ct, ct)

)and OChallenge(i, j,m, (ct, ct)), the challenger

in Hyb1 computes µ ← AE.Decrypt(ki, ct) while the challenger in Hyb2 sets µ ← Theader[i, ct]. The rest of

the experiments remain identical.

By the correctness condition for ΠAE, these two distributions of µ in the two experiments are identically

distributed as long as (i, ct) is contained in Theader. However, in both Hyb1 and Hyb2, if ct is not contained in

Theader, the challenger returns ⊥. Therefore, the view ofA in the two experiments are identically distributed.


Lemma 4.13.3. Suppose that ΠAE satisfies εconfae -confidentiality (theorem 4.2.8). Then, for all efficient ad-

versaries A, we have

∣∣Pr[Hyb2(A) = 1]− Pr[Hyb3(A) = 1]∣∣ ≤ h · εconfae (λ).

Proof. To prove the lemma, we proceed via a sequence of inner hybrid experiments. For γ = 0, . . . , h, we

define the hybrid experiments Hyb2,γ as follows:

• Hyb2,γ : The challenger proceeds through the setup phase of the experiment according to the specifica-

tions in Hyb2 and Hyb3 (which are identical). The challenger answers each of A’s queries during the

query phase of the experiment as follows:

– OEncrypt(i,m): If i > γ, then the challenger proceeds as in Hyb2. Otherwise, the challenger

proceeds as in Hyb3.

– OReEncrypt

(i, j, (ct, ct)

): If i > γ, then the challenger proceeds as in Hyb2. Otherwise, the

challenge proceeds as in Hyb3.

– OChallenge(i, j,m, (ct, ct)): If i > γ, then the challenger proceeds as in Hyb2. Otherwise, the

challenger proceeds as in Hyb3.

At the end of the experiment, adversary A outputs a bit b, which the challenger returns as the output of

the experiment.

By definition, experiment Hyb2,0 corresponds to experiment Hyb2, and experiment Hyb2,h corresponds to

experiment Hyb3. To prove the lemma, we show that each consecutive hybrid experiments Hyb2,γ−1 and

Hyb2,γ for γ = 1, . . . , h are computationally indistinguishable.

Claim 4.13.4. Suppose that ΠAE satisfies εconfae -confidentiality. Then, for all γ ∈ [h] and all efficient adver-

saries A, we have ∣∣Pr[Hyb2,γ−1(A) = 1]− Pr[Hyb2,γ(A)]∣∣ ≤ εconfae (λ).

Proof. Let A be an adversary that distinguishes experiments Hyb2,γ−1 and Hyb2,γ . We construct an algo-

rithm B that uses A to break the confidentiality of ΠAE. Algorithm B works as follows:

• Setup phase: For the setup phase, algorithm B proceeds according to the specifications in Hyb2,γ−1

and Hyb2,γ (which are identical). However, for the key kγ , it leaves it unspecified.


– OEncrypt(i,m): Algorithm B follows the exact specification of the two experiments. However,

since kγ is unspecified, it uses the encryption oracle

Okγ ,b

((s, |ctpayload|, kae,⊥), (0|s|, 0intlen, 0|kae|, 0λ)

),


in place of AE.Encrypt(kγ , (s, |ctpayload|, kae,⊥)

)or AE.Encrypt

(kγ , (0


– OReEncrypt

(i, j, (ct, ct)

): Algorithm B follows the exact specification of the two experiments.

However, since kγ is unspecified, it uses the encryption oracle

Okγ ,b

((s′, `, k′ae, k

′history), (kj , (0


′history|)

),

in place of AE.Encrypt(kγ , (s


)or AE.Encrypt

(kγ , (0


′history|)

).

– OChallenge(i, j,m, (ct, ct)): Algorithm B follows the exact specification of the two experiments.

However, since kγ is unspecified, it uses the encryption oracleOkγ ,b instead of AE.Encrypt(kγ , ·)as described above for encryption and re-encryption.

• Output phase: At the end of the experiment, adversary A outputs a bit b ∈ 0, 1, which B returns as

its own output.

By specification, algorithm B perfectly simulates the experiments Hyb2,γ and Hyb2,γ−1 as long as the out-

put of the oracle Okγ ,b(·, ·) is consistent with the specifications of the two experiments. By specification

(theorem 4.2.8), we have

Okγ ,0


)= AE.Encrypt

(kγ , (s, |ctpayload|, kae,⊥)

),

and

Okγ ,1


)= AE.Encrypt

(kγ , (0


This means that if B is interacting with the oracle Okγ ,0, then it perfectly simulates Hyb2,γ−1, and if it is

interacting with the oracle Okγ ,1, then it perfectly simulates Hyb2,γ . Therefore, with the same distinguishing

advantage of the two experiments by A, algorithm B breaks the confidentiality of ΠAE. The claim now

follows.

The statement of the lemma now follows from theorem 4.13.4 and the triangle inequality.

Lemma 4.13.5. Suppose that G : 0, 1λ → 0, 1∗ satisfies εprg PRG security (theorem 4.2.2). Then, for

all efficient adversaries A that make at most Q oracle queries, we have

∣∣Pr[Hyb3(A) = 1]− Pr[Hyb4(A) = 1]∣∣ ≤ Q · εprg(λ).

Proof. To prove the lemma, we proceed via a sequence of inner hybrid experiments. For γ = 0, . . . , Q, we



tions in Hyb3 and Hyb4 (which are identical). The challenger numbers A’s oracle queries and answers

each of A’s kth query during the query phase of the experiment as follows:


– OEncrypt(i,m): If k > γ, then the challenger proceeds as in Hyb3. Otherwise, the challenger


– OReEncrypt

(i, j, (ct, ct)

): If k > γ, then the challenger proceeds as in Hyb3. Otherwise, the


– OChallenge(i, j,m, (ct, ct)): If k > γ, then the challenger proceeds as in Hyb3. Otherwise, the



the experiment.

By definition, experiment Hyb3,0 corresponds to experiment Hyb3, and experiment Hyb3,Q correponds to


Hyb3,γ for γ = 1, . . . , Q are computationally indistinguishable.

Claim 4.13.6. Suppose that G : 0, 1λ → 0, 1∗ satisfies εprg PRG security (theorem 4.2.2). Then, for all

γ ∈ [Q] and all efficient adversaries A, we have

∣∣Pr[Hyb3,γ−1(A) = 1]− Pr[Hyb3,γ(A)]∣∣ ≤ εprg(λ).

Proof. Let A be an adversary that distinguishes experiments Hyb3,γ−1 and Hyb3,γ . We construct an al-

gorithm B that uses A to break the PRG security of G. Algorithm B proceeds according to the specifica-

tion of Hyb3,γ−1, except in the γth call to G, if it is in an execution of OEncrypt(i,m) where i ≤ h or of

OReEncrypt

(i, j, (ct, ct)

)orOChallenge(i, j,m, (ct, ct)) where j ≤ h, it passes on its input instead of evaluating

G. At the end of the experiment, B passes on A’s output as its own output.

Since the seed on which G is evaluated by the challenger does not appear in the view of the adversary

A, B provides a perfect simulation of Hyb3,γ−1 if its input is a PRG evaluation and a perfect simulation of

Hyb3,γ if its input is a truly random string. Therefore, with the same distinguishing advantage of the two

experiments by A, algorithm B breaks the PRG security of G. The claim now follows.


Lemma 4.13.7. Suppose that AE.Encrypt satisfies εrandae ciphertext pseudorandomness (theorem 4.2.10).

Then, for all efficient adversaries A that make at most Q oracle queries, we have

∣∣Pr[Hyb4(A) = 1]− Pr[Hyb5(A) = 1]∣∣ ≤ Q · εrandae (λ).




tions in Hyb4 and Hyb5 (which are identical). The challenger numbersA’s oracle queries, starting from


Q and counting backwards, and answers A’s kth last query during the query phase of the experiment

as follows:



– OReEncrypt

(i, j, (ct, ct)



– OChallenge(i, j,m, (ct, ct)): If k > γ, then the challenger proceeds as in Hyb4. Otherwise, the



the experiment.

By definition, experiment Hyb4,0 corresponds to experiment Hyb4, and experiment Hyb4,Q correponds to



Claim 4.13.8. Suppose that AE.Encrypt satisfies εrandae ciphertext pseudorandomness (theorem 4.2.10). Then,

for all γ ∈ [Q] and all efficient adversaries A, we have

∣∣Pr[Hyb4,γ−1(A) = 1]− Pr[Hyb4,γ(A)]∣∣ ≤ εrandae (λ).


rithm B that uses A to break the ciphertext pseudorandomness of AE.Encrypt. Algorithm B answers each

of A’s oracle queries exactly as the challenger in Hyb4,γ , except it answers the γth query (starting counting

queries from Q and counting downward) as follows:

• OEncrypt(i,m): This query is handled identically to challenger Hyb4,γ .

• OReEncrypt

(i, j, (ct, ct)

): If j ≤ h, B answers the oracle query exactly as in Hyb4,γ , but it sets the value

cthistory ← F ((kae, khistory)) where F (·) is the oracle provided to B in the ciphertext pseudorandomness

experiment. The rest of the simulation in answering A’s queries remains unchanged.

• OChallenge(i, j,m, (ct, ct)): If j ≤ h, B answers the oracle query exactly as in Hyb4,γ , but it sets the

value cthistory ← F ((kae, khistory)) where F (·) is the oracle provided to B in the ciphertext pseudoran-

domness experiment. The rest of the simulation in answering A’s queries remains unchanged.

Apart from the changes described above, B simulates the challenger of Hyb4,γ exactly. At the end of the

experiment, adversary A outputs a bit b ∈ 0, 1, which B returns as its own output.

By specification, algorithm B perfectly simulates the experiment Hyb4,γ or Hyb4,γ−1 depending on

whether the output of the oracle F (·) corresponds to evaluation of AE.Encrypt(·, ·) or a randomly chosen

function f(·). This is the case because if j ≤ h, the key k′history does not appear in the adversary A’s view: it


was erased from the ciphertext header in Hyb3, and the value of cthistory that is based on it was replaced with

the output of a random function in a previous subhybrid Hyb4,γ′ (this is why we begin counting queries from

the last query instead of the first). If j ≥ h, the hybrids Hyb4,γ and Hyb4,γ−1 are defined identically. There-

fore, with the same distinguishing advantage of the two experiments by A, algorithm B breaks the ciphertext

pseudorandomness of AE.Encrypt. The claim now follows.





Proof. This proof is analogous to the proof of theorem 4.13.7, so we omit it.

Lemma 4.13.10. For all (unbounded) adversaries A, we have

∣∣Pr[Hyb6(A) = 1]− Pr[Hyb7(A) = 1]∣∣ = 0.

Proof. The only difference between the two hybrid experiments is in the way the challenger responds to A’s

challenge oracle queries toOChallenge. Namely, to generate a ciphertext body ct′ on a queryOChallenge

(i, j,m, (ct, ct)

),

the challenger in Hyb6 computes ct′payload ← fkae(m) and ct′pad ←R 0, 1t·(2ρ+ν), and then it sets ct′ ←

(ct′payload, ct′pad). The challenger in Hyb7 computes ∆i,j,ct ← ReKeyGen(ki, kj , ct), ct′payload ← fk′ae(ctpayload, cthistory),

and ct′pad ←R 0, 1|ct|−|ct

′payload| and then sets ct′ ← (ct′payload, ct

′pad). However, since fkae(·) and fk′ae(·) are

completely random functions, these two distributions of the ciphertext body components are identically dis-

tributed independent of m or ct as long as the resulting ciphertexts have the same length. By specification, the

challenger returns ct′ only when this is the case. Therefore, the view of A in Hyb6 and Hyb7 are identically

distributed and the lemma follows.




Proof. The proof is identical to the proof of Lemma 4.13.9.






Lemma 4.13.13. Suppose that G : 0, 1λ → 0, 1∗ satisfies εprg PRG security (theorem 4.2.2). Then, for

all efficient adversaries A that make at most Q oracle queries, we have

∣∣Pr[Hyb9(A) = 1]− Pr[Hyb10(A) = 1]∣∣ ≤ Q · εprg(λ).


Lemma 4.13.14. Suppose that ΠAE satisfies εconfae -confidentiality (theorem 4.2.8). Then, for all efficient

adversaries A, we have



Lemma 4.13.15. Suppose that ΠAE is correct (Definition 4.2.7). Then, for all (unbounded) adversaries A,

we have ∣∣Pr[Hyb11(A) = 1]− Pr[Hyb12(A) = 1]∣∣ = 0.





By combining the lemmas above and using the triangle inequality, the proof of update independence follows.

Message confidentiality and re-encryption indistinguishability. The proofs of message confidentiality

and re-encryption indistinguishability are almost identical to the proof of update independence. In addition

to modifying the first and the final hybrid experiments, we can adapt the proof of update independence as

follows:

• The proofs of message confidentiality and re-encryption indistinguishability do not include hybrids

Hyb4 and Hyb10, which rely on the security of the PRG G. The definitions of message confidentiality

and re-encryption indistinguishability (theorem 4.9.1 and theorem 4.9.2) do not require hiding whether

a ciphertext is a fresh encryption or a re-encryption.

• The proofs of message confidentiality and re-encryption indistinguishability rely on the confidentiality

of ΠAE instead of ciphertext pseudorandomness in the hybrid experiments Hyb5, Hyb6, Hyb8 and Hyb9.

The definitions of message confidentiality and re-encryption indistinguishability do not hide whether


a ciphertext is a fresh encryption or a re-encryption, so the content of an encryption need not appear

random to hide where the encryption ends and a PRG output begins.

• The definitions of message confidentiality and re-encryption indistinguishability include an additional

ReKeyGen oracle OReKeyGen, so the the proofs of message confidentiality and re-encryption indistin-

guishability must also discuss this oracle. Changes made to this oracle in all hybrids are identical to

changes made to the OReEncrypt oracle in the proof above.

4.13.4 Proof of Integrity

We proceed via a sequence of hybrid experiments that are defined as follows:

• Hyb0: This hybrid experiment corresponds to the real updatable authenticated encryption update inde-

pendence experiment ExptintΠUAE(λ, h, d,A) that is instantiated with Construction 4.4.2.



look-up table Theader that keeps track of all of the “well-formed” ciphertext headers (under honest keys)

that A receives from the challenger throughout the experiment. The table is initially set to be empty,

and the challenger answers each of A’s oracle queries as follows:


header

ct← AE.Encrypt(ki, (s, |ctpayload|, kae,⊥)

),

and the ciphertext body as specified in construction 4.4.2. After returning the ciphertext (ct, ct)

to A, it additionally adds the mapping Theader[i, ct]← (s, |ctpayload|, kae,⊥) to the table if i ≤ h.

– OReKeyGen

(i, j, ct

): If i ≤ h, then the challenger first checks if Theader[i, ct] = ⊥ and outputs⊥ if

this is the case. If Theader[i, ct] 6= ⊥ or i > h, then the challenger proceeds exactly as in Hyb0, by

setting ct′ ← AE.Encrypt

(kj , (s


), computing ∆i,j,ct, and returning it to A. After

returning ∆i,j,ct to A, it adds the mapping Theader[j, ct′]← (s′, l, k′ae, k


– OReEncrypt

(i, j, (ct, ct)

): If i ≤ h, then the challenger first checks if Theader[i, ct] = ⊥ and output

⊥ if this is the case. If Theader[i, ct] 6= ⊥ or i > h, then the challenger proceeds exactly as

in Hyb0 by setting ct′ ← AE.Encrypt

(kj , (s


), computing ∆i,j,ct, and returning

ReEncrypt(∆i,j,ct, (ct, ct)

)toA. After returning the updated ciphertext toA, it adds the mapping

Theader[j, ct′]← (s′, l, k′ae, k


At the end of the experiment, adversaryA outputs an index i ≤ h and a ciphertext (ct, ct). As specified

in Hyb0, the challenger checks the following conditions, outputting ⊥ if either are met:

– m = ⊥,


– T[i, ct] = ct.

In addition, when invoking the decryption algorithm Decrypt above, the challenger verifies whether

Theader[i, ct] = ⊥. If this is the case, then the challenger also outputs ⊥. If none of the conditions are

met, then the challenger returns 1 as the output of the experiment.

During the output phase of the experiment, when the challenger is decrypting the purported forged

ciphertext (ct, ct), when the challenger computes µ ← AE.Decrypt(k, ct) (which occurs in step 1 of

decryption), it also checks the table Theader and sets µ′ ← Theader[i, ct]. If µ 6= µ′, the challenger

aborts the experiment and outputs ⊥.





simulation for honest keys in ciphertext headers. Namely, the challenger answers A’s ReKeyGen and

ReEncrypt oracle queries as follows when i ≤ h:

– OReKeyGen

(i, j, ct

): The challenger answers the oracle exactly as in Hyb1, but instead of decrypt-

ing the ciphertext header µ ← AE.Decrypt(ki, ct), it sets µ ← Theader[i, ct]. If no such entry

exists in Theader, then it immediately aborts the experiment and outputs ⊥.

– OReEncrypt

(i, j, (ct, ct)



entry exists in Theader, then it immediately aborts the experiment and outputs ⊥.

In the output phase, the challenger answers the oracle exactly as in Hyb1, but instead of decrypting the

ciphertext header µ← AE.Decrypt(ki, ct), it sets µ← Theader[i, ct]. If no such entry exists in Theader,

then it immediately aborts the experiment and outputs ⊥.




• Hyb3: In this hybrid experiment, we erase the contents of ciphertext headers for honest keys. Namely,

the challenger answers each of A’s oracle queries as follows, where intlen represents the number of

bits required to represent an integer:

– OEncrypt(i,m): If i ≤ h, the challenger answers the oracle query exactly as in Hyb2, but it sets

the ciphertext header ct to be





– OReKeyGen

(i, j, ct

): If j ≤ h, the challenger answers the oracle query exactly as in Hyb2, but it

sets the ciphertext header ct′ to be


(kj , (0


′history|)

).


– OReEncrypt

(i, j, (ct, ct)

): If j ≤ h, the challenger answers the oracle query exactly as in Hyb2,



(kj , (0


′history|)

).





• Hyb4: In this hybrid we erase the contents of cthistory ciphertexts produced under honest keys. Namely,

the challenger answers each of A’s ReKeyGen and ReEncrypt oracle queries as follows:

– OReKeyGen

(i, j, ct

): If j ≤ h, the challenger answers the oracle exactly as in Hyb3, but instead of

setting cthistory ← AE.Encrypt(k′history, (kae, khistory)), it sets cthistory to be

cthistory ← AE.Encrypt(k′history, (0|kae|, 0|khistory|)).


– OReEncrypt

(i, j, (ct, ct)

): If j < h, the challenger answers the oracle exactly as in Hyb3, but

instead of setting cthistory ← AE.Encrypt(k′history, (kae, khistory)), it sets cthistory to be







look-up table Tpayload that keeps track of all of the “well-formed” payload ciphertexts ctpayload under


honest keys that A receives from the challenger throughout the experiment. The table is initially set to

be empty, and the challenger answers A’s Encrypt and ReEncrypt oracle queries as follows:

– OEncrypt(i,m): The challenger proceeds exactly as in Hyb4 and sets ctpayload ← AE.Encrypt(kae,m).

However, it also adds the mapping Tpayload[kae, ctpayload]← m to the table.

– OReEncrypt

(i, j, (ct, ct)

): The challenger proceeds exactly as in Hyb4 and sets ct′payload ← AE.Encrypt

(k′ae,

(ctpayload, cthistory)). However, it also adds the mapping Tpayload[k

′ae, ct

′payload]← (ctpayload, cthistory)

to the table.

During the output phase of the experiment, when the challenger is decrypting the purported forged ci-

phertext (ct, ct), each time the challenger computes µ← AE.Decrypt(k′ae, ctpayload) or µ← AE.Decrypt(kae, ct)

(which occurs in steps 4 and 6 of decryption), it also checks the table Tpayload and sets µ′ ← Tpayload[k′ae, ctpayload]

or µ′ ← Tpayload[kae, ct] respectively. If µ 6= µ′, the challenger aborts the experiment and outputs ⊥.

This check is skipped if there is no entry in Tpayload[k′ae, ·] or Tpayload[kae, ·] respectively, i.e., if the pay-

load key in question was never used by the challenger. The rest of the experiment remains unchanged

from Hyb4.



Finally, in theorem 4.13.23 below, we show that an adversary has negligible advantage in forcing the

challenger to output 1 in Hyb5.






Proof. This proof is almost identical to that of theorem 4.13.1, so we omit the full proof.



Proof. The only difference between the two hybrid experiments is in the way the challenger decrypts the

ciphertext headers. For each query to OReKeyGen

(i, j, ct

)or OReEncrypt

(i, j, (ct, ct)

), as well as in the output

phase, the challenger in Hyb1 computes µ ← AE.Decrypt(ki, ct) while the challenger in Hyb2 sets µ ←Theader[i, ct]. The rest of the experiments remains identical.








Proof. This proof is almost identical to that of theorem 4.13.3, so we omit the full proof.


adversaries A that make at most Q oracle queries, we have

∣∣Pr[Hyb3(A) = 1]− Pr[Hyb4(A) = 1]∣∣ ≤ Q · εconfae (λ).




tions in Hyb3 and Hyb4 (which are identical). The challenger numbersA’s oracle queries, starting from

Q and counting backwards, and answers A’s kth last query during the query phase of the experiment

as follows:



– OReKeyGen

(i, j, ct

): If k > γ, then the challenger proceeds as in Hyb3. Otherwise, the challenger


– OReEncrypt

(i, j, (ct, ct)




the experiment.

By definition, experiment Hyb3,0 corresponds to experiment Hyb3, and experiment Hyb3,Q corresponds to







rithm B that uses A to break the confidentiality of ΠAE. Algorithm B answers each of A’s oracle queries

exactly as the challenger in Hyb3,γ , except it answers the γth query (starting couting queries from Q and

counting downwards) as follows:

• OEncrypt(i,m): This query is handled identically to challenger Hyb3,γ .

• OReKeyGen

(i, j, ct

): If j ≤ h, B answers the oracle query exactly as in Hyb3,γ , but it sets

cthistory ← Okγ ,b((kae, khistory), (0|kae|, 0|khistory|))

instead of setting


or



• OReEncrypt

(i, j, (ct, ct)

): If j ≤ h, B answers the oracle query exactly as in Hyb3,γ , but it sets

cthistory ← Okγ ,b((kae, khistory), (0|kae|, 0|khistory|))

instead of setting


or



Apart from the changes described above, B simulates the challenger of Hyb3,γ exactly. At the end of the

experiment, adversary A outputs a bit b ∈ 0, 1, which B returns as its own output.

By specification, algorithm B perfectly simulates the experiments Hyb3,γ and Hyb3,γ−1 as long as the

output of the oracle Okγ ,b(·, ·) is consistent with the specifications of the two experiments. By specification


Okγ ,0((kae, khistory), (0|kae|, 0|khistory|)) = cthistory ← AE.Encrypt(k′history, (kae, khistory)),

and

Okγ ,1((kae, khistory), (0|kae|, 0|khistory|)) = AE.Encrypt(k′history, (0

|kae|, 0|khistory|)).


interacting with the oracle Okγ ,1, then it perfectly simulates Hyb3,γ . This is the case because if j ≤ h, the


key k′history does not appear in the adversary A’s view: it was erased from the ciphertext header in Hyb3, and

it was erased from cthistory in a previous subhybrid Hyb3,γ′ (this is why we begin counting queries from the

last query instead of the first). If j ≥ h, the hybrids Hyb3,γ and Hyb3,γ−1 are defined identically. Therefore,

with the same distinguishing advantage of the two experiments by A, algorithm B breaks the confidentiality

of ΠAE. The claim now follows.



A that make at most Q oracle queries, we have

∣∣Pr[Hyb4(A) = 1]− Pr[Hyb5(A) = 1]∣∣ ≤ Q · εintae (λ).

Proof. Let A be an adversary that distinguishes experiments Hyb4 and Hyb5. We construct an algorithm Bthat uses A to break the integrity of ΠAE (theorem 4.2.9). Algorithm B proceeds through the setup phase of

the experiment according to the specifications in Hyb4 and Hyb5 (which are identical). Then it samples a

random index c∗ ←R [Q]. The challenger counts A’s oracle queries and answers each of A’s cth query during

the query phase of the experiment as follows:

• OEncrypt(i,m): If c = c∗, algorithm B proceeds according to the specification in Hyb5. Otherwise, it

proceeds according to Hyb4. In both cases, whenever B must use c∗th value of kae to generate the ci-

phertext ctpayload ← AE.Encrypt(kae,m), it uses the encryption oracleOkc∗ (·) for ΠAE (theorem 4.2.9).

If c = c∗ and B must abort, it submits the c∗th value of cthistory as a forgery for ΠAE.

• OReKeyGen

(i, j, ct

): If c = c∗, algorithm B proceeds according to the specification in Hyb5. Otherwise,

it proceeds according to Hyb4. In both cases, whenever B must use c∗th value of k′ae to generate the

ciphertext ct′payload ← AE.Encrypt(k′ae, (ctpayload, cthistory)), it uses the encryption oracle Okc∗ (·) for

ΠAE (theorem 4.2.9). If c = c∗ and B must abort, it submits the c∗th value of cthistory as a forgery for

ΠAE.

• OReEncrypt

(i, j, (ct, ct)

): If c = c∗, algorithm B proceeds according to the specification in Hyb5. Oth-

erwise, it proceeds according to Hyb4. In both cases, whenever B must use c∗th value of k′ae to generate

the ciphertext ct′payload ← AE.Encrypt(k′ae, (ctpayload, cthistory)), it uses the encryption oracle Okc∗ (·)for ΠAE (theorem 4.2.9). If c = c∗ and B must abort, it submits the c∗th value of cthistory as a forgery

for ΠAE.

At the end of the experiment, adversary A outputs a bit b ∈ 0, 1, which algorithm B returns as the output

of the experiment.

By definition, the only difference between the hybrid experiments Hyb4 and Hyb5 is the additional abort

condition when the challenger answers an adversary’s oracle queries in Hyb5. Therefore, by definition,

algorithm B perfectly simulates A’s views of the experiments Hyb4 and Hyb5 modulo the abort conditions.


Furthermore, by the specification of B, if A forces B to abort in any of these queries, then B successfully

forges a new ciphertext for ΠAE.




• Let Xc for c ∈ [Q] denote the event that c = c∗ during B’s simulation above.

• Let Yc for c ∈ [Q] denote the event that adversary A forces the challenger to abort in Hyb5 by submit-

ting a query OEncrypt(i,m), OReKeyGen

(i, j, ct

), or OReEncrypt

(i, j, (ct, ct)

).

The lemma now follows from the identical argument used to prove theorem 4.13.1.


∣∣Pr[Hyb5(A) = 1]∣∣ ≤ Q/2λ.

Proof. We now prove that the adversary in Hyb5 has an at most negligible probability of forging a UAE

ciphertext (ct, ct) under a key ki of its choosing, i ≤ h. For the sake of contradiction, suppose that Asuccessfully produces such a forgery.

First, recall that if the experiment completes without aborting, then ct must appear in Theader. Thus we

can recover (s′, `, k′ae, k′history) ← Theader[i, ct], the plaintext of ct. If G(s′) 6= ctpad, then decryption would

fail (in step 3), so it must be thatG(s′) = ctpad. This means we can strip off ctpad from ct to recover ctpayload.

Now consider µ ← Tpayload[k′ae, ctpayload]. Since decryption completes without aborting, this entry must

exist. Observe that since k′ae contains λ bits of entropy, the probability of Tpayload containing two or more

entries of the form Tpayload[k′ae, ·] is at most Q/2λ. We will only consider the case where there is only one

such entry. By construction, Tpayload[k′ae, ctpayload] must be added to Tpayload in the same oracle call that

Theader[i, ct] is added to Theader. This means that, in the same oracle call, the entry T[i, ct]← ct was added to

T, for ct = (ctpayload, ctpad). But this is a contradiction because (ct, ct) cannot be a forgery for ki if it appears

in the table. Thus a successful forgery in Hyb5 leads to a contradiction with probability at least 1 − Q/2λ,

completing the proof.

By combining the lemmas above and using the triangle inequality, the proof of integrity follows.



4.14.1 Proof of Strong Compactness

Fix the security parameter λ, number of updates N ∈ N, and any message m ∈ Mλ. Let k0, . . . , kN ←KeyGen(1λ), (ct0, ct0)← Encrypt(k0,m),

∆i,i+1,cti ← ReKeyGen(ki, ki+1, cti), and

(cti+1, cti+1)← ReEncrypt(∆i,i+1,cti , (cti, cti)

),

for i = 0, . . . , N − 1.

Ciphertext header: by the specification of Encrypt and ReEncrypt, we have that cti = AE.Encrypt(ki, (kprf , h)),

where kprf ∈ KPRF and h = H(m). The PRF key space KPRF depends only on the security parameter, and

by definition ofH, we have |h| = λ. Thus every ciphertext header has the same fixed length.

Ciphertext body: by construction, the ciphertext body cti has the form cti = (ct1, ..., ct`) where ` ∈ N is

the size of the output, in blocks, of (m1, ...,m`) ← Pad(m), which depends only on m and does not change

with the number of re-encryptions. Thus every ciphertext body has the same length, dependent only on the

underlying plaintext message.

Re-encryption key: The re-encryption key ∆i,i+1,cti consists of a new ciphertext header ct′ and a PRF key

kupprf . By the specification of ReEncrypt, we have ct′

=(ki+1, (k

′prf , h)

)where k′prf ∈ KPRF and h = H(m),

and therefore, we have |ct′| = |ct|, as established above. Furthermore, by specification, kupprf ←R KPRF and

therefore, the size |kupprf | is always fixed and depends only on the security parameter. This shows that the size

|∆i,i+1,ct| always has the same fixed length.

4.14.2 Proof of Correctness

Fix the security parameter λ ∈ N, number of updates N = poly(λ), and any message m ∈ Mλ. Let

k1, . . . , kN ← KeyGen(1λ), (ct1, ct1)← Encrypt(k1,m), and


),

for i = 1, . . . , N − 1. We must show that

Decrypt(kN , (ctN , ctN )

)= m.

To do this, we show that (cti, cti) for i ∈ [N ] satisfies:

• cti = AE.Encrypt(k, (kprf , h)

)for a PRF key kprf ∈ KPRF and h = H(m).


• cti = (cti,1, . . . , cti,`) where each ciphertext block cti,j for j ∈ [`] has the form

cti,j ← mj + F (kprf,i, j) + ei,j ,

for some |ei,j | ≤ i · β and (m1, . . . ,m`)← Pad(m).

This implies that Decrypt(kN , (ctN , ctN )

)= m by the specification of Decrypt and the correctness of the

encoding scheme.

The show that (cti, cti) for i ∈ [N ] has the form as above, we proceed via induction.

• The ciphertext (ct1, ct1) has the form above simply by the specification of the Encrypt algorithm.

• Now assuming that (cti−1, cti−1) for some i ∈ [N ] has the form above, let us consider (cti, cti). We

know that (cti−1, cti−1 satisfies

– cti−1 = AE.Encrypt(ki−1, (kprf,i−1, h)

)for a PRF key kprf,i−1 ∈ KPRF and h = H(m).

– cti−1 = (cti−1,1, . . . , cti−1,`) where each ciphertext block for j ∈ [`] has the form

cti−1,j ← mi−1,j + F (kprf , j) + ei−1,j ,

for some noise |ei−1,j | ≤ (i− 1) · β.

On input two keys ki−1, ki, and ciphertext header cti−1, the ReKeyGen algorithm proceeds as follows:

1. It decrypts (k′prf,i−1, h′)← AE.Decrypt(ki−1, cti−1).

2. It samples a new PRF key kprf,i ←R KPRF and defines kupprf ← kprf,i − k′prf,i−1.

3. It sets ct′i ← AE.Encrypt(ki, (kprf,i, h

′))

and ∆i−1,i ← (ct′i, k

upprf).

By the correctness of ΠAE (theorem 4.2.7), we have k′prf,i−1 = kprf,i−1 and h′ = h. Therefore, we have

ct′i = AE.Encrypt

(ki, (kprf,i, h)

)and kupprf = kprf,i − kprf,i−1.

Now, on input ∆i−1,i = (cti, kupprf) and ciphertext (cti−1, cti−1), the ReEncrypt algorithm proceeds as

follows:

1. It sets cti ← ct′i = AE.Encrypt

(ki, (kprf,i, h)

).

2. For cti = (cti,1, . . . , cti,`), it sets

cti,j ← cti−1,j + F (kupprf , j) =(mi + F (kprf,i−1, j) + ei−1,j

)+(F (kprf,i − kprf,i−1, j)

)= mi + F (kprf,i, j) + ei−1,j + e′i,j ,

for error |e′i,j | ≤ β for j = 1, . . . , `. This means that |ei−1,j + e′i,j | ≤ i · β.

Correctness now follows.


4.14.3 Proof of Confidentiality


• Hyb0: This hybrid experiment corresponds to the real updatable authenticated encryption confidential-

ity experiment ExptconfΠUAE(λ, h, d,A, 0) that is instantiated with Construction 4.5.2.

• Hyb1: In this hybrid experiment, we introduce an abort condition to the challenger’s simulation.

Namely, throughout the query phase of the experiment, the challenger maintains an additional look-up

table Theader that keeps track of all of the “well-formed” ciphertext headers under honest keys that

A receives from the challenger throughout the experiment. The table is initially set empty and the

challenger answers each of A’s oracle queries as follows:


header

ct← AE.Encrypt(ki, (kprf , h)

),

and the ciphertext body ct = (ct1, . . . , ct`) according to the specification of Encrypt(ki,m). Fur-

thermore, after returning the ciphertext (ct, ct) toA, it additionally adds the mapping Theader[i, ct]←(kprf , h) to the table.

– OReKeyGen(i, j, ct): If i ≤ h, then the challenger checks if Theader[i, ct] = ⊥ and outputs ⊥if this is the case. If Theader[i, ct] 6= ⊥ or i > h, then the challenger proceeds exactly as in

Hyb0 by computing ct′ ← AE.Encrypt

(kj , (k

′prf , h)

), and returning ∆i,j,ct ← (ct

′, kupprf) to A.

Furthermore, if j ≤ h, then it adds the mapping Theader[j, ct′]← (k′prf , h) to the table.

– OReEncrypt

(i, j, (ct, ct)

): If i ≤ h, then the challenger checks if Theader[i, ct] = ⊥ and out-

puts ⊥ if this is the case. If Theader[i, ct] 6= ⊥ or i > h, then the challenger proceeds exactly

as in Hyb0 by computing ct′ ← AE.Encrypt

(kj , (k

′prf , h)

), setting ∆i,j,ct ← (ct

′, kupprf), and

returning ReEncrypt(∆i,j,ct, (ct, ct)

)to A. Furthermore, if j ≤ h, then it adds the mapping

Theader[j, ct′]← (k′prf , h) to the table.

– OChallenge(i, j,m, (ct, ct)): If i ≤ h, then the challenger checks if Theader[i, ct] = ⊥ and outputs

⊥ if this is the case. If Theader[i, ct] 6= ⊥ or i > h, then the challenger answers the oracle query

exactly as in Hyb0 by generating the ciphertext header


(kj , (kprf , h)

),

and the ciphertext body ct′ = (ct′1, . . . , ct′`) according to the specification of Encrypt(kj ,m).

After returning the ciphertext (ct′, ct′) to A, it adds the mapping Theader[j, ct

′]← (kprf , h) to the

table.






simulation. Namely, the challenger answers A’s oracle queries exactly as in Hyb1. However, for the

re-encryption key generation, re-encryption, and challenge oracle queries where the input index i ≤ h,

the challenger works as follows:

– OReKeyGen(i, j, ct): The challenger answers the oracle exactly as in Hyb1, but instead of decrypt-

ing the ciphertext header µ ← AE.Decrypt(ki, ct), it sets µ ← Theader[i, ct]. If no such entry

exists in Theader, then it aborts the experiment and outputs ⊥.

– OReEncrypt

(i, j, (ct, ct)



entry exists in Theader, then it aborts the experiment and outputs ⊥.

– OChallenge(i, j,m, (ct, ct)): The challenger answers the oracle exactly as in Hyb1, but whenever it

must compute µ ← AE.Decrypt(ki, ct) in the call to ReKeyGen, it sets µ ← Theader[i, ct]. If no

such entry exists in Theader, then it aborts the experiment and outputs ⊥.




• Hyb3: In this hybrid experiment, we erase the PRF keys kprf and any information about the plaintext m

from the ciphertext headers. Namely, the challenger answers each of A’s oracle queries as follows:

– OEncrypt(i,m): The challenger answers the oracle query exactly as in Hyb2, but instead of setting

the ciphertext header ct← AE.Encrypt(ki, (kprf , h)

), it sets


|kprf |, 0|h|)).


– OReKeyGen(i, j, ct): If j > h, then the challenger answers the oracle query exactly as in Hyb2. If

j ≤ h, then instead of setting the new ciphertext header ct′ ← AE.Encrypt(k2, (k

′prf , h)

), it sets


(k2, (0

|k′prf |, 0|h|)).

– OReEncrypt

(i, j, (ct, ct)

): If j > h, then the challenger answers the oracle query exactly as in

Hyb2. If j ≤ h, then instead of setting the new ciphertext header ct′ ← AE.Encrypt(k2, (k

′prf , h)

),

it sets


(k2, (0

|k′prf |, 0|h|)).


– OChallenge(i, j,m, (ct, ct)): The challenger answers the oracle query exactly as in Hyb2, but in-

stead of setting the ciphertext header ct′ ← AE.Encrypt(kj , (kprf , h)

), it sets


(kj , (0

|kprf |, 0|h|)).





• Hyb4: In this hybrid experiment, we replace the PRF F with a completely random function. Namely,

when answeringA’s challenge oracle queriesOChallenge(i, j,m, (ct, ct)), instead of evaluating the PRFs

F (kprf , ·) and F (kupprf , ·), it uses a random function fkprf (·) or fkupprf (·) instead (for the PRF output that

affects the returned ciphertext). The rest of the experiment remains unchanged from Hyb3.


indistinguishable assuming that F : KPRF × 0, 1∗ → Y is a secure PRF.

• Hyb5: In this hybrid experiment, we modify the challenger from directly encrypting the message m to

re-encrypting the ciphertext (ct, ct) when answering A’s challenge query OChallenge

(i, j,m, (ct, ct)

).

Namely, on a query OChallenge

(i, j,m, (ct, ct)

), instead of computing (m1, . . . ,m`) ← Pad(m) and

setting ct′i ← mi + fkprf (i) for i ∈ [`], the challenger proceeds as follows:

1. It computes ∆i,j,ct ← ReKeyGen(ki, kj , ct),

2. It parses ∆i,j,ct = (ct′, kupprf), ct = (ct1, . . . , ct`),

3. It sets ct′i ← cti + fkupprf (i) for i ∈ [`].



guishable.

• Hyb6: Starting from this hybrid, we start unrolling back the changes that we made from Hyb0. In

this hybrid experiment, we undo the changes that we made in Hyb4 by replacing the random function

evaluations with true PRF evaluations.


indistinguishable assuming that F : KPRF × 0, 1∗ → Y is a secure PRF.

• Hyb7: In this hybrid experiment, we undo the changes that we made in Hyb3 by including the PRF

keys kprf and information about the plaintext m in the ciphertext headers.




• Hyb8: In this hybrid experiment, we undo the changes that we made in Hyb2 by re-introducing the

decryption algorithm AE.Decrypt in the challenger’s simulation.



• Hyb9: In this hybrid experiment, we undo the changes that we made in Hyb1 by removing the additional

abort condition.



This hybrid experiment corresponds to the real updatable authenticated encryption confidentiality ex-

periment ExptconfΠUAE(λ, h, d,A, 1).

We now show that each of the consecutive hybrid experiments are indistinguishable. For a hybrid experiment

Hyb and an adversaryA, we use Hyb(A) to denote the random variable representing the output of experiment

Hyb with adversary A.



Proof. Let A be an adversary that distinguishes experiments Hyb0 and Hyb1. We construct an algorithm Bthat uses A to break the integrity of ΠAE (theorem 4.2.9). Algorithm B works as follows:

• Setup phase: At the start of the experiment, algorithmB samples a random index i∗ ←R [h]. It generates

the keys ki for i ∈ [h+ d]\ i∗ according to the (identical) specifications of Hyb0 and Hyb1. For ki∗ ,

algorithm B leaves it unspecified.


– OEncrypt(i,m): If i 6= i∗, algorithm B proceeds according to Hyb0. If i = i∗, it proceeds ac-

cording to the specification in Hyb1. Whenever B must use ki∗ to generate the ciphertext header

ct← AE.Encrypt(ki∗ , (kprf , h)

), it uses the encryption oracle Ok∗i

(·) for ΠAE.

– OReKeyGen(i, j, ct): If i 6= i∗, then B proceeds according to the specification in Hyb0. If i = i∗,

then it proceeds according to the specification in Hyb1. In both cases, whenever B must use ki∗

to generate the ciphertext header ct′ ← AE.Encrypt(ki∗ , (k

′prf , h)

), it uses the encryption oracle

Ok∗i(·) for ΠAE (theorem 4.2.9). If i = i∗ and B must abort, it submits ct as a forgery for ΠAE.

– OReEncrypt

(i, j, (ct, ct)

): If i = i∗, algorithm B proceeds according to the specification in Hyb1.


ciphertext header ct′ ← AE.Encrypt(ki∗ , (k

′prf , h)


(·) for ΠAE

(theorem 4.2.9). If i = i∗ and B must abort, it submits ct as a forgery for ΠAE.


– OChallenge(i, j,m, (ct, ct)): If i = i∗, algorithm B proceeds according to the specification in Hyb1.


ciphertext header ct′ ← AE.Encrypt(ki∗ , (k

′prf , h)


(·) for ΠAE

(theorem 4.2.9). If i = i∗ and B must abort, then it submits ct as a forgery for ΠAE.

• Output phase: At the end of the experiment, adversary A outputs a bit b ∈ 0, 1, which algorithm Breturns as the output of the experiment.

By definition, the only difference between the hybrid experiments Hyb0 and Hyb1 is the additional abort con-

dition when the challenger answers an adversary’s re-encryption key generation, re-encryption, or challenge

queries in Hyb1. Therefore, by definition, algorithm B perfectly simulatesA’s views of the experiments Hyb0

and Hyb1 modulo the abort conditions. Furthermore, by the specification of B, if A forces B to abort in any

of these queries, then B successfully forges a new ciphertext for ΠAE.




• Let Xi for i ∈ [h] denote the event that i = i∗ during B’s simulation above.

• Let Yi for i ∈ [h] denote the event that adversaryA forces the challenger to abort in Hyb1 by submitting

a query OReKeyGen(i, j, ct), OReEncrypt

(i, j, (ct, ct)

), or OChallenge(i, j,m, (ct, ct)).

Then, by definition, algorithm B successfully forges a new authenticated encryption ciphertext whenA forces

algorithm B to abort on a queryOReKeyGen(i∗, j, ct),OReEncrypt

(i∗, j, (ct, ct)

), orOChallenge(i

∗, j,m, (ct, ct)):

Pr[Z]

=∑i∈[h]

Pr[Xi ∩ Yi

]=∑i∈[h]

Pr[Xi | Yi

]· Pr

[Yi]

=∑i∈[h]

1

h· Pr

[Yi]

=1

h

∑i∈[h]

Pr[Yi]

≥ 1

h· Pr

[Y1 ∪ . . . ∪ Yh

],

where the last inequality follows by the union bound. Now, since the only difference between the hybrid

experiments Hyb0 and Hyb1 is the additional abort condition when the challenger answersOReKeyGen(i, j, ct),

OReEncrypt

(i, j, (ct, ct)

), or OChallenge(i, j,m, (ct, ct)), an adversary’s advantage in distinguishing the two

experiments is bounded by the probability of the event Y1 ∪ . . . ∪ Yh:

∣∣Pr[Hyb0(A) = 1]− Pr[Hyb1(A) = 1]∣∣ ≤ Pr

[Y1 ∪ . . . ∪ Yh

].


Putting the two inequalities together, we have

∣∣Pr[Hyb0(A) = 1]− Pr[Hyb1(A) = 1]∣∣ ≤ Pr

[Y1 ∪ . . . ∪ Yh

]≤ h · Pr

[Z]

≤ h · εintae (λ),

and the lemma follows.



Proof. The only difference between the two hybrid experiments is in the way the challenger decrypts the ci-

phertext headers. For each queriesOReKeyGen(i, j, ct),OReEncrypt

(i, j, (ct, ct)

), andOChallenge

(i, j,m, (ct, ct)

),

the challenger in Hyb1 computes µ← AE.Decrypt(ki, ct) while the challenger in Hyb2 sets µ← Theader[i, ct].

The rest of the experiments remains identical.







Proof. To prove the lemma, we proceed via a sequence of inner hybrid experiment. For γ = 0, . . . , h, we



tions in Hyb2 and Hyb3 (which are identical). The challenger answers each of A’s queries during the

query phase of the experiment as follows:

– OEncrypt(i,m): If i > γ, then the challenger proceeds as in Hyb2. Otherwise, the challenger


– OReKeyGen(i, j, ct): If i > γ, then the challenger proceeds as in Hyb2. Otherwise, the challenger


– OReEncrypt

(i, j, (ct, ct)

): If i > γ, then the challenger proceeds as in Hyb2. Otherwise, the



– OChallenge(i, j,m, (ct, ct)): If i > γ, then the challenger proceeds as in Hyb2. Otherwise, the



the experiment.

By definition, experiment Hyb2,0 corresponds to experiment Hyb2, and experiment Hyb2,γ correponds to


Hyb2,γ for γ = 1, . . . , h are computationally indistinguishable.




rithm B that uses A to break the confidentiality of ΠAE. Algorithm B works as follows:

• Setup phase: For the setup phase, algorithm B proceeds according to the specifications in Hyb2,γ−1

and Hyb2,γ (which are identical). However, for the key kγ , it leaves it unspecified.


– OEncrypt(i,m): Algorithm B follows the exact specification of the two experiments. However,


Okγ ,b

((kprf , h), (0|kprf |, 0|h|)

),

in place of AE.Encrypt(kγ , (kprf , h)

)or AE.Encrypt

(kγ , (0

|kprf |, 0|h|)).

– OReKeyGen(i, j, ct): Algorithm B follows the exact specification of the two experiments. However,


Okγ ,b

((k′prf , h), (0|k

′prf |, 0|h|)

),


)or AE.Encrypt

(kγ , (0

|k′prf |, 0|h|)).

– OReEncrypt

(i, j, (ct, ct)

): Algorithm B follows the exact specification of the two experiments.


Okγ ,b

((k′prf , h), (0|k

′prf |, 0|h|)

),


)or AE.Encrypt

(kγ , (0

|k′prf |, 0|h|)).


– OChallenge(i, j,m, (ct, ct)): Algorithm B follows the exact specification of the two experiments.


Okγ ,b

((kprf , h), (0|kprf |, 0|h|)

),


)or AE.Encrypt

(kγ , (0

|kprf |, 0|h|)).

• Output phase: At the end of the experiment, adversary A outputs a bit b ∈ 0, 1, which B returns as

its own output.

By specification, algorithm B perfectly simulates the experiments Hyb2,γ and Hyb2,γ−1 as long as the out-

put of the oracle Okγ ,b(·, ·) is consistent with the specifications of the two experiments. By specification


Okγ ,0

((kprf , h), (0|kprf |, 0|h|)

)= AE.Encrypt

(kγ , (kprf , h)

),

and

Okγ ,1

((kprf , h), (0|kprf |, 0|h|)

)= AE.Encrypt

(kγ , (0

|kprf |, 0|h|)).


interacting with the oracle Okγ ,1, then it perfectly simulates Hyb2,γ . Therefore, with the same distinguishing

advantage of the two experiments by A, algorithm B breaks the confidentiality of ΠAE. The claim now

follows.


Lemma 4.14.5. Suppose that F : KPRF × 0, 1∗ → Y satisfies εprf -security (theorem 4.2.3). Then, for all

efficient adversaries A that makes Q challenge oracle queries to OChallenge, we have

∣∣Pr[Hyb3(A) = 1]− Pr[Hyb4(A) = 1]∣∣ ≤ Q · εprf(λ).



• Hyb3,γ : The challenger proceeds through the setup phase of the experiments according to the specifi-

cations in Hyb3 and Hyb4 (which are identical). The challenger also answers each ofA’s oracle queries

OReKeyGen, OEncrypt, OReEncrypt queries according the specifications in the two experiments. Algorithm

B answers A’s challenge oracle queries as follows:

– OChallenge(i, j,m, (ct, ct)): For A’s first γ queries, the challenger proceeds exactly as in Hyb3.

For the rest of the queries, it proceeds as in Hyb4.



the experiment.

By definition, experiment Hyb3,0 corresponds to experiment Hyb3, and experiment Hyb3,Q corresponds to

experiment Hyb4. The lemma follows by the computational indistinguishability of the consecutive hybrid

experiments Hyb3,γ−1 and Hyb3,γ for γ = 1, . . . , Q. The proof of the following claim follows immediately

from the definition of PRF security (theorem 4.2.3) and the fact that the adversary’s view is independent of

the PRF key kprf or kupprf used in the output ofOChallenge(i, j,m, (ct, ct)) as enforced by the checks on the table

T in the confidentiality definition.

Claim 4.14.6. Suppose that F : KPRF × 0, 1∗ → Y satisfies εprf -securitry. Then, for all γ ∈ [Q] and all

efficient adversaries A that makes at most Q challenge oracle queries OChallenge, we have

∣∣Pr[Hyb3,γ−1(A) = 1]− Pr[Hyb3,γ(A) = 1]∣∣ ≤ εprf(λ).



∣∣Pr[Hyb4(A) = 1]− Pr[Hyb5(A) = 1]∣∣ = 0.

Proof. The only difference between the two hybrid experiments is in the way the challenger responds to A’s

challenge oracle queries toOChallenge. Namely, to generate a ciphertext body ct′ on a queryOChallenge

(i, j,m, (ct, ct)

),

the challenger in Hyb4 computes (m1, . . . ,m`)← Pad(m) and sets

ct′i ← mi + fkprf (i)

for i ∈ [`], while the challenger in Hyb5 computes ∆i,j,ct ← ReKeyGen(ki, kj , ct) and sets

ct′i ← cti + fkupprf (i)

for i ∈ [`] where ∆i,j,ct = (ct′, kupprf), ct = (ct1, . . . , ct`). However, since fkprf (·) and fkupprf (·) are completely

random functions, these two distributions of the ciphertext body components are identically distributed inde-

pendent of m or ct as long as the resulting ciphertexts have the same length. By specification, the challenger

returns ct′ = (ct′1, . . . , ct′`) only when this is the case. Therefore, the view of A in Hyb4 and Hyb5 are

identically distributed and the lemma follows.

Lemma 4.14.8. Suppose that F : KPRF × 0, 1∗ → Y satisfies εprf -security (theorem 4.2.3). Then, for all

efficient adversaries A that makes Q challenge oracle queries to OChallenge, we have

∣∣Pr[Hyb5(A) = 1]− Pr[Hyb6(A) = 1]∣∣ ≤ Q · εprf(λ).







Lemma 4.14.10. Suppose that ΠAE is correct (Definition 4.2.7). Then, for all (unbounded) adversaries A,

we have ∣∣Pr[Hyb7(A) = 1]− Pr[Hyb8(A) = 1]∣∣ = 0.





By combining the lemmas above and using the triangle inequality, the proof of confidentiality follows.

4.14.4 Proof of Relaxed Integrity


• Hyb0: This hybrid experiment corresponds to the real updatable authenticated encryption relaxed in-

tegrity experiment Exptrelaxed-intΠUAE

(λ, h, d, γ,A) that is instantiated with Construction 4.5.2.

• Hyb1: In this hybrid experiment, we introduce an additional abort condition to the challenger’s simula-

tion. Namely, throughout the experiment, the challenger maintains an additional look-up table Theader

that keeps track of all of the “well-formed” ciphertext headers (under the honest keys) that A receives

from the challenger. Then, it answers each of A’s oracle queries as follows:


header

ct← AE.Encrypt(ki, (kprf , h)

),

and the ciphertext body ct = (ct1, . . . , ct`) according to the specification of Encrypt(ki,m).

After returning the ciphertext (ct, ct) to A, it adds the mapping Theader[i, ct] ←((kprf , h),m

)to

the table if i ≤ h.


– OReKeyGen(i, j, ct): If i > h, then the challenger proceeds exactly as in Hyb0. Otherwise, if

i ≤ h, then the challenger first checks if Theader[i, ct] = ⊥ and outputs ⊥ if this is the case. If

Theader[i, ct] 6= ⊥, then the challenger proceeds as in Hyb0 by computing ct← AE.Encrypt(kj , (k

′prf , h)

),

and returning ∆i,j,ct ← (ct′, kupprf) toA. Furthermore, if j ≤ h, then it sets (µ,m)← Theader[i, ct]

and adds the mapping Theader[j, ct′]←

((k′prf , h),m

)to the table.

– OReEncrypt

(i, j, (ct, ct)

): The challenger answers the query as follows:

* If i > h, then the challenger proceeds exactly as in Hyb0 by first computing m← Decrypt(ki, (ct, ct)

).

If m = ⊥, then the challenger returns⊥. Otherwise, it computes ct← AE.Encrypt(kj , (k

′prf , h)

),

sets ∆i,j,ct ← (ct′, kupprf), and returns (ct

′, ct′)← ReEncrypt


)toA. If j ≤ h,

then it additionally adds Theader[j, ct′]←

((k′prf , h),m

)to the table.

* If i ≤ h, then the challenger first checks if Theader[i, ct] = ⊥ and outputs ⊥ if this is the

case. If Theader[i, ct] 6= ⊥, then the challenger proceeds as in Hyb0 by computing ct ←AE.Encrypt

(kj , (k

′prf , h)

), and returning (ct

′, ct′) ← (ReEncrypt


)to A. If

j ≤ h, then it additionally adds Theader[j, ct′]←

((k′prf , h),m

)to the table.


in Hyb0, the challenger computes m ← Decrypt(ki, (ct, ct)

)and checks the following conditions,

outputting ⊥ if either is met:

– m = ⊥,

– For (ct′,m′)← T[i, ct], ct′ = (ct′1, . . . , ct′`), we have that m = m′, ` = `′, and

∥∥ctj − ct′j∥∥ ≤ γ

for all j ∈ [`].

In addition, the challenger verifies whether Theader[i, ct] = ⊥. If this is the case, then the challenger

also outputs ⊥. If none of the conditions above are met, then the challenger returns 1 as the output of

the experiment.




simulation for honest keys. Namely, the challenger answers A’s re-encryption key generation oracle

OReKeyGen and re-encryption oracle OReEncrypt as follows:

– OReKeyGen(i, j, ct): The challenger answers the oracle exactly as in Hyb1, but instead of decrypt-

ing the ciphertext header µ← AE.Decrypt(ki, ct), it looks up (µ,m)← T[i, ct]. If no such entry

exists in Theader, then it immediately aborts the experiments and outputs ⊥.

– OReEncrypt

(i, j, (ct, ct)


decrypting the ciphertext header µ ← AE.Decrypt(ki, ct), it looks up (µ,m) ← Theader[i, ct]. If

no such entry exists in Theader, then it immediately aborts the experiments and outputs ⊥.



in Hyb1, the challenger computes m ← Decrypt(ki, (ct, ct)

)and checks the following conditions,

outputting ⊥ if either is met:

– m = ⊥,

– For (ct′,m′)← T[i, ct], ct′ = (ct′1, . . . , ct′`), we have that m = m′, ` = `′, and

∥∥ctj − ct′j∥∥ ≤ γ

for all j ∈ [`].

However, when computing µ← Decrypt(ki, (ct, ct)

), instead of decrypting the header µ← AE.Decrypt(ki, ct),

it sets µ ← Theader[i, ct]. If no such entry exists in Theader, then it aborts the experiment and outputs

⊥. The rest of the output phase remains unchanged.


guishable assuming that ΠAE satisfies correctness.

Then in theorem 4.14.14, we show that an adversary’s advantage in forcing the challenger to output 1

in Hyb2 is negligible assuming that H is collision-resistant.




Lemma 4.14.12. Suppose that ΠAE satisfies εintae -integrity (theorem 4.2.9). Then, for all efficient adversaries


Proof. The proof is almost identical to the proof of theorem 4.14.1 aside from the different set of oracles that

are available to the adversary in the integrity game. The only distinction between Hyb1 that we consider for

integrity and Hyb1 that we consider for the confidentiality security proof in theorem 4.14.1 is the content of

Theader. In Hyb1 for integrity, the challenger additionally includes a plaintext message m that is encrypted by

the ciphertext body of each corresponding ciphertext headers. However, this distinction does not actually im-

pact the security proof as long as there always exists a well-defined plaintext message m for each ofA’s oracle

queries to OReEncrypt. This condition is guaranteed by the relaxed integrity security game (theorem 4.12.1)

and therefore, the lemma follows by the same argument as in the proof of theorem 4.14.1.



Proof. The proof is identical to the proof of theorem 4.14.2.

Lemma 4.14.14. Suppose that H is a εcr-secure collision resistant hash function. Then, for all efficient


Pr[Hyb2(A) = 1] ≤ εcr(λ).


Proof. Let A be an adversary that produces a ciphertext forgery in Hyb2. We construct an algorithm B that

uses A to produce a collision for the hash function H . Algorithm B works as follows:

• Algorithm B simply follows the specification of the challenger in Hyb2 until A produces a forgery.

Once A produces a forgery, which consists of an index i ∈ [h] and a ciphertext (ct, ct), B verifies if

Theader[i, ct] = ⊥. If this is the case, then it aborts and returns ⊥. Otherwise, it decrypts the message


)and also looks up (µ,m′)← Theader[i, ct]. It returns (m,m′) as the collision

for the hash function H .

We now show that if A successfully produces a valid forgery for Hyb2, then B’s output (m,m′) is a valid

collision for H: H(m) = H(m′) and m 6= m′. If A’s forgery, which consists of an index i ∈ [h] and a

ciphertext (ct, ct), is a valid forgery, then it must be the case that for m← Decrypt(ki, (ct, ct)

), we have

• m 6= ⊥,

• For (ct′,m′) ← T[i, ct], ct′ = (ct′1, . . . , ct′`), we have that m = m′, ` = `′, and

∥∥ctj − ct′j∥∥ ≤ γ for

all j ∈ [`].

Now, let((kprf , h),m

)← Theader[i, ct]. We first note that by the specification of the challenger in Hyb2,

we have h = H(m′). Furthermore, by the specification of the Decrypt algorithm, in order for m =

Decrypt(ki, (ct, ct)

)6= ⊥, we must have m = H(m). Finally, since T[i, ct] 6= ct, the forged ciphertext

(ct, ct) was never output by the challenger during the simulation of the experiment. Since ct is uniquely de-

termined by the underlying plaintext m for a fixed PRF key kprf , we have m 6= m′. The lemma follows.

By combining the lemmas above and using the triangle inequality, the proof of relaxed integrity follows.


4.15.1 Security

LetA be an adversary that distinguishes the PRFF (s, x) from a truly random function f ←R Funs[0, 1`,Rq].We construct an algorithm B that uses A to break the Ring Learning with Errors problem RLWEn,q,χ. Algo-

rithm B proceeds as follows:

• Setup phase: At the start of the experiment, algorithm B initiates a look-up tables T0 and T1:

– T0 is indexed by PRF inputs x ∈ 0, 1` and stores elements (a, v) ∈ Rq ×Rq .

– T1 is indexed by elements (s, x) and stores elements r ∈ 0, 1`.

• Query phase: Algorithm B answers each of A’s oracle queries as follows:

– RO queries to H0: For each query x ∈ 0, 1` to H0, algorithm B checks if T1[x] = ⊥. If

this is the case, then it queries the RLWEn,q,χ oracle to receive a sample (a, v) ∈ Rq ×Rq , sets


T1[x] ← (a, v), and returns a to A. If T1[x] 6= ⊥, then it looks up (a, v) ← T[x], and returns a

to A.

– RO Queries to H1: For each query (s′, x) ∈ Rq × 0, 1`, algorithm B checks if T2[s′, x] = ⊥.

If this is the case, then it samples a random element r ←R 0, 1`, sets T [s′, x] ← r, and returns

r. If T2[s′, x] 6= ⊥, then it sets r ← T2[s′, x], and returns r.

– Evaluation queries: On an evaluation query x ∈ 0, 1`, algorithm B checks if T[x] = ⊥. If

this is the case, then it queries the RLWEn,q,χ oracle to receive a sample (a, v) ∈ Rq ×Rq , sets

T[x] ← (a, v), and returns v to A. If T[x] 6= ⊥, then it looks up (a, v) ← T[x], and returns v

to A.

• Output phase: At the end of the experiment, adversary A outputs a bit b ∈ 0, 1. Now, algorithm Bproceeds as follows.

– For each (s′, x) ∈ Rq × 0, 1` for which T2[s′, x] 6= ⊥, it checks if ‖v − a · s′‖ ≤ 2B for each

(a, v) ∈ T1. If there exists such entry (s′, x) ∈ Rq × 0, 1`, algorithm B outputs 0.

– If no such entry (s′, x) ∈ Rq × 0, 1` exists, then algorithm B outputs b that A returned.

Suppose that B is interacting with the real RLWE oracle OReals , which provides (a, a · s+ e) for a←R Rq and

e← χ to B. Then, by definition, algorithm B perfectly simulates the responses to all ofA’s oracle queries as

long as A never submits (s, x) as a query to H1 for some x ∈ 0, 1`. However, if A submits such a query

to H1, then algorithm B uses s to verify whether it is interacting with the real oracle OReals or OIdeal at the

output phase of the simulation.

Now, suppose that B is interacting with the ideal RLWE oracleOIdeal, which provides (a, u)←R Rq×Rq .Then, by definition, algorithmB perfectly simulates the responses toA’s queries. At the end of the simulation,

algorithm B returns the output of A as long as A never made a query (s′, x) to H1 for which s′ is a valid

RLWEn,q,χ secret. However, when B is interacting with OIdeal, no such s′ can exist. Therefore, algorithm Bdistinguishes oraclesOReal

s andOIdeal with at least the distinguishing advantage ofA in distinguishing F (s, ·)and f(·).

4.15.2 Key-Homomorphism

Key-homomorphism of the PRF follows straightforwardly from the following relation:

F (s1, x) + F (s2, x)− F (s1 + s2, x) = a · s1 + e1 + a · s2 + e2 − a · (s1 + s2) + e3

= e1 + e2 − e3,

where e1 = Samp(H1(s1, x)

), e2 = Samp

(H1(s2, x)

), and e3 = Samp

(H1(s1 + s2, x)

). By definition

of Samp, the norm of ring elements e1, e2, and e3 are bounded by B. Therefore, ‖e1 + e2 − e3‖ ≤ ‖e1‖ +

‖e2‖+ ‖e3‖ ≤ 3B. The statement of the theorem now follows.

Chapter 5

Conclusion

This thesis has aimed to make some small contribution to the project of protecting private data in the “wild

west” of cybersecurity in which we still find ourselves today. To this end, we began by discussing how to

protect secrets that users type into their local devices from malware. Next, we focused on the problem of

metadata-hiding messaging and showed how to make metadata-hiding systems practical for whistleblowing

applications. Finally, we introduced new cryptographic techniques for updatable encryption, which enables

rotation of encryption keys for data that’s encrypted and then stored by a third party cloud provider.

Each solution presented in the thesis used a different set of tools – hardware enclaves, distributed point

functions, zero-knowledge proofs on secret shared data, lattice cryptography, etc – but in all cases we were

able to gain order of magnitude performance improvements over prior work or to demonstrate a new func-

tionality that was not previously possible. It is our hope that the tools developed in this thesis, or future tools

that build upon them, will help lead us into a world where individuals have more control over their data and

where privacy is seen as a fundamental aspect of computing systems, not a bonus feature.

147

Bibliography

[1] Intel software guard extensions sdk for linux os, developer reference.

[2] Source code repository. https://github.com/moshih/UpdateableEncryption_Code.

[3] Tweetnacl.js. https://github.com/dchest/tweetnacl-js.

[4] Ittai Abraham, Benny Pinkas, and Avishay Yanai. Blinder: Mpc based scalable and robust anonymous

committed broadcast. Cryptology ePrint Archive, Report 2020/248, 2020.

[5] Navid Alamati, Hart Montgomery, and Sikhar Patranabis. Symmetric primitives with structured se-

crets. In CRYPTO, pages 650–679, 2019.

[6] Martin R Albrecht, Rachel Player, and Sam Scott. On the concrete hardness of learning with errors.

Journal of Mathematical Cryptology, 9(3):169–203, 2015.

[7] Erdem Alkim, Leo Ducas, Thomas Poppelmann, and Peter Schwabe. Post-quantum key exchange - A

new hope. In USENIX Security, 2016.

[8] Sebastian Angel, Hao Chen, Kim Laine, and Srinath T. V. Setty. PIR with compressed queries and

amortized query processing. In IEEE Symposium on Security and Privacy, SP, 2018.

[9] Sebastian Angel and Srinath T. V. Setty. Unobservable communication over fully untrusted infrastruc-

ture. In OSDI, 2016.

[10] Anonymous. I am part of the resistance inside the trump administration. https://www.nytimes.

com/2018/09/05/opinion/trump-white-house-anonymous-resistance.html,

2018.

[11] Anonymous. Whistleblower complaint to us intelligence community inspector general. https:

//www.documentcloud.org/documents/6430351-Whistleblower-Complaint.

html, 2019.

[12] AP. Gov’t obtains wide ap phone records in probe. Associated Press, 2013.

[13] AP. Times says justice seized reporter’s email, phone records. Associated Press, 2018.

148

https://github.com/moshih/UpdateableEncryption_Code

https://github.com/dchest/tweetnacl-js

https://www.nytimes.com/2018/09/05/opinion/trump-white-house-anonymous-resistance.html

https://www.nytimes.com/2018/09/05/opinion/trump-white-house-anonymous-resistance.html

https://www.documentcloud.org/documents/6430351-Whistleblower-Complaint.html



BIBLIOGRAPHY 149

[14] Benny Applebaum, David Cash, Chris Peikert, and Amit Sahai. Fast cryptographic primitives and

circular-secure encryption based on hard learning problems. In CRYPTO, 2009.

[15] Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, Andre Martin, Christian Priebe,

Joshua Lind, Divya Muthukumaran, Dan O’Keeffe, Mark Stillwell, David Goltzsche, David M. Eyers,

Rudiger Kapitza, Peter R. Pietzuch, and Christof Fetzer. SCONE: secure linux containers with intel

SGX. In 12th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2016,

Savannah, GA, USA, November 2-4, 2016., pages 689–703, 2016.

[16] Michael Backes, Aniket Kate, Praveen Manoharan, Sebastian Meiser, and Esfandiar Mohammadi.

Anoa: A framework for analyzing anonymous communication protocols. J. Priv. Confidentiality,

2016.

[17] Abhishek Banerjee and Chris Peikert. New and improved key-homomorphic pseudorandom functions.

In CRYPTO, 2014.

[18] Abhishek Banerjee, Chris Peikert, and Alon Rosen. Pseudorandom functions and lattices. In EURO-

CRYPT, 2012.

[19] Elaine Barker. Nist special publication 800-57 part 1 revision 4: Recommendation for key manage-

ment, 2016.

[20] Andrew Baumann, Marcus Peinado, and Galen C. Hunt. Shielding applications from an untrusted

cloud with haven. In 11th USENIX Symposium on Operating Systems Design and Implementation,

OSDI ’14, Broomfield, CO, USA, October 6-8, 2014., pages 267–283, 2014.

[21] Mihir Bellare and Chanathip Namprempre. Authenticated encryption: Relations among notions and

analysis of the generic composition paradigm. In ASIACRYPT, 2000.

[22] Mihir Bellare and Phillip Rogaway. Random oracles are practical: A paradigm for designing efficient

protocols. In CCS, 1993.

[23] Daniel J. Bernstein. Curve25519: New diffie-hellman speed records. In PKC, 2006.

[24] Charles Berret. Guide to securedrop. https://www.cjr.org/tow_center_reports/

guide_to_securedrop.php, 2016.

[25] Andrea Bittau, Ulfar Erlingsson, Petros Maniatis, Ilya Mironov, Ananth Raghunathan, David Lie,

Mitch Rudominer, Ushasree Kode, Julien Tinnes, and Bernhard Seefeld. Prochlo: Strong privacy

for analytics in the crowd. In Proceedings of the 26th Symposium on Operating Systems Principles,

Shanghai, China, October 28-31, 2017, pages 441–459, 2017.

[26] Dan Boneh, Elette Boyle, Henry Corrigan-Gibbs, Niv Gilboa, and Yuval Ishai. Zero-knowledge proofs

on secret-shared data via fully linear pcps. In CRYPTO, 2019.

https://www.cjr.org/tow_center_reports/guide_to_securedrop.php

https://www.cjr.org/tow_center_reports/guide_to_securedrop.php

BIBLIOGRAPHY 150

[27] Dan Boneh, Saba Eskandarian, Sam Kim, and Maurice Shih. Improving speed and security in updat-

able encryption schemes. In Advances in Cryptology - ASIACRYPT 2020 - 26th International Confer-

ence on the Theory and Application of Cryptology and Information Security, Daejeon, South Korea,

December 7-11, 2020, Proceedings, Part III, pages 559–589, 2020.

[28] Dan Boneh, Kevin Lewi, Hart William Montgomery, and Ananth Raghunathan. Key homomorphic

prfs and their applications. In CRYPTO, 2013.

[29] Dan Boneh and Victor Shoup. A Graduate Course in Applied Cryptography (version 0.5, Chapter 9).

2017. https://cryptobook.us.

[30] Kevin Borders and Atul Prakash. Securing network input via a trusted input proxy. In 2nd USENIX

Workshop on Hot Topics in Security, HotSec’07, Boston, MA, USA, August 7, 2007. USENIX Associ-

ation, 2007.

[31] Nikita Borisov, George Danezis, and Ian Goldberg. DP5: A private presence service. PoPETs,

2015(2):4–24, 2015.

[32] Colin Boyd, Gareth T. Davies, Kristian Gjøsteen, and Yao Jiang. Fast and secure updatable encryption.

In CRYPTO, 2020.

[33] Elette Boyle, Niv Gilboa, and Yuval Ishai. Function secret sharing. In EUROCRYPT, 2015.

[34] Elette Boyle, Niv Gilboa, and Yuval Ishai. Function secret sharing: Improvements and extensions. In

ACM CCS, 2016.

[35] Zvika Brakerski, Adeline Langlois, Chris Peikert, Oded Regev, and Damien Stehle. Classical hardness

of learning with errors. In STOC, 2013.

[36] Zvika Brakerski and Vinod Vaikuntanathan. Constrained key-homomorphic prfs from standard lattice

assumptions. In TCC, 2015.

[37] Anthony Brandon and Michael Trimarchi. Trusted display and input using screen overlays. In Inter-

national Conference on ReConFigurable Computing and FPGAs, ReConFig 2017, Cancun, Mexico,

December 4-6, 2017, pages 1–6, 2017.

[38] Ferdinand Brasser, Urs Muller, Alexandra Dmitrienko, Kari Kostiainen, Srdjan Capkun, and Ahmad-

Reza Sadeghi. Software grand exposure: SGX cache attacks are practical. In 11th USENIX Workshop

on Offensive Technologies, WOOT 2017, Vancouver, BC, Canada, August 14-15, 2017., 2017.

[39] Stefan Brenner, Colin Wulf, David Goltzsche, Nico Weichbrodt, Matthias Lorenz, Christof Fetzer,

Peter R. Pietzuch, and Rudiger Kapitza. Securekeeper: Confidential zookeeper using intel SGX. In

Proceedings of the 17th International Middleware Conference, Trento, Italy, December 12 - 16, 2016,

page 14, 2016.

https://cryptobook.us

BIBLIOGRAPHY 151

[40] Ran Canetti, Hugo Krawczyk, and Jesper Buus Nielsen. Relaxing chosen-ciphertext security. In

CRYPTO, 2003.

[41] David Chaum. Untraceable electronic mail, return addresses, and digital pseudonyms. Commun. ACM,

24(2):84–88, 1981.

[42] David Chaum. The dining cryptographers problem: Unconditional sender and recipient untraceability.

J. Cryptology, 1(1):65–75, 1988.

[43] Guoxing Chen, Sanchuan Chen, Yuan Xiao, Yinqian Zhang, Zhiqiang Lin, and Ten H. Lai. Sgxpectre

attacks: Leaking enclave secrets via speculative execution. CoRR, abs/1802.09085, 2018.

[44] Weikeng Chen. libdpf. https://github.com/weikengchen/libdpf, 2018.

[45] Raymond Cheng, Will Scott, Bryan Parno, Irene Zhang, Arvind Krishnamurthy, and Thomas Ander-

son. Talek: a Private Publish-Subscribe Protocol. Technical Report UW-CSE-16-11-01, University of

Washington Computer Science and Engineering, Seattle, Washington, Nov 2016.

[46] Benny Chor, Eyal Kushilevitz, Oded Goldreich, and Madhu Sudan. Private information retrieval. J.

ACM, 45(6):965–981, 1998.

[47] David Cole. We kill people based on metadata. New York Review of Books, 2014.

[48] David A. Cooper and Kenneth P. Birman. Preserving privacy in a network of mobile computers. In

IEEE Symposium on Security and Privacy, SP, 1995.

[49] Henry Corrigan-Gibbs and Dan Boneh. Prio: Private, robust, and scalable computation of aggregate

statistics. In NSDI, 2017.

[50] Henry Corrigan-Gibbs, Dan Boneh, and David Mazieres. Riposte: An anonymous messaging system

handling millions of users. In IEEE Symposium on Security and Privacy, SP, 2015.

[51] Henry Corrigan-Gibbs and Bryan Ford. Dissent: accountable anonymous group messaging. In ACM

CCS, 2010.

[52] Henry Corrigan-Gibbs and Bryan Ford. Conscript your friends into larger anonymity sets with

javascript. In Proceedings of the 12th annual ACM Workshop on Privacy in the Electronic Society,

WPES 2013, Berlin, Germany, November 4, 2013, pages 243–248, 2013.

[53] Henry Corrigan-Gibbs, David Isaac Wolinsky, and Bryan Ford. Proactively accountable anonymous

messaging in verdict. In USENIX Security, 2013.

[54] Victor Costan and Srinivas Devadas. Intel SGX explained. IACR Cryptology ePrint Archive, 2016:86,

2016.

https://github.com/weikengchen/libdpf

BIBLIOGRAPHY 152

[55] Victor Costan, Ilia A. Lebedev, and Srinivas Devadas. Sanctum: Minimal hardware extensions for

strong software isolation. In 25th USENIX Security Symposium, USENIX Security 16, Austin, TX,

USA, August 10-12, 2016., pages 857–874, 2016.

[56] Richard S. Cox, Steven D. Gribble, Henry M. Levy, and Jacob Gorm Hansen. A safety-oriented

platform for web applications. In 2006 IEEE Symposium on Security and Privacy (S&P 2006), 21-24

May 2006, Berkeley, California, USA, pages 350–364. IEEE Computer Society, 2006.

[57] Cora Currier. Planned nsa reforms still leave journalists reason to worry. Columbia Journalism Review,

2014.

[58] Janis Danisevskis. Android protected confirmation: Taking transaction security to the

next level, 2018. https://android-developers.googleblog.com/2018/10/

android-protected-confirmation.html.

[59] Debajyoti Das, Sebastian Meiser, Esfandiar Mohammadi, and Aniket Kate. Anonymity trilemma:

Strong anonymity, low bandwidth overhead, low latency - choose two. In IEEE Symposium on Security

and Privacy, SP, 2018.

[60] Aritra Dhar, Ivan Puddu, Kari Kostiainen, and Srdjan Capkun. Proximitee: Hardened sgx attestation

and trusted path through proximity verification. Cryptology ePrint Archive, Report 2018/902, 2018.

https://eprint.iacr.org/2018/902.

[61] Roger Dingledine. One cell is enough to break tor’s anonymity, 2009.

[62] Roger Dingledine, Nick Mathewson, and Paul F. Syverson. Tor: The second-generation onion router.

In USENIX Security Symposium, 2004.

[63] Cynthia Dwork. Differential privacy. In ICALP, 2006.

[64] Saba Eskandarian, Jonathan Cogan, Sawyer Birnbaum, Peh Chang Wei Brandon, Dillon Franke, Forest

Fraser, Gaspar Garcia Jr., Eric Gong, Hung T. Nguyen, Taresh K. Sethi, Vishal Subbiah, Michael

Backes, Giancarlo Pellegrino, and Dan Boneh. Fidelius: Protecting user secrets from compromised

browsers. In 2019 IEEE Symposium on Security and Privacy, SP 2019, San Francisco, CA, USA, May

19-23, 2019, pages 264–280, 2019.

[65] Saba Eskandarian, Henry Corrigan-Gibbs, Matei Zaharia, and Dan Boneh. Express: Lowering the cost

of metadata-hiding communication with cryptographic privacy. In 30th USENIX Security Symposium

(USENIX Security 21), Vancouver, B.C., 2021. USENIX Association.

[66] Adam Everspaugh, Kenneth G. Paterson, Thomas Ristenpart, and Samuel Scott. Key rotation for

authenticated encryption. In CRYPTO, 2017.

https://android-developers.googleblog.com/2018/10/android-protected-confirmation.html

https://android-developers.googleblog.com/2018/10/android-protected-confirmation.html

https://eprint.iacr.org/2018/902

BIBLIOGRAPHY 153

[67] Norman Feske and Christian Helmuth. A nitpicker’s guide to a minimal-complexity secure GUI. In

21st Annual Computer Security Applications Conference (ACSAC 2005), 5-9 December 2005, Tucson,

AZ, USA, pages 85–94. IEEE Computer Society, 2005.

[68] Amos Fiat and Adi Shamir. How to prove yourself: Practical solutions to identification and signature

problems. In CRYPTO, 1986.

[69] Ben A. Fisch, Dhinakaran Vinayagamurthy, Dan Boneh, and Sergey Gorbunov. Iron: Functional

encryption using intel sgx. IACR Cryptology ePrint Archive, 2016.

[70] Tommaso Frassetto, David Gens, Christopher Liebchen, and Ahmad-Reza Sadeghi. Jitguard: Hard-

ening just-in-time compilers with SGX. In Bhavani M. Thuraisingham, David Evans, Tal Malkin, and

Dongyan Xu, editors, Proceedings of the 2017 ACM SIGSAC Conference on Computer and Commu-

nications Security, CCS 2017, Dallas, TX, USA, October 30 - November 03, 2017, pages 2405–2419.

ACM, 2017.

[71] Michael Freyberger, Warren He, Devdatta Akhawe, Michelle L. Mazurek, and Prateek Mittal. Crack-

ing shadowcrypt: Exploring the limitations of secure I/O systems in internet browsers. PoPETs,

2018(2):47–63, 2018.

[72] Robert Gallager. Low-density parity-check codes. IRE Transactions on information theory, 8(1):21–

28, 1962.

[73] Tal Garfinkel, Ben Pfaff, Jim Chow, Mendel Rosenblum, and Dan Boneh. Terra: a virtual machine-

based platform for trusted computing. In Michael L. Scott and Larry L. Peterson, editors, Proceedings

of the 19th ACM Symposium on Operating Systems Principles 2003, SOSP 2003, Bolton Landing, NY,

USA, October 19-22, 2003, pages 193–206. ACM, 2003.

[74] Niv Gilboa and Yuval Ishai. Distributed point functions and their applications. In EUROCRYPT, 2014.

[75] Sharad Goel, Mark Robson, Milo Polte, and Emin Gun Sirer. Herbivore: A scalable and efficient

protocol for anonymous communication. Technical report, Cornell University, 2003.

[76] Oded Goldreich, Shafi Goldwasser, and Silvio Micali. On the cryptographic applications of random

functions. In CRYPTO, 1984.

[77] David Goltzsche, Colin Wulf, Divya Muthukumaran, Konrad Rieck, Peter R. Pietzuch, and Rudiger

Kapitza. Trustjs: Trusted client-side execution of javascript. In Cristiano Giuffrida and Angelos

Stavrou, editors, Proceedings of the 10th European Workshop on Systems Security, EUROSEC 2017,

Belgrade, Serbia, April 23, 2017, pages 7:1–7:6. ACM, 2017.

[78] Google. Key rotation. https://cloud.google.com/kms/docs/key-rotation.

BIBLIOGRAPHY 154

[79] Johannes Gotzfried, Moritz Eckert, Sebastian Schinzel, and Tilo Muller. Cache attacks on intel SGX.

In Proceedings of the 10th European Workshop on Systems Security, EUROSEC 2017, Belgrade, Ser-

bia, April 23, 2017, pages 2:1–2:6, 2017.

[80] Glenn Greenwald. Nsa collecting phone records of millions of verizon customers daily. The Guardian,

2013.

[81] Warren He, Devdatta Akhawe, Sumeet Jain, Elaine Shi, and Dawn Xiaodong Song. Shadowcrypt:

Encrypted web applications for everyone. In Proceedings of the 2014 ACM SIGSAC Conference on

Computer and Communications Security, Scottsdale, AZ, USA, November 3-7, 2014, pages 1028–

1039, 2014.

[82] Matthew Hoekstra, Reshma Lal, Pradeep Pappachan, Vinay Phegade, and Juan del Cuvillo. Using

innovative instructions to create trustworthy software solutions. In HASP 2013, The Second Workshop

on Hardware and Architectural Support for Security and Privacy, Tel-Aviv, Israel, June 23-24, 2013,

page 11, 2013.

[83] Susan Hohenberger, Allison B. Lewko, and Brent Waters. Detecting dangerous queries: A new ap-

proach for chosen ciphertext security. In EUROCRYPT, 2012.

[84] Amir Houmansadr and Nikita Borisov. The need for flow fingerprints to link correlated network flows.

In PETS, 2013.

[85] Tyler Hunt, Zhiting Zhu, Yuanzhong Xu, Simon Peter, and Emmett Witchel. Ryoan: A distributed

sandbox for untrusted computation on secret data. In 12th USENIX Symposium on Operating Systems

Design and Implementation, OSDI 2016, Savannah, GA, USA, November 2-4, 2016., pages 533–549,

2016.

[86] Collin Jackson, Daniel R. Simon, Desney S. Tan, and Adam Barth. An evaluation of extended valida-

tion and picture-in-picture phishing attacks. In Sven Dietrich and Rachna Dhamija, editors, Financial

Cryptography and Data Security, 11th International Conference, FC 2007, and 1st International Work-

shop on Usable Security, USEC 2007, Scarborough, Trinidad and Tobago, February 12-16, 2007. Re-

vised Selected Papers, volume 4886 of Lecture Notes in Computer Science, pages 281–293. Springer,

2007.

[87] Yeongjin Jang. Building trust in the user I/O in computer systems. PhD thesis, Georgia Tech, 2017.

[88] Aaron Johnson, Chris Wacek, Rob Jansen, Micah Sherr, and Paul F. Syverson. Users get routed: traffic

correlation on tor by realistic adversaries. In ACM CCS, 2013.

[89] Dave Jones. Picamera. https://github.com/waveform80/picamera, 2017.

[90] Sam Kim. Key-homomorphic pseudorandom functions from lwe with small modulus. In EURO-

CRYPT, 2020.

https://github.com/waveform80/picamera

BIBLIOGRAPHY 155

[91] Lea Kissner, Alina Oprea, Michael K. Reiter, Dawn Xiaodong Song, and Ke Yang. Private keyword-

based push and pull with applications to anonymous communication. In ACNS, 2004.

[92] Lea Kissner, Alina Oprea, Michael K. Reiter, Dawn Xiaodong Song, and Ke Yang. Private keyword-

based push and pull with applications to anonymous communication. In ACNS, 2004.

[93] Michael Klooß, Anja Lehmann, and Andy Rupp. (R)CCA secure updatable encryption with integrity

protection. In EUROCRYPT, 2019.

[94] Christiane Kuhn, Martin Beck, Stefan Schiffner, Eduard A. Jorswieck, and Thorsten Strufe. On privacy

notions in anonymous communication. PoPETs, 2019.

[95] Christiane Kuhn, Martin Beck, and Thorsten Strufe. Breaking and (partially) fixing provably secure

onion routing. In IEEE Symposium on Security and Privacy, SP, 2020.

[96] Albert Kwon, Henry Corrigan-Gibbs, Srinivas Devadas, and Bryan Ford. Atom: Horizontally scaling

strong anonymity. In SOSP, 2017.

[97] Albert Kwon, David Lazar, Srinivas Devadas, and Bryan Ford. Riffle: An efficient communication

system with strong anonymity. PoPETs, 2016(2):115–134, 2016.

[98] Albert Kwon, David Lu, and Srinivas Devadas. XRD: scalable messaging system with cryptographic

privacy. CoRR, abs/1901.04368, 2019.

[99] Reshma Lal and Pradeep M. Pappachan. An architecture methodology for secure video conferencing.

In Technologies for Homeland Security (HST). IEEE, 2013.

[100] Adeline Langlois and Damien Stehle. Worst-case to average-case reductions for module lattices. De-

signs, Codes and Cryptography, 75(3):565–599, 2015.

[101] David Lazar, Yossi Gilad, and Nickolai Zeldovich. Karaoke: Distributed private messaging immune

to passive traffic analysis. In OSDI, 2018.

[102] David Lazar and Nickolai Zeldovich. Alpenhorn: Bootstrapping secure communication without leak-

ing metadata. In OSDI, 2016.

[103] Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim, Hyesoon Kim, and Marcus Peinado. Inferring

fine-grained control flow inside SGX enclaves with branch shadowing. In 26th USENIX Security

Symposium, USENIX Security 2017, Vancouver, BC, Canada, August 16-18, 2017., pages 557–574,

2017.

[104] Anja Lehmann and Bjorn Tackmann. Updatable encryption with post-compromise security. In EU-

ROCRYPT, 2018.

BIBLIOGRAPHY 156

[105] Chang Liu, Austin Harris, Martin Maas, Michael W. Hicks, Mohit Tiwari, and Elaine Shi. Ghostrider:

A hardware-software system for memory trace oblivious computation. In Ozcan Ozturk, Kemal

Ebcioglu, and Sandhya Dwarkadas, editors, Proceedings of the Twentieth International Conference

on Architectural Support for Programming Languages and Operating Systems, ASPLOS ’15, Istanbul,

Turkey, March 14-18, 2015, pages 87–101. ACM, 2015.

[106] Dan Luu. Computer latency: 1977-2017, 2017. https://danluu.com/input-lag/.

[107] Vadim Lyubashevsky, Chris Peikert, and Oded Regev. On ideal lattices and learning with errors over

rings. In EUROCRYPT, 2010.

[108] Vadim Lyubashevsky, Chris Peikert, and Oded Regev. A toolkit for ring-lwe cryptography. In EURO-

CRYPT, 2013.

[109] Martin Maas, Eric Love, Emil Stefanov, Mohit Tiwari, Elaine Shi, Krste Asanovic, John Kubiatowicz,

and Dawn Song. PHANTOM: practical oblivious computation in a secure processor. In Ahmad-Reza

Sadeghi, Virgil D. Gligor, and Moti Yung, editors, 2013 ACM SIGSAC Conference on Computer and

Communications Security, CCS’13, Berlin, Germany, November 4-8, 2013, pages 311–324. ACM,

2013.

[110] Lorenzo Martignoni, Pongsin Poosankam, Matei Zaharia, Jun Han, Stephen McCamant, Dawn Song,

Vern Paxson, Adrian Perrig, Scott Shenker, and Ion Stoica. Cloud terminal: Secure access to sensitive

applications from untrusted systems. In 2012 USENIX Annual Technical Conference, Boston, MA,

USA, June 13-15, 2012, pages 165–182, 2012.

[111] Sinisa Matetic, Mansoor Ahmed, Kari Kostiainen, Aritra Dhar, David Sommer, Arthur Gervais, Ari

Juels, and Srdjan Capkun. ROTE: rollback protection for trusted execution. In 26th USENIX Security

Symposium, USENIX Security 2017, Vancouver, BC, Canada, August 16-18, 2017., pages 1289–1306,

2017.

[112] Jonathan M. McCune, Yanlin Li, Ning Qu, Zongwei Zhou, Anupam Datta, Virgil D. Gligor, and Adrian

Perrig. Trustvisor: Efficient TCB reduction and attestation. In 31st IEEE Symposium on Security

and Privacy, S&P 2010, 16-19 May 2010, Berleley/Oakland, California, USA, pages 143–158. IEEE

Computer Society, 2010.

[113] Jonathan M. McCune, Bryan Parno, Adrian Perrig, Michael K. Reiter, and Hiroshi Isozaki. Flicker:

an execution infrastructure for tcb minimization. In Joseph S. Sventek and Steven Hand, editors,

Proceedings of the 2008 EuroSys Conference, Glasgow, Scotland, UK, April 1-4, 2008, pages 315–

328. ACM, 2008.

[114] Jonathan M. McCune, Adrian Perrig, and Michael K. Reiter. Bump in the ether: A framework for

securing sensitive user input. In Atul Adya and Erich M. Nahum, editors, Proceedings of the 2006

https://danluu.com/input-lag/

BIBLIOGRAPHY 157

USENIX Annual Technical Conference, Boston, MA, USA, May 30 - June 3, 2006, pages 185–198.

USENIX, 2006.

[115] Jonathan M. McCune, Adrian Perrig, and Michael K. Reiter. Safe passage for passwords and other

sensitive data. In Proceedings of the Network and Distributed System Security Symposium, NDSS

2009, San Diego, California, USA, 8th February - 11th February 2009. The Internet Society, 2009.

[116] Carlos Aguilar Melchor, Joris Barrier, Laurent Fousse, and Marc-Olivier Killijian. XPIR : Private

information retrieval for everyone. PoPETs, 2016(2):155–174, 2016.

[117] Micha Mettke. Nuklear. https://github.com/vurtun/nuklear, 2018.

[118] Daniele Micciancio and Petros Mol. Pseudorandom knapsacks and the sample complexity of LWE

search-to-decision reductions. In CRYPTO, 2011.

[119] Daniele Micciancio and Chris Peikert. Trapdoors for lattices: Simpler, tighter, faster, smaller. In

EUROCRYPT, 2012.

[120] Pratyush Mishra, Rishabh Poddar, Jerry Chen, Alessandro Chiesa, and Raluca Ada Popa. Oblix: An

efficient oblivious search index. In 2018 IEEE Symposium on Security and Privacy, SP (Oakland),

2018.

[121] mitar, wh0, and C. Van Wiemeersch. Secureworker. https://github.com/luckychain/

node-secureworker, 2018.

[122] Moni Naor, Benny Pinkas, and Omer Reingold. Distributed pseudo-random functions and kdcs. In

EUROCRYPT, 1999.

[123] Rafail Ostrovsky and Victor Shoup. Private information storage (extended abstract). In STOC, 1997.

[124] Antonis Papadimitriou, Ranjita Bhagwan, Nishanth Chandran, Ramachandran Ramjee, Andreas Hae-

berlen, Harmeet Singh, Abhishek Modi, and Saikrishna Badrinarayanan. Big data analytics over en-

crypted datasets with seabed. In 12th USENIX Symposium on Operating Systems Design and Imple-

mentation, OSDI 2016, Savannah, GA, USA, November 2-4, 2016., pages 587–602, 2016.

[125] PCI Security Standards Council. Payment card industry data security standard, 2018.

[126] Chris Peikert. Public-key cryptosystems from the worst-case shortest vector problem. In STOC, 2009.

[127] Ania M. Piotrowska, Jamie Hayes, Tariq Elahi, Sebastian Meiser, and George Danezis. The loopix

anonymity system. In USENIX Security, 2017.

[128] Julie Posetti. Protecting Journalism Sources in the Digital Age. UNESCO, 2017.

[129] Christian Priebe, Kapil Vaswani, and Manuel Costa. Enclavedb: A secure database using sgx. In 2018

IEEE Symposium on Security and Privacy, SP (Oakland), 2018.

https://github.com/vurtun/nuklear

https://github.com/luckychain/node-secureworker

https://github.com/luckychain/node-secureworker

BIBLIOGRAPHY 158

[130] Ashay Rane, Calvin Lin, and Mohit Tiwari. Raccoon: Closing digital side-channels through obfuscated

execution. In 24th USENIX Security Symposium, USENIX Security 15, Washington, D.C., USA, August

12-14, 2015., pages 431–446, 2015.

[131] Oded Regev. On lattices, learning with errors, random linear codes, and cryptography. In STOC, 2005.

[132] Mark Russinovich. Introducing Azure confidential computing, 2017. https://azure.

microsoft.com/en-us/blog/introducing-azure-confidential-computing/.

[133] Len Sassaman, Bram Cohen, and Nick Mathewson. The pynchon gate: a secure method of pseudony-

mous mail retrieval. In Proceedings of the 2005 ACM Workshop on Privacy in the Electronic Society,

WPES 2005, Alexandria, VA, USA, November 7, 2005, pages 1–9, 2005.

[134] Sajin Sasy, Sergey Gorbunov, and Christopher W. Fletcher. Zerotrace : Oblivious memory primitives

from intel SGX. IACR Cryptology ePrint Archive, 2017:549, 2017.

[135] Stuart E. Schechter, Rachna Dhamija, Andy Ozment, and Ian Fischer. The emperor’s new security

indicators. In 2007 IEEE Symposium on Security and Privacy (S&P 2007), 20-23 May 2007, Oakland,

California, USA, pages 51–65, 2007.

[136] Michael Schwarz, Samuel Weiser, Daniel Gruss, Clementine Maurice, and Stefan Mangard. Malware

guard extension: Using SGX to conceal cache attacks. In Detection of Intrusions and Malware, and

Vulnerability Assessment - 14th International Conference, DIMVA 2017, Bonn, Germany, July 6-7,

2017, Proceedings, pages 3–24, 2017.

[137] Gregor Seiler. Faster AVX2 optimized NTT multiplication for ring-lwe lattice cryptography. IACR

Cryptology ePrint Archive, 2018:39, 2018.

[138] Jaebaek Seo, Byoungyoung Lee, Seong Min Kim, Ming-Wei Shih, Insik Shin, Dongsu Han, and Tae-

soo Kim. Sgx-shield: Enabling address space layout randomization for SGX programs. In 24th An-

nual Network and Distributed System Security Symposium, NDSS 2017, San Diego, California, USA,

February 26 - March 1, 2017, 2017.

[139] Ming-Wei Shih, Sangho Lee, Taesoo Kim, and Marcus Peinado. T-SGX: eradicating controlled-

channel attacks against enclave programs. In 24th Annual Network and Distributed System Security

Symposium, NDSS 2017, San Diego, California, USA, February 26 - March 1, 2017, 2017.

[140] Shweta Shinde, Zheng Leong Chua, Viswesh Narayanan, and Prateek Saxena. Preventing page faults

from telling your secrets. In Proceedings of the 11th ACM on Asia Conference on Computer and

Communications Security, AsiaCCS 2016, Xi’an, China, May 30 - June 3, 2016, pages 317–328, 2016.

[141] Shweta Shinde, Dat Le Tien, Shruti Tople, and Prateek Saxena. Panoply: Low-tcb linux applications

with SGX enclaves. In 24th Annual Network and Distributed System Security Symposium, NDSS 2017,

San Diego, California, USA, February 26 - March 1, 2017, 2017.

https://azure.microsoft.com/en-us/blog/introducing-azure-confidential-computing/

https://azure.microsoft.com/en-us/blog/introducing-azure-confidential-computing/

BIBLIOGRAPHY 159

[142] Rohit Sinha, Sriram K. Rajamani, Sanjit A. Seshia, and Kapil Vaswani. Moat: Verifying confiden-

tiality of enclave programs. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and

Communications Security, Denver, CO, USA, October 12-16, 2015, pages 1169–1184, 2015.

[143] Dawn Xiaodong Song, David A. Wagner, and Xuqing Tian. Timing analysis of keystrokes and timing

attacks on SSH. In Dan S. Wallach, editor, 10th USENIX Security Symposium, August 13-17, 2001,

Washington, D.C., USA. USENIX, 2001.

[144] Emily Stark, Michael Hamburg, and Dan Boneh. Stanford javascript crypto library. https://

github.com/bitwiseshiftleft/sjcl, 2009.

[145] Emily Stark, Michael Hamburg, and Dan Boneh. Symmetric cryptography in javascript. In ACSAC,

2009.

[146] Damien Stehle, Ron Steinfeld, Keisuke Tanaka, and Keita Xagawa. Efficient public key encryption

based on ideal lattices. In ASIACRYPT, 2009.

[147] Aaron Swartz. Securedrop. https://securedrop.org/, 2013.

[148] Richard Ta-Min, Lionel Litty, and David Lie. Splitting interfaces: Making trust between applications

and operating systems configurable. In Brian N. Bershad and Jeffrey C. Mogul, editors, 7th Symposium

on Operating Systems Design and Implementation (OSDI ’06), November 6-8, Seattle, WA, USA, pages

279–292. USENIX Association, 2006.

[149] Shuo Tang, Haohui Mai, and Samuel T. King. Trust and protection in the illinois browser operating

system. In Remzi H. Arpaci-Dusseau and Brad Chen, editors, 9th USENIX Symposium on Operat-

ing Systems Design and Implementation, OSDI 2010, October 4-6, 2010, Vancouver, BC, Canada,

Proceedings, pages 17–32. USENIX Association, 2010.

[150] Hongliang Tian, Yong Zhang, Chunxiao Xing, and Shoumeng Yan. Sgxkernel: A library operating

system optimized for intel SGX. In Proceedings of the Computing Frontiers Conference, CF’17, Siena,

Italy, May 15-17, 2017, pages 35–44, 2017.

[151] Chia-che Tsai, Donald E. Porter, and Mona Vij. Graphene-sgx: A practical library OS for unmodified

applications on SGX. In 2017 USENIX Annual Technical Conference, USENIX ATC 2017, Santa

Clara, CA, USA, July 12-14, 2017., pages 645–658, 2017.

[152] Nirvan Tyagi, Yossi Gilad, Derek Leung, Matei Zaharia, and Nickolai Zeldovich. Stadium: A dis-

tributed metadata-private messaging system. In SOSP, 2017.

[153] United Nations High Commissioner for Human Rights. The right to privacy in the digital age, 2018.

https://github.com/bitwiseshiftleft/sjcl

https://github.com/bitwiseshiftleft/sjcl

BIBLIOGRAPHY 160

[154] Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel Genkin, Baris Kasikci, Frank Piessens, Mark Sil-

berstein, Thomas F. Wenisch, Yuval Yarom, and Raoul Strackx. Foreshadow: Extracting the keys to

the Intel SGX kingdom with transient out-of-order execution. In Proceedings of the 27th USENIX

Security Symposium. USENIX Association, August 2018.

[155] Jelle van den Hooff, David Lazar, Matei Zaharia, and Nickolai Zeldovich. Vuvuzela: scalable private

messaging resistant to traffic analysis. In SOSP, 2015.

[156] Frank Wang, Catherine Yun, Shafi Goldwasser, Vinod Vaikuntanathan, and Matei Zaharia. libfss.

https://github.com/frankw2/libfss, 2017.

[157] Frank Wang, Catherine Yun, Shafi Goldwasser, Vinod Vaikuntanathan, and Matei Zaharia. Splinter:

Practical private queries on public data. In NSDI, 2017.

[158] Nico Weichbrodt, Anil Kurmus, Peter R. Pietzuch, and Rudiger Kapitza. Asyncshock: Exploiting

synchronisation bugs in intel SGX enclaves. In Computer Security - ESORICS 2016 - 21st European

Symposium on Research in Computer Security, Heraklion, Greece, September 26-30, 2016, Proceed-

ings, Part I, pages 440–457, 2016.

[159] Samuel Weiser and Mario Werner. SGXIO: generic trusted I/O path for intel SGX. In Gail-Joon Ahn,

Alexander Pretschner, and Gabriel Ghinita, editors, Proceedings of the Seventh ACM on Conference

on Data and Application Security and Privacy, CODASPY 2017, Scottsdale, AZ, USA, March 22-24,

2017, pages 261–268. ACM, 2017.

[160] Tara Whalen and Kori M. Inkpen. Gathering evidence: use of visual security cues in web browsers. In

Proceedings of the Graphics Interface 2005 Conference, May 9-11, 2005, Victoria, British Columbia,

Canada, pages 137–144, 2005.

[161] Wikipedia contributors. Next-generation secure computing base — Wikipedia, the free encyclopedia,

2018. accessed August 2018.

[162] Gordon Williams. tiny-js. https://github.com/gfwilliams/tiny-js, 2015.

[163] David Isaac Wolinsky, Henry Corrigan-Gibbs, Bryan Ford, and Aaron Johnson. Dissent in numbers:

Making strong anonymity scale. In OSDI, 2012.

[164] Yuanzhong Xu, Weidong Cui, and Marcus Peinado. Controlled-channel attacks: Deterministic side

channels for untrusted operating systems. In 2015 IEEE Symposium on Security and Privacy, SP 2015,

San Jose, CA, USA, May 17-21, 2015, pages 640–656, 2015.

[165] Miao Yu, Virgil D. Gligor, and Zongwei Zhou. Trusted display on untrusted commodity platforms.

In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security,

Denver, CO, USA, October 12-16, 2015, pages 989–1003, 2015.

https://github.com/frankw2/libfss

https://github.com/gfwilliams/tiny-js

BIBLIOGRAPHY 161

[166] Wenting Zheng, Ankur Dave, Jethro G. Beekman, Raluca Ada Popa, Joseph E. Gonzalez, and Ion

Stoica. Opaque: An oblivious and encrypted distributed analytics platform. In 14th USENIX Sympo-

sium on Networked Systems Design and Implementation, NSDI 2017, Boston, MA, USA, March 27-29,

2017, pages 283–298, 2017.

[167] Zongwei Zhou, Virgil D. Gligor, James Newsome, and Jonathan M. McCune. Building verifiable

trusted path on commodity x86 computers. In IEEE Symposium on Security and Privacy, SP 2012,

21-23 May 2012, San Francisco, California, USA, pages 616–630, 2012.

Date post:	25-Nov-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

STRONG PRIVACY FOR COMMUNICATION, BROWSING, AND …

Documents