# How does the random oracle model simplify proofs versus using the standard model?

If I use the standard model, then the proof must rely on mathematical assumptions.

Will this security proof, generally be longer/more complex?

Is there an example where the random oracle has been used to prove security, then removed to shows this?

• Does crypto.stackexchange.com/a/68298 help? So-called ‘standard model’ proofs—which are, in principle, just proofs of theorems like in that post, but with no $H$ parameter involved—are often much more difficult and complicated and serve for much less practical cryptosystems that essentially nobody uses in the real world. – Squeamish Ossifrage May 31 '19 at 22:25
• @SqueamishOssifrage yes it helps a lot. I assumed that we would first try our best to prove security in the standard model, even if the proof would be easier in the ROM. Maybe this is not the case and irrelevant for real-world applications? – WeCanBeFriends May 31 '19 at 22:36

Yes, there are examples where the random oracle model has been first used, then removed, Yes, the proof becomes, in the end, much (much) more complex. But in fact, simplicity of the proof is not the reason why we initially prove security in the ROM. The main reason is that we don't even know what security property our hash function must satisfy!

Intuitively, a random oracle models an idealized hash function that would satisfy all the security properties you can dream of. So, consider a protocol that uses a hash function $$H$$. It is often the case in cryptography that this protocol seems secure, in the sense that we do not know how to break it. However, to prove that it is secure, we need a security reduction: an efficient reduction from the existence of an adversary that breaks the protocol to the existence of an algorithm that contradicts some security property of our hash function.

But then the question becomes: which security property? Do we want $$k$$-wise independence? one-wayness? Collision-resistance? Multi-collision-resistance? Output intractability? Correlation intractability? Correlation robustness? Extractable collision resistance?

All the properties I list above are actually security properties of hash functions which have been used in security proofs of various cryptographic construction. But there are many more. Dozen of them, at least.

Because of the hardness of finding the right security notion, cryptographers usually like to argue security in the random oracle model. If you can do so, intuitively, this guarantees that we are likely to be able, someday, to prove the security of our protocol under some assumption about our hash function. If you fail, it might simply mean that your protocol is insecure - so that's a nice sanity check. Proofs in the ROM are usually very simple: the adversary sees nothing at all about the function, it's behavior is perfectly random, so you can just count the information accumulated by the adversary about the random oracle, and compute the exact probability that he finds some specific information. You have also access, in the proof, to all the queries made by the adversary to the oracle - and you can even manipulate the oracle if you like.

Is there an example where the random oracle has been used to prove security, then removed to shows this?

Many. Here are a few such examples:

• Oblivious transfer extension is a core cryptographic primitive in the area of secure computation, which allows to achieve much more efficient protocols by transforming a small number of "oblivious transfers" into a much larger number, using only a few hashes for each new oblivious transfer generated. An efficient OT extension protocol was first given in this paper. The security is proven in the ROM, but it can also be proven assuming that the hash function statisfies correlation robustness, a property which they introduce in the same paper.
• The free-XOR trick is a method to improve the efficiency of garbled circuits, also a core primitive in secure computation. It was first introduced here and proven secure in the ROM, and later proven secure in the standard model in this paper by replacing the hash by a special symmetric encryption secure against a certain type of related-key attacks.
• The Fiat-Shamir transform is, arguably, one of the most famous applications of the ROM. It allows to transform interactive zero-knowledge protocols into non-interactive zero-knowledge protocols. Proving security of non-interactive protocols obtained through the Fiat-Shamir heuristic has been a major open problem for more than 3 decades, one which attracted a lot of attention from the cryptographic community. The first results in this respect were mainly negative, proving the uninstantiability of the Fiat-Shamir transform in the standard model, for some class of protocols. However, things have changed recently: it has been shown that a large class of interactive protocol can be made non interactive with the Fiat-Shamir transform, if the hash function satisfies correlation intractability for an appropriate class of samplers. Then, hash functions satisfying correlation intractability for important class of samples have been constructed from various assumptions, culminating with a very recent construction of such hash functions from the LWE assumption, which finally solved the long standing open problem of constructing non-interactive zero-knowledge proofs from LWE.
• Other situations include building point function obfuscation with auxiliary inputs, or very strong forms of leakage resilient pseudorandom generators, both known in the ROM, but which were only recently obtained in a beautiful paper with a security analysis in the standard model.
• RSA-OAEP has been analyzed and proven IND-CPA secure in the standard model here, under the $$\phi$$-hiding assumption, and assuming that the underlying hash function was $$k$$-wise independent. It was previously only known to be secure under the RSA assumption when modeling the hash function as a random oracle.

This is just a sample of the things that come directly to my mind, there are many more.

• beautifully written – WeCanBeFriends Jun 4 '19 at 13:24