It is convenient and common for schemes in the random oracle model to assume access to multiple random oracles (ROs), leaving to implementations the task -we call it oracle cloning-of constructing them from a single RO. The first part of the paper is a case study of oracle cloning in KEM submissions to the NIST Post-Quantum Cryptography standardization process. We give key-recovery attacks on some submissions arising from mistakes in oracle cloning, and find other submissions using oracle

more »

... g methods whose validity is unclear. Motivated by this, the second part of the paper gives a theoretical treatment of oracle cloning. We give a definition of what is an "oracle cloning method" and what it means for such a method to "work," in a framework we call readonly indifferentiability, a simple variant of classical indifferentiability that yields security not only for usage in single-stage games but also in multistage ones. We formalize domain separation, and specify and study many oracle cloning methods, including common domain-separating ones, giving some general results to justify (prove read-only indifferentiability of) certain classes of methods. We are not only able to validate the oracle cloning methods used in many of the unbroken NIST PQC KEMs, but also able to specify and validate oracle cloning methods that may be useful beyond that. NIST PQC KEMs. In late 2016, NIST put out a call for post-quantum cryptographic algorithms [35] . In the first round they received 28 submissions targeting IND-CCA-secure KEMs, of which 17 remain in the second round [37]. Recall that in a KEM (Key Encapsulation Mechanism) KE, the encapsulation algorithm KE.E takes the public key pk (but no message) to return a symmetric key K and a ciphertext C * encapsulating it, (C * , K) ←$ KE.E(pk). Given an IND-CCA KEM, one can easily build an IND-CCA PKE scheme by hybrid encryption [18] , explaining the focus of standardization on the KEMs. Most of the KEM submissions (23 in the first round, 15 in the second round) are constructed from a weak (OW-CPA, IND-CPA, ...) PKE scheme using either a method from Hofheinz, Hövelmanns and Kiltz (HHK) [24] or a related method from [21, 40, 27]. This results in a KEM KE 4 , the subscript to indicate that it uses up to four ROs that we'll denote H 1 , H 2 , H 3 , H 4 . Results of [24, 21, 40, 27] imply that KE 4 is provably IND-CCA, assuming the ROs H 1 , H 2 , H 3 , H 4 are independent. Next, the step of interest for us, the oracle cloning: they build the multiple random oracles via a single RO H , replacing H i with an oracle F[H ](i, ·), where we refer to the construction F as a "cloning functor," and F[H ] means that F gets oracle access to H . This turns KE 4 into a KEM KE 1 that uses only a single RO H , allowing an implementation to instantiate the latter with a single NISTrecommended primitive like SHA3-512 or SHAKE256 [36]. (In some cases, KE 1 NIST PQC KEMs, Oracle Cloning and Read-Only Indifferentiability 3 uses a number of ROs that is more than one but less than the number used by KE 4 , which is still oracle cloning, but we'll ignore this for now.) Often the oracle cloning method (cloning functor) is not specified in the submission document; we obtained it from the reference implementation. Our concern is the security of this method and the security of the final, single-ROusing KEM KE 1 . (As above we assume the starting KE 4 is secure if its four ROs are independent.) Oracle cloning in submissions. We surveyed the relevant (first-and secondround) NIST PQC KEM submissions, looking in particular at the reference code, to determine what choices of cloning functor F was made, and how it impacted security of KE 1 . Based on our findings, we classify the submissions into groups as follows. First is a group of successfully attacked submissions. We discover and specify attacks, enabled through erroneous RO cloning, on three (first-round) submissions: BIG QUAKE [8], DAGS [7] and Round2 [22] . (Throughout the paper, firstround submissions are in gray, second-round submissions in bold.) Our attacks on BIG QUAKE and Round2 recover the symmetric key K from the ciphertext C * and public key. Our attack on DAGS succeeds in partial key recovery, recovering 192 bits of the symmetric key. These attacks are very fast, taking at most about the same time as taken by the (secret-key equipped, prescribed) decryption algorithm to recover the key. None of our attacks needs access to a decryption oracle, meaning we violate much more than IND-CCA. Next is submissions with questionable oracle cloning. We put just one in this group, namely NewHope [2]. Here we do not have proof of security in the ROM for the final instantiated scheme KE 1 . We do show that the cloning methods used here do not achieve our formal notion of rd-indiff security, but this does not result in an attack on KE 1 , so we do not have a practical attack either. We recommend changes in the cloning methods that permit proofs. Next is a group of ten submissions that use ad-hoc oracle cloning methodsas opposed, say, to conventional domain separation as per Equation (1) -but for which our results (to be discussed below) are able to prove security of the final single-RO scheme. In this group are BIKE [3], KCL [44], LAC [28], Lizard [16], LOCKER [4], Odd Manhattan [38], ROLLO-II [30], Round5 [6], SABER [19] and Titanium [43]. Still, the security of these oracle cloning methods remains brittle and prone to vulnerabilities under slight changes. A final group of twelve submissions did well, employing something like Equation (1). In particular our results can prove these methods secure. In this group are Classic McEliece [13], CRYSTALS-Kyber [5], EMBLEM [41], FrodoKEM [34], HQC [32], LIMA [42], NTRU-HRSS-KEM [25], NTRU Prime [14], NTS-KEM [1], RQC [31], SIKE [26] and ThreeBears [23]. This classification omits 14 KEM schemes that do not fit the above framework. (For example they do not target IND-CCA KEMs, do not use HHK-style transforms, or do not use multiple random oracles.) Lessons and response. We see that oracle cloning is error-prone, and that it is sometimes done in ad-hoc ways whose validity is not clear. We suggest that