strong privacy for communication, browsing, and …
TRANSCRIPT
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
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
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.
Zakir Durumeric
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.
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
CHAPTER 1. INTRODUCTION 3
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.
CHAPTER 1. INTRODUCTION 4
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,
CHAPTER 1. INTRODUCTION 5
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
CHAPTER 1. INTRODUCTION 6
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],
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 9
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.
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 10
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.
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 11
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 12
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 13
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 14
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 15
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" />
10 <input type="text"
11 value="Card Number" name="card"/>
12 <input type="text"
13 value="MM/YY" name="exp"/>
14 <input type="text"
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>
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 16
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.
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 17
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,
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 18
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 19
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.
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 20
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 21
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 22
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.
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 23
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 24
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 25
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.
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 26
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.
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 27
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.
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 28
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 29
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 30
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 31
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 32
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 33
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
CHAPTER 2. FIDELIUS: PROTECTING USER SECRETS FROM COMPROMISED BROWSERS 34
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.
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],
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 37
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 38
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.
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 39
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 40
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 –
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 41
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.
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 42
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.
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 43
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.
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 44
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 45
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 46
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 47
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 48
“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.
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 49
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 50
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 51
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.
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 52
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 53
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 54
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
Pung Riposte Express
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 55
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 56
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 57
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
Pung Riposte Express
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.
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 58
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 59
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 60
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 61
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.
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 62
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 63
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].
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 64
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
CHAPTER 3. EXPRESS: LOWERING THE COST OF METADATA-HIDING COMMUNICATION 65
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].
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 68
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 69
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 70
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].
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 71
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(λ),
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 72
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 73
• 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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 74
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 75
• 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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 76
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 77
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 78
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 ← ReKeyGen(ki, kj , ct)
(ct′, ct′)← ReEncrypt
(∆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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 79
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)
),
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 80
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).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 81
• 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).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 82
• 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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 83
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 84
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)
):
∆i,j,ct ← ReKeyGen(ki, kj , ct)
(ct′, ct′)← ReEncrypt
(∆i,j,ct, (ct, ct)
)if j ≤ h:
T[j, ct′]← ct′
Output (ct′, ct′)
OReKeyGen(i, j, ct):
if i > h and j ≤ h:
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
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 85
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,
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 86
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
(cti+1, cti+1)← ReEncrypt(ReKeyGen(ki, ki+1, cti), (cti, cti)
),
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 87
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 (λ)
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 88
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|
Output (ct′, 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 (λ)
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 89
∣∣∣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λ.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 90
KeyGen(1λ, 1t):
k← AE.KeyGen(1λ)
Output k
ReKeyGen(k1, k2, ct):
µ← 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)
ReEncrypt(∆1,2,ct, (ct, ct)
):
(ct′, kupprf)← ∆1,2,ct
(ct1, . . . , ct`)← ct
for i ∈ [`]:
ct′i ← cti + F (kupprf , i)
ct′ ← (ct′1, . . . , ct′`)
Output (ct′, 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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 91
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).
We construct an updatable authenticated encryption scheme ΠUAE = (KeyGen,Encrypt,ReKeyGen,ReEncrypt,
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 92
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 .
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 93
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 94
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 .
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 95
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(λ).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 96
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]
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 97
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
32KB MessagesEncrypt 29.85 39.89 61.90 5.94 5.50 0.12 1836.9ReEncrypt 32.33 44.51 83.06 6.43 5.85 0.15 2606.8
100KB MessagesEncrypt 31.03 41.63 65.11 9.42 9.12 0.12 3029.5ReEncrypt 33.30 45.77 79.63 9.92 8.70 0.14 3766.2
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 98
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 99
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 100
• 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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 101
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 102
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):
Output Encrypt(ki,m)
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 ← ReKeyGen(ki, kj , ct)
(ct′, ct′)← ReEncrypt
(∆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′)
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 103
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):
Output Encrypt(ki,m)
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 ← ReKeyGen(ki, kj , ct)
(ct′, ct′)← ReEncrypt
(∆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′)
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(λ).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 104
Exptctxt-intΠUAE(λ, h, d,A):
win← false
k1, . . . , kh+d ← KeyGen(1λ)
AO(kh+1, ..., kh+d)
Output win
OEncrypt(i,m):
(ct, ct)← Encrypt(ki,m)
T[i, ct]← ct
Output (ct, ct)
OReKeyGen(i, j, ct):
if i > h and j ≤ h:
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
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,
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 105
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.
We construct an updatable authenticated encryption scheme ΠUAE = (KeyGen,Encrypt,ReKeyGen,ReEncrypt,
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).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 106
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)
ReKeyGen(k1, k2, 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
ReEncrypt(∆1,2,ct, (ct, 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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 107
(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(λ).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 108
Exptrelaxed-intΠ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)
)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):
(ct, ct)← Encrypt(ki,m)
T[i, ct]← ct
Output (ct, ct)
OReKeyGen(i, j, ct):
if i > h and j ≤ h:
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)
):
m← Decrypt(ki, (ct, ct)
)if m = ⊥:
Output ⊥∆i,j,ct ← ReKeyGen(ki, kj , ct)
(ct′, ct′)← ReEncrypt
(∆i,j,ct, (ct, ct)
)if j ≤ h:
T[j, ct′]← ct′
Output (ct′, ct′)
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,
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 109
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
(cti+1, cti+1)← ReEncrypt(ReKeyGen(ki, ki+1, cti), (cti, cti)
),
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 110
- 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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 111
– 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
ct′ ← AE.Encrypt
(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
ct′ ← AE.Encrypt
(kj , (s
′, l, k′ae, k′history)
)and ciphertext body ct′ according to ReEncrypt
(∆i,j,ct, (ct, ct)
)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 ⊥.
The rest of the experiment remains unchanged from Hyb1.
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:
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 112
– 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
ct′ ← AE.Encrypt
(kj , (0
|s′|, 0intlen, 0|k′ae|, 0|k
′history|)
).
The rest of the simulation in answering A’s queries remain unchanged.
– OChallenge(i, j,m, (ct, ct)): If j ≤ h, the challenger answers the oracle query exactly as in Hyb2,
but it sets the ciphertext header ct′ to be
ct′ ← AE.Encrypt
(kj , ((0
|s|, 0intlen, 0|kae|, 0λ))
when b = 0 or
ct′ ← AE.Encrypt
(kj , ((0
|s′|, 0intlen, 0|k′ae|, 0k
′history)
)when b = 1. The rest of the simulation in answering A’s queries remain unchanged.
The rest of the experiment remains unchanged from Hyb2.
In theorem 4.13.3 below, we show that the hybrid experiments Hyb2 and Hyb3 are computationally
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.
The rest of the experiment remains unchanged from Hyb3.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 113
In theorem 4.13.5 below, we show that the hybrid experiments Hyb3 and Hyb4 are computationally
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.
– OChallenge(i, j,m, (ct, ct)): If j ≤ h, the challenger answers the oracle exactly as in Hyb4, but
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.
In theorem 4.13.7 below, we show that the hybrid experiments Hyb4 and Hyb5 are computationally
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.
– OChallenge(i, j,m, (ct, ct)): If j ≤ h, the challenger answers the oracle exactly as in Hyb5, but
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.
In theorem 4.13.9 below, we show that the hybrid experiments Hyb5 and Hyb6 are computationally
indistinguishable assuming that AE.Encrypt has ciphertext pseudorandomness.
• 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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 114
In theorem 4.13.10 below, we show that the hybrid experiments Hyb6 and Hyb7 are perfectly indistin-
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
indistinguishable assuming that AE.Encrypt has ciphertext pseudorandomness.
• 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, ·).
In theorem 4.13.12 below, we show that the hybrid experiments Hyb8 and Hyb9 are computationally
indistinguishable assuming that AE.Encrypt has ciphertext pseudorandomness.
• 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.
In theorem 4.13.13 below, we show that the hybrid experiments Hyb9 and Hyb10 are computationally
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.
In theorem 4.13.14 below, we show that the hybrid experiments Hyb10 and Hyb11 are computationally
indistinguishable assuming that ΠAE satisfies confidentiality.
• 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.
In theorem 4.13.16 below, we show that the hybrid experiments Hyb12 and Hyb13 are computationally
indistinguishable assuming that ΠAE satisfies integrity.
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 115
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
′, `, k′ae, k′history)
), 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.
Otherwise, it proceeds according to Hyb0. In both cases, whenever B must use ki∗ to generate the
ciphertext header ct′ ← AE.Encrypt(ki∗ , (s
′, `, k′ae, k′history)
), 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)).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 116
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 117
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.
• Query phase: Algorithm B simulates the responses to A’s oracle queries as follows:
– 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λ)
),
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 118
in place of AE.Encrypt(kγ , (s, |ctpayload|, kae,⊥)
)or AE.Encrypt
(kγ , (0
|s|, 0intlen, 0|kae|, 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
|s′|, 0intlen, 0|k′ae|, 0|k
′history|)
),
in place of AE.Encrypt(kγ , (s
′, `, k′ae, k′history)
)or AE.Encrypt
(kγ , (0
|s′|, 0intlen, 0|k′ae|, 0|k
′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
((s, |ctpayload|, kae,⊥), (0|s|, 0intlen, 0|kae|, 0λ)
)= AE.Encrypt
(kγ , (s, |ctpayload|, kae,⊥)
),
and
Okγ ,1
((s, |ctpayload|, kae,⊥), (0|s|, 0intlen, 0|kae|, 0λ)
)= AE.Encrypt
(kγ , (0
|s|, 0intlen, 0|kae|, 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
define the hybrid experiments Hyb3,γ as follows:
• Hyb3,γ : The challenger proceeds through the setup phase of the experiment according to the specifica-
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:
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 119
– OEncrypt(i,m): If k > γ, then the challenger proceeds as in Hyb3. Otherwise, the challenger
proceeds as in Hyb4.
– OReEncrypt
(i, j, (ct, ct)
): If k > γ, then the challenger proceeds as in Hyb3. Otherwise, the
challenge proceeds as in Hyb4.
– OChallenge(i, j,m, (ct, ct)): If k > γ, then the challenger proceeds as in Hyb3. Otherwise, the
challenger proceeds as in Hyb4.
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 Hyb3,0 corresponds to experiment Hyb3, and experiment Hyb3,Q correponds to
experiment Hyb3. To prove the lemma, we show that each consecutive hybrid experiments Hyb3,γ−1 and
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.
The statement of the lemma now follows from theorem 4.13.6 and the triangle inequality.
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 (λ).
Proof. To prove the lemma, we proceed via a sequence of inner hybrid experiments. For γ = 0, . . . , Q, we
define the hybrid experiments Hyb4,γ as follows:
• Hyb4,γ : The challenger proceeds through the setup phase of the experiment according to the specifica-
tions in Hyb4 and Hyb5 (which are identical). The challenger numbersA’s oracle queries, starting from
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 120
Q and counting backwards, and answers A’s kth last query during the query phase of the experiment
as follows:
– OEncrypt(i,m): If k > γ, then the challenger proceeds as in Hyb4. Otherwise, the challenger
proceeds as in Hyb5.
– OReEncrypt
(i, j, (ct, ct)
): If k > γ, then the challenger proceeds as in Hyb4. Otherwise, the
challenge proceeds as in Hyb5.
– OChallenge(i, j,m, (ct, ct)): If k > γ, then the challenger proceeds as in Hyb4. Otherwise, the
challenger proceeds as in Hyb5.
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 Hyb4,0 corresponds to experiment Hyb4, and experiment Hyb4,Q correponds to
experiment Hyb5. To prove the lemma, we show that each consecutive hybrid experiments Hyb4,γ−1 and
Hyb4,γ for γ = 1, . . . , Q are computationally indistinguishable.
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 (λ).
Proof. Let A be an adversary that distinguishes experiments Hyb4,γ−1 and Hyb4,γ . We construct an algo-
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 121
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.
The statement of the lemma now follows from theorem 4.13.8 and the triangle inequality.
Lemma 4.13.9. 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[Hyb5(A) = 1]− Pr[Hyb6(A) = 1]∣∣ ≤ Q · εrandae (λ).
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.
Lemma 4.13.11. 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[Hyb7(A) = 1]− Pr[Hyb8(A) = 1]∣∣ ≤ Q · εrandae (λ).
Proof. The proof is identical to the proof of Lemma 4.13.9.
Lemma 4.13.12. 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[Hyb8(A) = 1]− Pr[Hyb9(A) = 1]∣∣ ≤ Q · εrandae (λ).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 122
Proof. The proof is identical to the proof of Lemma 4.13.7.
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(λ).
Proof. The proof is identical to the proof of Lemma 4.13.5.
Lemma 4.13.14. Suppose that ΠAE satisfies εconfae -confidentiality (theorem 4.2.8). Then, for all efficient
adversaries A, we have
∣∣Pr[Hyb10(A) = 1]− Pr[Hyb11(A) = 1]∣∣ ≤ h · εconfae (λ).
Proof. The proof is identical to the proof of Lemma 4.13.3.
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.
Proof. The proof is identical to the proof of Lemma 4.13.2.
Lemma 4.13.16. Suppose that ΠAE satisfies εintae -integrity (Definition 4.2.9). Then, for all efficient adversaries
A, we have ∣∣Pr[Hyb12(A) = 1]− Pr[Hyb13(A) = 1]∣∣ ≤ h · εintae (λ).
Proof. The proof is identical to the proof of Lemma 4.13.1.
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 123
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.
• 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. 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
′, l, k′ae, k′history)
), 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
′history) to the table.
– 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
′, l, k′ae, k′history)
), 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
′history) to the table.
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 = ⊥,
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 124
– 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 ⊥.
The rest of the experiment remains unchanged from Hyb0.
In theorem 4.13.17 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 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)
): 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 ⊥.
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 ⊥.
The rest of the experiment remains unchanged from Hyb1.
In theorem 4.13.18 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λ)).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 125
The rest of the simulation in answering A’s queries remain unchanged.
– 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
ct′ ← AE.Encrypt
(kj , (0
|s′|, 0intlen, 0|k′ae|, 0|k
′history|)
).
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
ct′ ← AE.Encrypt
(kj , (0
|s′|, 0intlen, 0|k′ae|, 0|k
′history|)
).
The rest of the simulation in answering A’s queries remain unchanged.
The rest of the experiment remains unchanged from Hyb2.
In theorem 4.13.19 below, we show that the hybrid experiments Hyb2 and Hyb3 are computationally
indistinguishable assuming that ΠAE satisfies confidentiality.
• 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|)).
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 setting cthistory ← AE.Encrypt(k′history, (kae, khistory)), it sets cthistory to be
cthistory ← AE.Encrypt(k′history, (0|kae|, 0|khistory|)).
The rest of the simulation in answering A’s queries remains unchanged.
In theorem 4.13.20 below, we show that the hybrid experiments Hyb3 and Hyb4 are computationally
indistinguishable assuming that ΠAE satisfies confidentiality.
• Hyb5: 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 Tpayload that keeps track of all of the “well-formed” payload ciphertexts ctpayload under
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 126
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.
In theorem 4.13.22 below, we show that the hybrid experiments Hyb4 and Hyb5 are computationally
indistinguishable assuming that ΠAE satisfies integrity.
Finally, in theorem 4.13.23 below, we show that an adversary has negligible advantage in forcing the
challenger to output 1 in Hyb5.
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.17. 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. This proof is almost identical to that of theorem 4.13.1, so we omit the full proof.
Lemma 4.13.18. 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 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.
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 127
Theader, the challenger returns ⊥. Therefore, the view ofA in the two experiments are identically distributed.
Lemma 4.13.19. Suppose that ΠAE satisfies εconfae -confidentiality (theorem 4.2.8). Then, for all efficient
adversaries A, we have
∣∣Pr[Hyb2(A) = 1]− Pr[Hyb3(A) = 1]∣∣ ≤ h · εconfae (λ).
Proof. This proof is almost identical to that of theorem 4.13.3, so we omit the full proof.
Lemma 4.13.20. Suppose that ΠAE satisfies εconfae -confidentiality (theorem 4.2.8). Then, for all efficient
adversaries A that make at most Q oracle queries, we have
∣∣Pr[Hyb3(A) = 1]− Pr[Hyb4(A) = 1]∣∣ ≤ Q · εconfae (λ).
Proof. To prove the lemma, we proceed via a sequence of inner hybrid experiments. For γ = 0, . . . , Q, we
define the hybrid experiments Hyb3,γ as follows:
• Hyb3,γ : The challenger proceeds through the setup phase of the experiment according to the specifica-
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:
– OEncrypt(i,m): If k > γ, then the challenger proceeds as in Hyb3. Otherwise, the challenger
proceeds as in Hyb4.
– OReKeyGen
(i, j, ct
): If k > γ, then the challenger proceeds as in Hyb3. Otherwise, the challenger
proceeds as in Hyb4.
– OReEncrypt
(i, j, (ct, ct)
): If k > γ, then the challenger proceeds as in Hyb3. Otherwise, the
challenge proceeds as in Hyb4.
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 Hyb3,0 corresponds to experiment Hyb3, and experiment Hyb3,Q corresponds to
experiment Hyb4. To prove the lemma, we show that each consecutive hybrid experiments Hyb3,γ−1 and
Hyb3,γ for γ = 1, . . . , Q are computationally indistinguishable.
Claim 4.13.21. Suppose that ΠAE satisfies εconfae -confidentiality. Then, for all γ ∈ [h] and all efficient adver-
saries A, we have ∣∣Pr[Hyb3,γ−1(A) = 1]− Pr[Hyb3,γ(A)]∣∣ ≤ εconfae (λ).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 128
Proof. Let A be an adversary that distinguishes experiments Hyb3,γ−1 and Hyb3,γ . We construct an algo-
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
cthistory ← AE.Encrypt(k′history, (kae, khistory))
or
cthistory ← AE.Encrypt(k′history, (0|kae|, 0|khistory|)).
The rest of the simulation in answering A’s queries remains unchanged.
• 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
cthistory ← AE.Encrypt(k′history, (kae, khistory))
or
cthistory ← AE.Encrypt(k′history, (0|kae|, 0|khistory|)).
The rest of the simulation in answering A’s queries remains unchanged.
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
(theorem 4.2.8), we have
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|)).
This means that if B is interacting with the oracle Okγ ,0, then it perfectly simulates Hyb3,γ−1, and if it is
interacting with the oracle Okγ ,1, then it perfectly simulates Hyb3,γ . This is the case because if j ≤ h, the
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 129
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.
The statement of the lemma now follows from theorem 4.13.21 and the triangle inequality.
Lemma 4.13.22. Suppose that ΠAE satisfies εintae -integrity (Definition 4.2.9). Then, for all efficient adversaries
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 130
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.
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 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.
Lemma 4.13.23. For all (unbounded) adversaries A, we have
∣∣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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 131
4.14 Proof of theorem 4.5.3
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
(cti+1, cti+1)← ReEncrypt(ReKeyGen(ki, ki+1, cti), (cti, cti)
),
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).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 132
• 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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 133
4.14.3 Proof of Confidentiality
We proceed via a sequence of hybrid experiments that are defined as follows:
• 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:
– OEncrypt(i,m): The challenger answers the oracle exactly as in Hyb0 by generating the ciphertext
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
ct′ ← AE.Encrypt
(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.
The rest of the experiment remains unchanged from Hyb0.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 134
In theorem 4.14.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. 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)
): 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 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 ⊥.
The rest of the experiment remains unchanged from Hyb1.
In theorem 4.14.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 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
ct← AE.Encrypt(ki, (0
|kprf |, 0|h|)).
The rest of the simulation in answering A’s queries remains unchanged.
– 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
ct′ ← AE.Encrypt
(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
ct′ ← AE.Encrypt
(k2, (0
|k′prf |, 0|h|)).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 135
– 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
ct′ ← AE.Encrypt
(kj , (0
|kprf |, 0|h|)).
The rest of the simulation in answering A’s queries remain unchanged.
The rest of the experiment remains unchanged from Hyb2.
In theorem 4.14.3 below, we show that the hybrid experiments Hyb2 and Hyb3 are computationally
indistinguishable assuming that ΠAE satisfies confidentiality.
• 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.
In theorem 4.14.5 below, we show that the hybrid experiments Hyb3 and Hyb4 are computationally
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 ∈ [`].
The rest of the experiment remains unchanged from Hyb3.
In theorem 4.14.7 below, we show that the hybrid experiments Hyb4 and Hyb5 are perfectly indistin-
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.
In theorem 4.14.8 below, we show that the hybrid experiments Hyb5 and Hyb6 are computationally
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.
In theorem 4.14.9 below, we show that the hybrid experiments Hyb6 and Hyb7 are computationally
indistinguishable assuming that ΠAE satisfies confidentiality.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 136
• 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.
In theorem 4.14.10 below, we show that the hybrid experiments Hyb7 and Hyb8 are perfectly indistin-
guishable assuming that ΠAE is correct.
• Hyb9: In this hybrid experiment, we undo the changes that we made in Hyb1 by removing the additional
abort condition.
In theorem 4.14.11 below, we show that the hybrid experiments Hyb8 and Hyb9 are computationally
indistinguishable assuming that ΠAE satisfies integrity.
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.
Lemma 4.14.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∗ , (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.
Otherwise, it proceeds according to Hyb0. 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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 137
– OChallenge(i, j,m, (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∗ , (k
′prf , h)
), it uses the encryption oracle Ok∗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 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.
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 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
].
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 138
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.14.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 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.
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.14.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 experiment. 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.
– OReKeyGen(i, j, ct): 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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 139
– 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,γ correponds 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.14.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[Hyb3,γ(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.
• Query phase: Algorithm B simulates the responses to A’s oracle queries as follows:
– 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
((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,
since kγ is unspecified, it uses the encryption oracle
Okγ ,b
((k′prf , h), (0|k
′prf |, 0|h|)
),
in place of AE.Encrypt(kγ , (kprf , 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.
However, since kγ is unspecified, it uses the encryption oracle
Okγ ,b
((k′prf , h), (0|k
′prf |, 0|h|)
),
in place of AE.Encrypt(kγ , (kprf , h)
)or AE.Encrypt
(kγ , (0
|k′prf |, 0|h|)).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 140
– 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 oracle
Okγ ,b
((kprf , h), (0|kprf |, 0|h|)
),
in place of AE.Encrypt(kγ , (kprf , 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
(theorem 4.2.8), we have
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|)).
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.14.4 and the triangle inequality.
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(λ).
Proof. To prove the lemma, we proceed via a sequence of inner hybrid experiments. For γ = 0, . . . , Q, we
define the hybrid experiments Hyb3,γ as follows:
• 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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 141
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 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(λ).
The statement of the lemma now follows from theorem 4.14.6 and the triangle inequality.
Lemma 4.14.7. For all (unbounded) adversaries A, we have
∣∣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(λ).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 142
Proof. The proof is identical to the proof of Lemma 4.14.5.
Lemma 4.14.9. Suppose that ΠAE satisfies εconfae -confidentiality (theorem 4.2.8). Then, for all efficient ad-
versaries A, we have
∣∣Pr[Hyb6(A) = 1]− Pr[Hyb7(A) = 1]∣∣ ≤ h · εconfae (λ).
Proof. The proof is identical to the proof of Lemma 4.14.3.
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.
Proof. The proof is identical to the proof of Lemma 4.14.2.
Lemma 4.14.11. Suppose that ΠAE satisfies εintae -integrity (Definition 4.2.9). Then, for all efficient adversaries
A, we have ∣∣Pr[Hyb8(A) = 1]− Pr[Hyb9(A) = 1]∣∣ ≤ h · εintae (λ).
Proof. The proof is identical to the proof of Lemma 4.14.1.
By combining the lemmas above and using the triangle inequality, the proof of confidentiality follows.
4.14.4 Proof of Relaxed 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 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:
– OEncrypt(i,m): The challenger answers the oracle exactly as in Hyb0 by generating the ciphertext
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.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 143
– 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
(∆i,j,ct, (ct, ct)
)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
(∆i,j,ct, (ct, ct)
)to A. If
j ≤ h, then it additionally adds Theader[j, ct′]←
((k′prf , h),m
)to the table.
At the end of the experiment, adversaryA outputs an index i ≤ h and a ciphertext (ct, ct). As specified
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.
In theorem 4.14.12 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. 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)
): The challenger answers the oracle exactly as in Hyb1, but instead of
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 ⊥.
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 144
At the end of the experiment, adversaryA outputs an index i ≤ h and a ciphertext (ct, ct). As specified
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.
In theorem 4.14.13 below, we show that the hybrid experiments Hyb1 and Hyb2 are perfectly indistin-
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.
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.14.12. Suppose that ΠAE satisfies εintae -integrity (theorem 4.2.9). Then, for all efficient adversaries
A, we have ∣∣Pr[Hyb0(A) = 1]− Pr[Hyb1(A) = 1]∣∣ ≤ h · εintae (λ).
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.
Lemma 4.14.13. 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 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
adversaries A, we have
Pr[Hyb2(A) = 1] ≤ εcr(λ).
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 145
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
m← Decrypt(ki, (ct, ct)
)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 Proof of theorem 4.6.3
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
CHAPTER 4. IMPROVING SPEED AND SECURITY IN UPDATABLE ENCRYPTION SCHEMES 146
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.