 My name is Hannah Davis, and today I'm going to talk about domain separation. This is joint work with Mihir Bellare and Felix Schoenter. Design and security proofs of many practical schemes, including the CHEMS in the NIST PQC effort, use the random oracle model. Recall that here, scheme algorithms, as well as the adversary, are given oracle access to the random oracle H. This oracle is a function drawn at random from some space, parties can query X and get back H of X. When it comes time to implement the scheme, the random oracle is built from some cryptographic hash function. In the most basic version of the model, shown on the prior slide, there's only one random oracle. In the design of schemes, however, it is often convenient to assume access to multiple independent random oracles. Parties can query an index I and a string X and get back each I of X, the result of the Ith random oracle on input X. The proof of security would be in this setting, meaning it would assume the different random oracles are independently random. In the end, however, we want to be back in the setting with a single RO so that our implementation can use just one cryptographic hash function. So we get the problem of going from many random oracles to one. We formalize it as the task of designing what we call a cloning functor, here denoted F. Its job is to specify H1, H2, and so on as functions of H. That is, the scheme using just one ROH is formed by taking the scheme using multiple random oracles and replacing HI with F of I and so on. Note that while scheme algorithms now access F and not H directly, we give the adversary access to H according to the random oracle model. Of course, the functor has to work, meaning that the scheme using a single random oracle should be secure, assuming that the one using multiple random oracles was secure. Depending on the choice of F, this may or may not be true. In practice and in the NIST submissions, oracle cloning is done in ad hoc ways. Some schemes say how they do it, meaning they specify the cloning functor in their specification document. In others, it is implicitly defined by the implementation. At this point, we can abstract out the cloning functor independent of its usage. It's an algorithm that takes inputs I and X and has access to a single random oracle, H. The desired property is that the functions F1, F2, and so on behave like independent random oracles in the sense I described earlier, meaning any schemes secure with such independent random oracles remain secure when they are implemented via F. We'll give a more formal definition later. We call oracle cloning the task of designing a cloning functor that is good or works in this sense. Of course, there are already well-known ways of building many random oracles from one. The obvious and common one is domain separation. Here, the ith random oracle is defined on input X to prefix X with some representation of Y and then call H to get the result. In our terminology, the cloning functor F is defined as shown in the yellow box. The notation here is that F bracket H bracket means F has oracle access to H. Our understanding has been and is that domain separation works and this F is a good cloning functor. The claim may not perhaps have been formally or explicitly validated. For that, one has to ask precisely what is the target definition and have some proof. People may, however, say that this is overly pedantic. It seems obvious domain separation works. We'd be inclined to agree. But some events lead us to think that oracle cloning does need a more careful and complete treatment. We looked at submissions to the NIST post-quantum cryptography standardization effort that we're building key encapsulation mechanisms. They were using multiple ROs and then explicitly or implicitly implementing them via a cloning functor. We found two things. First, some cloning methods were wrong to the point where we were able to give a tax parking the schemes. Second, there were choices of cloning functors made and used that were different from domain separation. We decided to step back to consider the problem theoretically, giving definitions and proofs and then coming back to classify and when possible, validate oracle cloning methods in the submissions. In brief, having highlighted oracle cloning as a problem, we contribute in two ways. The first is a case study of oracle cloning in the NIST PQC key encapsulation schemes that motivates some theory. And the second is such theory to treat oracle cloning that we then bring back the bear on the cams. We analyze the NIST schemes and their oracle cloning methods and we classify them into three broad categories, schemes that we can attack due to flaws in their oracle cloning, schemes that use methods or theories can validate and others that are something in between. On the theoretical side, we started by seeking a standalone definition of what it means for a cloning functor to be good and converge on a variant of indifferentiability that we call read-only indifferentiability so that indifferentiability composition theorems can be used to conclude that a functor, meaning our definition, preserves security of all usages in which it maps multiple random oracles to a single one. From the ways in which different NIST cams performed oracle cloning, we abstract out cloning functors and can now ask whether or not they meet our definition. We show that many do, which then maps back to validate the corresponding cams. I will now go into more detail on the two lines of contributions, practical and theoretical, starting with the former. The NIST post-quantum cryptography standardization process is an ongoing effort to select cryptographic algorithms for standardization that are resilient against quantum attackers. Back in 2017, cryptographers submitted 69 candidates of which 37 targeted key encapsulation as a goal. After a year of scrutiny and discussion, 26 finalists advanced to round two. 17 of these finalists contain at least one key encapsulation algorithm. Recall the definition of a key encapsulation mechanism here called KE. It has an encapsulation algorithm called ke.ank which takes a public key pk and outputs a session key k and a ciphertext encrypting that key. The algorithm is randomized and recall that there is no message input to a cam. The decapsulation algorithm, ke.ank, given the secret key sk and the ciphertext will recover the session key. With regard to security, an adversary given the public key and ciphertext should not be able to quickly recover the session key or even part of it. It should not, in fact, even be able to distinguish it from random even under a chosen ciphertext attack. As we will see, our attacks violate even the first weaker security property while our proofs guarantee the second stronger one. Many of the NIST PQC chems employ the following three step design process. First, step one, they design a public key encryption scheme that we call PKE. The intent is that it satisfies some relatively weak security property but it does this even in the face of quantum attackers. None of this will matter for us. We'll just take PKE as a given. Next, in step two, PKE is turned into a chem by the application of a generic transform. This transform and the constructed chem uses multiple here up to three, independent random oracles. We name them H2, H3 and H4 because we reserve H1 for possible use by PKE. The transforms are based on ones given and validated in the literature. They're not always identical to the ones in the literature but we assume they work in the sense that PKE is secure in this setting. It's important to remember that this means under the assumption that H2, H3 and H4 are independent random oracles. Finally, in step three, the many ROs are implemented via a single one, H, through some cloning functor F to get the final chem. This chem uses a single random oracle. Our question is whether this final chem is secure assuming that the step two one was secure. In other words, we're asking whether the cloning functor was designed well in a way that preserves security from step two to step three. In order to study and answer this, we will have to open up step two a bit and look at the structure of the chems produced by the transforms. They are usually presented as using transforms given improved in the literature but in fact, they modify or embellish them in many little ways. And as a kind of orthogonal contribution, we have a framework to unify and visualize these variations. Here we show a step two encapsulation algorithm. We omit the encapsulation since it won't affect our analysis. The chem uses three assumed independent random oracles, H2, H3, and H4. At a high level, first we choose a random seed M of a length equal to the message length of the PKE scheme. We encrypt M under PKE using random coins R derived using a random oracle H2 applied to a quantity we call X. X differs across transforms and so it is a variable parameter in our framework. We'll have other parameters Y, Z, D, and K star and choice of all these parameters yields a particular transform. The chem ciphertext C star is C together with the parameter Y. Well, the session key K is the result of applying H4 to the parameter Z. H3 could be used in determining the parameters as a function of other quantities. The Boolean variable D is usually true so we'll assume that here. The table shows on what the parameters may depend. Table shows how to capture the NIST transforms in our framework. Each row corresponds to some choice of our parameters X, Y, Z, D, and K star. The details do not matter too much to our work but at a high level we can see that parameters X and Z which are used to derive random coins and the session key respectively vary the most between transforms. Moving forward, we stress that to the best of our knowledge all of these chems are secure in the current setting which is that the random oracles H2, H3, and H4 are independent of one another. The interesting thing is what happens when we try to implement them all with a single random oracle. We'll now illustrate one of our attacks. DAX is around one chem submission. The variant of the transform it uses meaning the way in which it sets the parameters X, Y, Z, et cetera, results in the chem looking as shown here. Suit the code on the right and picture on the left. Here the input to all random oracles ends up being M with the output used in different ways. This is not a problem. I emphasize again that this chem is secure when H2, H3, and H4 are independent random oracles. But now DAX builds H2, H3, and H4 from a single random oracle H using this cloning function. The consequence is that the session key K which equals H4 of M partially collides with the fragment Y of the ciphertext which equals H3 of M. Now an adversary given the public key and ciphertext can obtain Y from the latter and thus can obtain a fragment of the session key resulting in partial key recovery of 192 bits of the 512 bit key. Our DAX on the schemes big quake and round two exploit similar correlations between the output of H2 and H3 and they recover the full key. Next, I'll present an overview of the classification of the NIST schemes as per our analysis of their oracle cloning methods. We divided them into three classes. The first is the class of schemes on which we found a tax arising from poor choices of cloning functors. In this class are DAX, big quake and round two. All of our attacks are very fast and the attacks on big quake and round two achieve full key recovery. I want to stress that these are all round one submissions meaning that at the time our attacks were released they were no longer being considered for standardization. However, all three of these schemes were studied for at least a year without these attacks being noticed despite their simplicity. This suggests that there is a gap in our analysis process where we overlook cloning functors as a potential source of vulnerability. Next is a larger group of submissions that have what we call brittle security. These schemes use good cloning functors in their implementations and as a result we can prove their security in the single random oracle model. This gives us good reason to believe that the implementations of these designs are secure. Many of the NIST CAMS have a reference implementation and a separate optimized implementation of the same scheme. Whichever algorithm becomes standardized will likely be implemented many more times in various languages and cryptographic libraries sometimes by developers with very little cryptographic experience. We call the schemes in this group brittle because there's reason to fear that these future implementations will perform oracle cloning incorrectly. Some of these schemes define poor oracle cloning methods in their specifications even though the reference implementations use good methods. Other specifications in this group ignore oracle cloning entirely. To improve clarity and prevent bugs in future implementations, we would recommend that these schemes update their specifications to reflect the oracle cloning choices from their own reference implementations. The final group of schemes shows cloning functors that are good and specified these explicitly both in their document specifications and the reference implementations. Some of these use multiple hash functions to implement multiple ROs. Others analyze the oracle cloning step as part of their security proof. Or they explicitly stated that security was dependent on good domain separation. The HQC and RQC CAMS warned of a potential attack on their schemes if a particular bad cloning functor was used. Our theory can validate their choices via proofs. The NIST CAMS demonstrate that it is important to use good cloning functors. In the second part of this talk, we'll discuss exactly what that means and give some examples of good all-purpose functors to use in future designs. We'd like to prove that certain cloning functors are good. The first and very basic question then is what does good mean? What property X do we want a cloning functor to satisfy in order to call it good? The desired attribute of the cloning functor is that it works to replace multiple random oracles by a single one. That is, take any scheme, not just a CAM, but any cryptographic scheme for any goal that uses multiple random oracles and assume it is secure in that setting. Then replace the multiple random oracles with F. We want that this scheme, which uses a single random oracle, is also secure for the same goal. The question is what choice of property X for F yields this? There is an obvious answer, namely, indifferentiability. Here, the ideal object is the sequence of random oracles H1, H2, H3, and the primitive from which they are built is H. Recall that indifferentiability comes with a composition theorem, which would imply that in this case, the replacement we want works. The composition theorem for the original indifferentiability definition holds only for primitives whose security is defined by single stage games. This is enough to cover CAM security, but we want good cloning functors to work well regardless of the security definition our scheme is trying to meet. To accomplish this, we need a stronger definition. Reset indifferentiability is defined to solve exactly this problem. It has a composition theorem that works for both single and multi-stage security games. Unfortunately, reset indifferentiability is too strong for our application. Classical domain separation, which we already know works well, is not a reset indifferentiable construction. This means that we can't use the multi-stage composition theorem to prove security for any design that uses domain separation. To cover all security definitions and all of the established Oracle cloning techniques, we'll create our own indifferentiability definition, read only indifferentiability. Read only indifferentiability, which we'll describe in more detail in a couple of slides, is a midway point between basic and reset indifferentiability, and it exactly achieves our goal. On the one hand, it has a multi-stage composition theorem, which means that we can guarantee any type of security by using a good cloning filter. On the other hand, read only indifferentiability is a weaker notion than reset indifferentiability, which means that we cover a broader set of constructions, including domain separation and all of the other good cloning filters used by the NIST PQC chems. This means that we can use read only indifferentiability to validate all of the NIST PQC chems in groups two and three, as well as many other cryptographic designs. In the basic indifferentiability framework, our adversary is given access to an interface with two oracles. There are two worlds, the real world and the ideal world, and the adversary must determine which world it is interacting with. In the real world, the left oracle is our functor F, and the right is a random oracle H. The cloning functor's job is to replace multiple independent random oracles, so in the ideal world, this is exactly what we get as our left oracle. Since the adversary needs to have the same interface in both worlds, we need something in the ideal world to take the place of the random oracle H. This something is a simulator, which gets access to the random oracles H1, H2, and H3, so it can maintain consistency with their outputs. Each indifferentiability definition places different restrictions on the statefulness of the simulator. In read only indifferentiability, we allow our simulator to write to its own state buffer just once before it can access the random oracles. Once the state buffer is initialized, it can't be changed for the rest of the game. The ability to use read only state makes our simulators strictly stronger than stateless simulators, but the state is independent of the adversary's queries since it is fixed before the first query A makes to the evaluation algorithm S.ev. This is enough to give us a multi-stage composition theorem. The second novel piece of read only indifferentiability is the working domain, which introduces a new restriction on the queries adversary can make to its left oracle. Without working domains, read only indifferentiability implies basic indifferentiability, and it is a consequence of reset indifferentiability. With working domains, we can no longer compare these definitions. So why use working domains? Well, one quite common oracle cloning method that is used by several of the NIST PQC chems is safe to use on a restricted domain, but it breaks down trivially when the restrictions are removed. Schemes can use this method by enforcing the domain restriction on their own algorithms random oracle queries, and this works. Working domains let us capture this type of oracle cloning in the same framework as the other methods. Now that we have the read only indifferentiability framework in place, we can finally evaluate the cloning functors used by the NIST chems. There are three classes of functors that work well, and we prove read only indifferentiability for each of these. The prefixing method is a generalization of domain separation. The strings used as prefixes can be integers, names, descriptors, or code words from a prefix free encoding. Suffixing works analogously. When a string X is queried to the random oracle HI, the output splitting oracle returns the ith slice of H of X. We assume that the random oracles H1, H2, and H3 have the same output length L, but the method also works for any fixed lengths. This method is often used in combination with an extendable output function. The identity cloning functor simply drops the index of all of its queries and forwards them to its random oracle H. This clearly fails to be indifferentiable if an adversary can query two oracles, say H1 and H2, on a single string X. This is where working domains become useful. Many implementations written in low level languages like C fix the input length of every hash function call. If fixed input lengths mean that no two random oracles are ever queried on strings of the same length, then the identity functor intuitively works. We accordingly prove that the identity functor is read-only indifferentiable on certain restricted working domains. Given our toolbox of read-only indifferentiable cloning functors, it's easy to secure the construction of many random oracles from one. A good example of this process in action is the round two chem scheme, New Hope. We showed in our paper that New Hope used cloning functors that were not indifferentiable, meaning we could not guarantee New Hope's security in the single random oracle model. This doesn't mean that New Hope wasn't secure, just that further analysis was needed to give a proof in the single random oracle model. In response to our results, New Hope changed their scheme to include domain separation in every random oracle call. Thanks to our composition theorem, this updated version of New Hope is provably secure when using one random oracle without the need to write any new proofs. In summary, oracle cloning has always been part of the design of cryptographic schemes. There are known ways to do it well, like domain separation. As with any part of the design process, though, bugs will happen in oracle cloning, and sometimes these bugs lead to attacks. Because attacks that exploit poor oracle cloning fall outside the multiple random oracle model, they can be easy to miss. We found a few of these attacks on NIST PQC chems. Then we developed the read only in differentiability framework, which captures oracle cloning as a security goal and uses it to validate some of the known good methods of oracle cloning. If a scheme uses a read only in differentiable cloning functor, like prefixing or output splitting, and it is secure when using multiple independent random oracles, then it is also secure, according to our multi-stage composition theorem, in the single random oracle model. So please, separate your domains. Thank you very much.