 Thank you very much for that introduction Thanks everybody for sticking around and I know we all want to eat food at the beach So as the title suggests, I'm gonna talk about a very practical problem related to public key encryption today so syntactically we think of public key encryption as taking in a message and a public key and randomly outputting a ciphertext in practice Applications make use of pke by invoking a library such as open SSL Now it's convenient to assume that the library has access to a source of uniform random coins But in and in fact this assumption of uniformity underpins our traditional notions of security such as indcpa But as we all know in reality these coins are produced by some real system Which ultimately gathers entropy from its environment in order to produce them And as we all know again this complex process often fails in practice to produce coins of sufficient quality The causes are many It might be as simple as commenting out the wrong line of code There could be simply not enough entropy available in the systems environment Or it could be as malicious as a backdoor being built into the design of the rng itself So how can we hope to cope with such a variety of randomness failures? The aim of hedge cryptography is to design primitives and protocols that fail gracefully and by this I mean they achieve the usual notion of security when randomness is good But achieve some weaker yet still meaningful notion when randomness is bad So at their seminal in their seminal paper at Asia 2009 along with inventing the field kind of the laureate all proposed a nice solution for hedged public key encryption Their idea is to synthesize fresh coins for encryption But using the randomness provided by the system as well as any entropy contained in the message being encrypted To do this we just hash together the public key message and randomness and use the output as the source of randomness for any standard PKE scheme So in the random oracle model unless the adversary is able to guess both the message and randomness The synthesized coins can be treated as uniform This trick which in this talk I'll call encrypt with hash has been adapted to a wide variety of settings There are a number of papers that deal with encryption in the presence of imperfect randomness and in many of these Some instantiation of this trick is proposed as a defense It's also used in the context of deterministic encryption where no randomness is used at all and we rely just on the entropy in the message In fact the idea of synthesizing coins for encryption was used at least as early as 1999 by Fuji sake and Okamoto who used it as part of a transform from CPA to CCA security So as you can see there's been a lot of theoretical interest in this idea It's explicitly designed for practice It seems like it's a cheap and practical way to harden deployed crypto Because of course it works with any encryption scheme and you should be able to implement it without making any code changes So the conceptual starting point for our work is a very simple question Just how easy is it to implement encrypt with hash with real libraries? So to start we looked at open a cell at open SSL Perhaps the most widely deployed crypto library in use today So at its highest level open SSL provides an abstraction for public key encryption sometimes called secure envelopes The first input to this function is the encryption context which specifies the public key and algorithm Open SSL facilitates key generation and management and it's possible to instantiate this context properly without knowing much about the underlying crypto And this is great news from a usability perspective Conventional wisdom in API design is that the programmer should have to make as few security choices as possible And it seems like we see this principle at work here But in short the encryption context lets the programmer specify the public key The remaining arguments specify a buffer for the cipher text and the plain text Notice that nowhere in this interface. Is there a place for the programmer to specify the random coins and And this is likely intentional on the part of the API designers Crucially, it's harder to misuse this API in particular by inadvertently providing a weak entropy source But this design choice also means that we can't implement encrypt with hash at least at least at this API level Okay, but if you know what you're doing the library should provide a little more flexibility So let's go a level deeper and look at open SSL's interface for RSA based encryption As usual the the programmer provides a buffer for the plain text and cipher text and public key In addition, this interface requires the programmer to specify the padding scheme So open SSL implements a few standards and it even lets the programmer use no padding at all Which means you can implement raw RSA or handle padding yourself So this is this interface gives you just about all the flexibility you need for RSA Except that it still doesn't expose the coins So the high and mid-level API's don't let us implement encrypt with hash, but let's not give up quite yet As we all know hacking open SSL makes for excellent headlines So let's dig a little deeper into the code and see what we can do The first question is where the coins coming from So here we have a little code snippet of RSA OAP. It will be implementation and open SSL The function that implements the padding takes as input the message as well as some other stuff We can ignore for this talk and outputs the padded message This in turn invokes a function called brand bytes, which fetches the required number of bytes from open SSL's RNG So it's down at this level This lowest level that is the first chance you have to touch the coins So let me restate the question. How do I implement in encrypt with hash in open SSL? Let's have a look at the options If you're an open SSL maintainer the most direct approach would be to modify the implementation So for example, you can modify OAP code directly so that the public key message and output of ran bytes are hashed together And the output is used as the seed for the padding and this would of course be pretty straightforward to do However, these modifications mean that your implementation of RSA OAP no longer complies to the RFC that standardizes it So from a compliant standpoint, this solution is a non-starter Another approach which requires no code changes at all would be to manipulate the output of the RNG And so how can we do this? Is this even possible? So open SSL allows the application to provide entropy for the RNG and The same interface might be used at least in principle to implement encrypt with hash But there are a number of technical hurdles to overcome here not the least of which is that it simply doesn't work in general One reason is that open SSL lets the programmer specify a hardware-based RNG that uses the same interface But for obvious reasons Hardware RNGs don't let you modify their internal state So there's no way to make this work with this configuration From a software engineering perspective I think the best option is to build your own RNG for open SSL that explicitly supports the implementation of encrypt with hash This isn't such a bad idea, but it does it doesn't mean you're gonna have to contribute a fair bit of code to the library But for those of us who'd rather not have to touch the code. There are no viable options The punchline to the story is that encrypt with hash while really nice in theory is not as easy as it would seem to implement So you might be asking yourself if the problem is the API then why not just change the API Well first and foremost if a change is made to the interface Then this means that every application that uses that interface needs to be modified as well And it's for this reason that a library as heavily used as open SSL needs to have a very stable interface And the planners need the designers need to be planned for it to be around for a very long time The fact is that API design is hard work it's a complex trade-off between making the library easy to use and easy to extend and There are just no easy answers to the question of how much exposure to give to the programmer We looked at a number of libraries some widely used in others less So and found that about half of them expose the RNG to the programmer in a way that directly Facilitates encrypt with hash this finding highlights this tension between usability and flexibility in API design But I'd like to emphasize that none of the libraries on the left side of this table are used as widely as a as open SSL It's also worth noting that encrypt with hash is not the only way to hedge PKE So for example, Ballari at all propose a couple solutions that involve deterministic encryption But such schemes are not implemented in common libraries, and you can't use them at least not without touching the coins Okay, so these observations led us to revisit the theory of hedge PKE and see if we couldn't nudge it a little closer to practice and Doing so we're guided by two basic questions The first is what simple and efficient schemes can we implement using API's exported by common libraries and Second, what are the strongest security notions we can hope to achieve with these schemes? Towards addressing the second question we took as our starting point the security notion of Ballari at all which they call indistinguishability indistinguishability under chosen distribution attacks We're going to rename this to MMR CPA for reasons that will be apparent in a little while But first in order to understand their notion, it's helpful to begin with the user usual chosen plain text attack setting So in the IND CPA game We give the adversary an encryption oracle of which it asks pairs of messages It gets in response an encryption of one of these which one gets encrypted depends on the outcome of a coin flip made at the beginning of the game Since we're interested in randomness failures will explicitly just define the algorithm that produced the coins. Let's call it R Now in the IND CPA setting we assume the output of R is uniform But what happens when this assumption fails in the worst case? The adversary may simply be able to guess the coins then no encryption scheme provides security under chosen plain text attack The key insight of Ballari at all is that if the message has sufficient entropy then we can leverage this fact for security So in a chosen distribution attack the adversary specifies a distribution on message pairs In fact, the notion is a little bit stronger than this We actually allow the messages and coins to be jointly distributed To model this we have the adversary specify a randomized algorithm called an MMR Well called an MMR source that outputs a message a message and some randomness The oracle executes this algorithm encrypts one of the messages with the coins and returns the output So this notion already captures our intuition of what can't we can achieve when randomness fails However, there's a problem. It turns out that we can't provide security for distributions that depend on the public key Given the public key, it's possible for the adversary to craft an MMR source such that the cipher text leaks the message The challenge bit in just one query So to ameliorate this problem, we withhold the public key from the adversary until after it finishes its queries So now the adversary runs in two stages in the first it makes its queries and in the second It's given the public key and it outputs its guess Finally, we can further strengthen the notion by modeling messages and coins jointly distributed across encryption calls We do this by having the MMR source output vectors of plain text and coins and With that we have the security notion of Bollari at all To summarize in the IND CPA setting the adversary chooses the messages and the coins are chosen uniformly by the oracle in the MMR CPA setting the adversary specifies a distribution on messages and coins, which is required to have Hyman entropy We say that a PKE scheme is is hedge secure if it achieves both of these notions simultaneously Okay, so this is our starting point The first way we exchange this model is in a small syntactic way in our paper We decided to look at labeled encryption where sender and receiver share some data associated to the plain text This idea goes back to a classical paper by Victor Shupe It's also important in practice of some schemes implemented in real libraries actually use labels But more significantly we strengthen the notion by incorporating chosen ciphertext attacks To do this we provide the adversary with a decryption oracle in both its query and guessing stages We show that MMR CCA is achievable with primitives exported by high-level APIs What we propose is a hybrid encryption scheme based on a trapdoor permutation hash functions which we model as random oracles in the security analysis and Symmetric authenticated encryption with associated data commonly abbreviated to AEAD The construction itself is relatively straightforward, but I'd like to point out one interesting detail The public key is not just the description of the trapdoor F It also includes a short uniform random string called a randomizer The randomizer is part of a technical trick that simplifies the proof of security and it allows us to make no assumptions about the trapdoor permutation beyond one wayness It's actually borrowed from Bollari at all and is widely used in the Hedge PKE literature A Practical implication is that if you have a certificate for the trapdoor F like an RSA public key for example Adding the randomizer to the public key means that you have to reissue a certificate This can be somewhat problematic in practice But otherwise implementing this scheme is a straightforward matter of piecing together high-level API calls There are some technical details to attend to but someone with a moderate amount of crypto expertise Would be able to implement this correctly But if you don't want to reissue certificates and you don't want to have to cobble together API calls you're stuck Fully implemented PKE schemes exported by libraries simply don't achieve this strong MMR notion This led us to rethink the MMR setting The model allows for adversaries that adaptively corrupt the randomness source and prior to every encryption call So in practice and in the worst case this attack amounts to changing the behavior of the system RNG prior to every invocation of the encryption algorithm We think this model is overly conservative at least with respect to known attacks and randomness failures I'll remind you that the high-profile failures I alluded to at the beginning all involved one-time corruption of the RNG This observation led us to consider a weaker attack in which the coins are corrupted once prior to the adversaries attack Instead of specifying an MMR source the adversary specifies an MM source which outputs vectors of messages The vector of coins is output by a randomness source which parameterizes the security experiment Thus in the MMCCA game the the coins and messages are independent This fact allows us to give the adversary the public key at the outset This is achievable if the randomness source has enough entropy so that the adversary can't just guess the coins But this change is useful for a couple reasons First it's intuitively nice Because the attacker does know the public key in real life whether or not its attack explicitly depends on it From a theoretical's perspective it immediately allows for adaptive security Which is only achievable in the MMR setting if the scheme has in it admits an additional security property Beyond message privacy, but I'm not going to get into this. I'll just refer you to the paper for the details We're able to show in the random oracle model again that RSA OAP is secure in this weak randomness setting This is useful because it's the only provably secure PKE scheme offered by virtually all common libraries In our paper we provide a full treatment of the RFC standard including labels which the standard specifies as being optional This is what's actually imprim implemented in real libraries, although not all APIs expose the labels So to summarize the MMR CCA attack is very strong since it admits adversaries that adaptively corrupt the randomness source during the course of their attack The strength of this attack led us to consider a weaker model where the coins are corrupted once before the adversaries attack begins We're able to show able to give the adversary the public key in this setting But the output of the coin source must have enough entropy so that the adversary can't simply guess them But this is still a weaker requirement than the usual setting which requires uniform coins So as you can see the burden on the system to provide high-quality randomness decreases as we move from IND CCA to MMCCA and finally to MMR CCA Intuition would suggest that weakening the requirements on the system results in a stronger notion But the nature of the attack is quite different in each of these settings Nevertheless, we find that we're able to work out relationships among these notions under certain restrictions Now to wrap up We find that existing HedgePKE schemes are difficult to implement using real crypto libraries Although these schemes are explicitly designed for practice In particular you can't implement encrypt with hash in OpenSSL without modifying the code in some way So in our work, we revisited the HedgePKE from the perspective of what is achievable using existing libraries Building off of prior work, we introduce a CCA extension to the usual MMR attack and show it's achievable by a hybrid encryption And our construction makes use of primitives exported by common libraries We also introduce the weaker MM attacks and show that MMCCA is achieved by RSA O A E P Finally, the principles that drive API design are inherently in conflict with one another API should be easy to use even for those who may know very little about what it is they're doing More to the point, they need to be difficult to use incorrectly, especially when they involve cryptography On the other hand, they need to be flexible enough to be used in new ways, ways not even envisioned by the designers This is especially important because APIs exist for a long time We hope that our work calls these issues to the attention of our community When developing new theory, it's a good idea to take a look at libraries and see what they're already doing And how they're designed Whenever possible, we should favor solutions that are supported by existing APIs Thank you very much