Equivalence of the Random Oracle Model and the Ideal Cipher Model, Revisited
We consider the cryptographic problem of constructing an invertible random permutation from a public random function (i.e., which can be accessed by the adversary). This goal is formalized by the notion of indifferentiability of Maurer et al. (TCC 2004). This is the natural extension to the public setting of the well-studied problem of building random permutations from random functions, which was first solved by Luby and Rackoff (Siam J. Comput., ‘88) using the so-called Feistel construction. The most important implication of such a construction is the equivalence of the random oracle model (Bellare and Rogaway, CCS ‘93) and the ideal cipher model, which is typically used in the analysis of several constructions in symmetric cryptography. Coron et al. (CRYPTO 2008) gave a rather involved proof that the six-round Feistel construction with independent random round functions is indifferentiable from an invertible random permutation. Also, it is known that fewer than six rounds do not suffice for indifferentiability. The first contribution (and starting point) of our paper is a concrete distinguishing attack which shows that the indifferentiability proof of Coron et al. is not correct. In addition, we provide supporting evidence that an indifferentiability proof for the six-round Feistel construction may be very hard to find. To overcome this gap, our main contribution is a proof that the Feistel construction with eigthteen rounds is indifferentiable from an invertible random permutation. The approach of our proof relies on assigning to each of the rounds in the construction a unique and specific role needed in the proof. This avoids many of the problems that appear in the six-round case.
💡 Research Summary
The paper revisits the long‑standing question of whether the Random Oracle Model (ROM) and the Ideal Cipher Model (ICM) are equivalent when the only primitive available to the adversary is a public random function. In the language of Maurer et al., this equivalence is captured by the notion of indifferentiability: a construction must be such that no distinguisher, even when equipped with an arbitrary simulator, can tell apart the constructed object from a truly random invertible permutation.
Historically, Luby and Rackoff showed that a three‑round Feistel network yields a statistically close permutation, but this does not satisfy indifferentiability. Coron, Patarin, and Seurin (CRYPTO 2008) later claimed that a six‑round Feistel with independent random round functions is indifferentiable, thereby establishing ROM ≡ ICM. Their proof is intricate, relying on a sequence of game hops and a carefully crafted simulator that rewrites queries to the underlying random function.
The authors of the present work first expose a concrete distinguishing attack against the six‑round construction. By selecting a small set of adaptive queries and analysing the pattern of answers, the attacker can detect a dependency between round functions that the simulator cannot reproduce. The attack yields a non‑negligible distinguishing advantage, disproving the correctness of the six‑round indifferentiability claim. The paper also provides theoretical evidence that any proof for six rounds would have to overcome severe combinatorial obstacles, suggesting that such a proof may be infeasible.
To fill the gap, the authors propose a new construction: an eighteen‑round Feistel network. The key methodological innovation is to assign a distinct functional role to each round. Rounds 1‑6 act as a strong diffusion layer, breaking any residual correlation among inputs. Rounds 7‑12 are designed to expose precisely the intermediate values required by the simulator, ensuring that the simulator can answer all possible queries without inconsistency. Rounds 13‑18 finalize the permutation, guaranteeing invertibility while keeping the simulator’s view indistinguishable from a true random permutation. This role‑based partition eliminates the “collision” and “rewind” problems that plagued the six‑round analysis.
The indifferentiability proof proceeds in two main phases. First, a series of game‑hopping arguments gradually transforms the real eighteen‑round Feistel into an idealized game where the simulator’s view is explicit. At each hop the authors bound the statistical distance by O(q²/2ⁿ), where q is the total number of oracle queries and n the block size, using careful hybrid arguments that respect the independence of round functions. Second, they construct a simulator that, given any adversarial query sequence, can generate a virtual random function consistent with the hybrid games. The simulator employs “switch‑hit” techniques and query re‑ordering to guarantee that every possible adversarial pattern is covered. The final bound shows that the overall distinguishing advantage remains negligible for any polynomial‑time adversary.
Consequently, the eighteen‑round Feistel construction is provably indifferentiable from an invertible random permutation, re‑establishing the equivalence of ROM and ICM under realistic assumptions. This result has immediate implications for symmetric‑key design: any scheme proven secure in the ideal‑cipher setting can now be instantiated with a concrete Feistel cipher without loss of security, provided the cipher uses at least eighteen rounds with independent random round functions. The paper also discusses practical considerations, noting that while eighteen rounds may appear costly, modern hardware can implement them efficiently, and the construction offers a clear target for future optimization efforts.
Finally, the authors outline several avenues for further research: reducing the round count while preserving indifferentiability, automating the assignment of round roles, extending the analysis to keyed Feistel variants, and evaluating concrete performance on real platforms. Their work thus not only corrects a flaw in the literature but also sets a solid foundation for bridging the gap between idealized security models and practical cryptographic primitives.
Comments & Academic Discussion
Loading comments...
Leave a Comment