I'm currently a PhD candidate working with Prof. Milind Kulkarni as part of the Purdue Programming Languages Group (PurPL). I work on building compilers for privacy-preserving computation. I'm on the job market right now!
I'm currently looking for tenure-track research faculty positions! You can find my application materials linked below:
TL;DR: I'm interested in building compilers and PLs for privacy-preserving computation.
The style of privacy-preserving computation I'm interested in is Multiparty Computation (MPC): a class of cryptographic techniques in which mutually distrustful parties collaborate to compute a function without revealing their private inputs to the function. More specifically, a lot of my work deals with Fully Homomorphic Encryption (FHE), a particular MPC protocol that works by encrypting inputs and then performing computations on the ciphertexts. People care a lot about MPC—at least, I do—because it enables privacy-preserving computation, and has some really cool applications like secure machine learning or offloading analyses over sensitive data. Unfortunately, actually writing programs that use MPC in practice is really hard: even in the current state of the art, the cryptographic overhead is insane (like, several orders of magnitude slower than normal), and the programming model can be highly counterintuitive for non-cryptographers.
I'm a compiler person, and with compilers as my hammer, the world of MPC looks a lot like a nail: a compiler can abstract away all the messy details about the MPC programming model, and allow you to write programs in a comfortable, familiar language. A lot of classic MPC compilers take a very…80's-esque…approach to compilation (mechanically translating operations into their secure equivalents and doing very little optimization on top of this). My research focuses on building compilers that are MPC-aware: By knowing something about the MPC scheme we're targeting, we're able to automatically apply some really cool tricks from the depths of crypto literature! For example, in Coyote, I showed how, by considering the subtleties of the cost model for vectorization in some FHE schemes we can avoid a lot of the pitfalls that classic, SLP-style vectorizers run into (and, as an added benefit, automatically find really good data layouts!) In COIL, I demonstrated that because of the way branches work in MPC (they don't), we have to be really careful when translating programs with control flow. By playing some clever tricks involving remembering branching conditions, we can sometimes avoid doing unnecessary computation altogether!
Of course, we can take all this a step further. Instead of just designing compilers that target particular cryptosystems, we can make cryptosystems that are better compilation targets and then build the compilers (I'm calling this "compiler-cryptosystem codesign" because it sounds like "hardware-software codesign"). I started working towards this goal with COATL, where I showed that by replacing the fundamental unit of computation in CGGI (a particular style of FHE scheme) with a thing I called arithmetic lookup tables instead of the usual Boolean gates, we can build compilers that manage to express the same programs using fewer CGGI operations overall!
My research barely scratches the surface of what I think is possible
in this space! A question I've been thinking about recently is, what
features should a cryptosystem support to make compiler writers'
jobs easier? What are the right abstractions to use here at the
protocol level? What about at the "language" level? Some really cool
people have done some really cool work (like
Viaduct, Taype) about
designing better languages for MPC, but a lot of this is still
pretty theoretical; how do we build actual, usable compilers for
these languages?
People have recently been looking at running FHE on things like
dedicated hardware accelerators; what would it take to write compilers that target these, instead
of the usual FHE libraries?
Finally, cryptographers keep adding features to their FHE schemes
that compilers don't really know how to use (my favorite examples of
this are
scheme switching and
faster BFV bootstrapping). Someone should do something about that!!
If any of these questions sound interesting to you, or you have
ideas or answers, please feel free to
contact me!
Cryptographic techniques have the potential to enable distrusting parties to collaborate in fundamentally new ways, but their practical implementation poses numerous challenges. An important class of such cryptographic techniques is known as Secure Multi-Party Computation (MPC). Developing Secure MPC applications in realistic scenarios requires extensive knowledge spanning multiple areas of cryptography and systems. And while the steps to arrive at a solution for a particular application are often straightforward, it remains difficult to make the implementation efficient, and tedious to apply those same steps to a slightly different application from scratch. Hence, it is an important problem to design platforms for implementing Secure MPC applications with minimum effort and using techniques accessible to non-experts in cryptography.
In this paper, we present the HACCLE (High Assurance Compositional Cryptography: Languages and Environments) toolchain, specifically targeted to MPC applications. HACCLE contains an embedded domain-specific language Harpoon, for software developers without cryptographic expertise to write MPC-based programs, and uses Lightweight Modular Staging (LMS) for code generation. Harpoon programs are compiled into acyclic circuits represented in HACCLE's Intermediate Representation (HIR) that serves as an abstraction over different cryptographic protocols such as secret sharing, homomorphic encryption, or garbled circuits. Implementations of different cryptographic protocols serve as different backends of our toolchain. The extensible design of HIR allows cryptographic experts to plug in new primitives and protocols to realize computation. And the use of standard metaprogramming techniques lowers the development effort significantly.
Fully Homomorphic Encryption (FHE) enables evaluating computations over ciphertexts without revealing the encrypted data. A key challenge when compiling for FHE is dealing with control flow: the usual semantics require the party evaluating the program to learn something about each branch, which violates the basic premise of secure computations. Standard "multiplexer"-based compilers solve this problem by generating programs that require the evaluator to execute every possible path, obviating the need to know which path is correct. Thus, they provide oblivious semantics at the cost of producing unwieldy circuits that are difficult to effectively optimize.
We present COIL, an FHE compiler that addresses the control flow challenge by restructuring how control flow in circuits is interpreted, replacing the use of multiplexers with path forests, and enabling a series of path-dependent optimizations that result in more efficient realizations of complex branching kernels. We demonstrate on a variety of benchmarks that COIL outperforms other state-of-the-art FHE compilation techniques, often by more than an order of magnitude.
Fully Homomorphic Encryption (FHE) is a cryptographic technique that enables privacy-preserving computation. State-of-the-art Boolean FHE implementations provide a very low-level interface, usually exposing a limited set of Boolean gates that programmers must use to write their FHE applications. This programming model is unnecessarily restrictive: many Boolean FHE schemes support programable bootstrapping, an operation that allows evaluation of an arbitrary fixed-size lookup table. However, most modern FHE compilers are only capable of reasoning about traditional Boolean circuits, and therefore struggle to take full advantage of programmable bootstrapping.
We present COATL, an FHE compiler that makes use of programmable bootstrapping to produce circuits that are smaller and more efficient than their traditional Boolean counterparts. COATL generates circuits using arithmetic lookup tables, a novel abstraction we introduce for reasoning about computations in Boolean FHE programs. We demonstrate on a variety of benchmarks that COATL can generate circuits that run up to 1.5x faster than those generated by other state-of-the-art compilation strategies.
This is bold and this is strong. This is
italic and this is emphasized. This is
superscript text and this is subscript text.
This is underlined and this is code:
for (;;) { ... }. Finally,
this is a link.
Fringilla nisl. Donec accumsan interdum nisi, quis tincidunt felis sagittis eget tempus euismod. Vestibulum ante ipsum primis in faucibus vestibulum. Blandit adipiscing eu felis iaculis volutpat ac adipiscing accumsan faucibus. Vestibulum ante ipsum primis in faucibus lorem ipsum dolor sit amet nullam adipiscing eu felis.
i = 0;
while (!deck.isInOrder()) {
print 'Iteration ' + i;
deck.shuffle();
i++;
}
print 'It took ' + i + ' iterations to sort the deck.';| Name | Description | Price |
|---|---|---|
| Item One | Ante turpis integer aliquet porttitor. | 29.99 |
| Item Two | Vis ac commodo adipiscing arcu aliquet. | 19.99 |
| Item Three | Morbi faucibus arcu accumsan lorem. | 29.99 |
| Item Four | Vitae integer tempus condimentum. | 19.99 |
| Item Five | Ante turpis integer aliquet porttitor. | 29.99 |
| 100.00 | ||
| Name | Description | Price |
|---|---|---|
| Item One | Ante turpis integer aliquet porttitor. | 29.99 |
| Item Two | Vis ac commodo adipiscing arcu aliquet. | 19.99 |
| Item Three | Morbi faucibus arcu accumsan lorem. | 29.99 |
| Item Four | Vitae integer tempus condimentum. | 19.99 |
| Item Five | Ante turpis integer aliquet porttitor. | 29.99 |
| 100.00 | ||