An Introduction to Indistinguishability Obfuscation

Special thanks to Sora Suegami for feedback and source material.

Indistinguishability obfuscation (iO) has been buzzing through Ethereum circles as a “holy grail” of cryptography, a crown once worn by ZK and FHE. The concept has a turbulent history, from early impossibility results to fragile breakthroughs to today’s “Diamond iO” benchmarks. At its core, iO is the simple idea that code can be made runnable but unreadable. Of course, it’s still wildly impractical. If it ever matures, iO could transform blockchains: powering private governance, confidential markets, and tamper-proof infrastructure. This blog post walks through the history, the benchmarks, and what iO might mean on-chain.

iO: A Book and a Maze

Imagine a world-class chef. Her genius lies not just in the dishes she makes, but in how she makes them: the subtle variations, the order of steps, the tricks that she’s refined over her lifetime. She wants you to be able to cook her food at home, but doesn’t want you to learn her secrets.

So she gives you a magic recipe book. You open it, follow the instructions step by step, and out comes a perfect replica of the signature dish. However, the recipe is written in magic ink. You’re able to follow the instructions and use her secrets to cook the meal as if you were the chef herself, but you never learn what the secret to making it her way actually was.

This highlights the obfuscation of iO: a cryptographic primitive that allows software to be published in a way that anyone can run it, but no one can reverse-engineer. Due to its power and what can be derived from it, iO is a “holy grail” of cryptography and web3: developers can publish obfuscated programs that users can interact with freely, that any node can run, but that yields no insight to the code that is actually being run, even if there are secret keys hidden in the code.

Now think of two mazes: one is a straight line from start to finish, the other is a labyrinth of twists and turns. Both mazes have the same entrance and the same exit. iO applies a magic fog to the mazes: you’re able to walk from start to finish, but you have no idea which maze you’ve traversed.

This is the indistinguishability trait of iO: two different programs that compute the same function become indistinguishable once obfuscated. If the entrance is your input and the exit is the output of the program, you will get to the correct output without being able to deduce anything meaningful from the intermediate steps.

The definition of iO: Given two different programs that computes the same function (in other words, both programs will give the same output for any input), once obfuscated, you can’t tell which program your obfuscation corresponds to. An obfuscator takes in a program and produces an obfuscated binary can then be run on any computer.

iO’s ideal functionality

iO unlocks a direct path to both privacy and verifiability: confidential auctions, private voting, or contracts can be naively built for correctness, and once obfuscated, be private as well. Any validator or node can run the program, but won’t be able to see the inner workings of it: no TEEs or special hardware needed.

The road to iO wasn’t straightforward. In 2001, a seminal paper — On the (Im)possibility of Obfuscating Programs — showed that perfect “black-box” obfuscation is impossible. Some mazes can never be fogged without leaking their structure. For a while after this paper was published, it seemed like the dream of meaningful obfuscation was dead.

In 2013 however, cryptographers introduced indistinguishability obfuscation (iO) — a weaker and far more nuanced approach. It didn’t try to fog all mazes; it only required that if two mazes have the same entrance and exit, then once obfuscated, they look the same.

The realization of iO’s usefulness in 2013 opened the floodgates. Even though early candidate constructions were impractical, iO revealed itself as a foundational primitive. Complex cryptographic systems can be built almost trivially by mixing iO with other primitives. In fact, several primitives themselves can be made from iO as well, and it has since been found that much of modern cryptography can be built from iO.

A Locksmith for Cryptography

Cryptography has equips defenders with a growing keyring of specialized tools, or cryptographic primitives. One key unlocks digital signatures, another zero-knowledge proofs, another multiparty computation, yet another functional encryption. Each key is tailored to its lock, and defenders must carefully choose and wield them against attackers.

iO brings a primitive that can act as a locksmith: much (although not all) of today’s cryptography can be made from iO. With iO and basic assumptions, much of modern cryptography can be derived: public key cryptography, signatures, NIZKs, functional encryption, attribute-based encryption, even FHE can be constructed from iO. If quick and efficient iO can be achieved, the hope is that anything that can be made from iO (such as FHE) would also be quick and efficient.

The use cases of different cryptographic primitives

A History

iO Exists (2000–2001)

At the turn of the millennium, researchers asked a natural question: could software be made unreadable yet runnable? In 2000, early work laid out formal definitions of what an “obfuscator” should achieve. However, in 2001, Barak, Goldwasser, Wigderson, and others reached a result which proved that virtual black-box (VBB) obfuscation is impossible. Certain programs, they showed, can never be obfuscated without leaking secrets. iO was defined as a by-product of the impossibility, but it wasn’t seen as powerful or interesting in its own right.

The impossibility result was a shock — and for more than a decade, obfuscation seemed like a dead end.

iO Winter (2001–2013)

After the impossibility result, the field went quiet. Program obfuscation was seen as a curiosity, not a research frontier. For twelve years, cryptographers pursued other directions: lattices, homomorphic encryption, multiparty computation. Obfuscation was dismissed as theoretically alluring, but fundamentally out of reach.

A New Hope (2013)

More than a decade after the impossibility result, Garg, Gentry, Sahai, and Waters introduced the first candidate construction of indistinguishability obfuscation (iO). Their breakthrough used a then-new algebraic tool called multilinear maps and a related primitive, functional encryption.

The key idea was to show an iO candidate construction from multilinear maps. The paper revived the field of program obfuscation after a decade of impossibility results and demonstrated that iO could be extremely powerful if efficiently realized.

iO Breakthroughs and Attacks (2013–202)

Indistinguishability obfuscation (iO) had leapt from dream to reality. Researchers quickly realized it was not just another primitive: it was a useful for almost all cryptographic constructs. From iO, one could construct almost everything: fully homomorphic encryption, zero-knowledge proofs, secure multiparty computation, even primitives once thought unrelated. For a time, iO looked like a single foundation stone upon which modern cryptography could be rebuilt.

But the excitement came with fragility. These first constructions relied on powerful but delicate new algebraic objects called multilinear maps. Between 2013 and 2017, a wave of attacks exposed cracks in these foundations. By the end of this era, the cryptographic community faced a paradox: iO was unimaginably powerful in theory, but its concrete instantiations were flawed.

The fragilities were uncovered and exploited. The first zeroing attacks were unveiled in 2014, breaking leading iO candidates. Other works catalogued the growing list of broken assumptions. The field had reached a crossroads: if iO was real, it could not rest on multilinear maps.

Broadly, the exotic assumptions that constructions were using were unreliable. Until iO could be built from standard cryptographic assumptions, it was clear that achieving robustness would be an additional hurdle to overcome. Researchers began searching for solid assumptions from which to build iO, which culminated in a breakthrough in 2020.

Towards Solid Ground (2020–Today)

A major breakthrough arrived in 2020, when Jain, Lin, and Sahai proposed the first iO construction from standard, broadly trusted assumptions: lattice problems (LWE), subgroup-based assumptions (SXDH), constant-depth pseudorandom generators, and learning with parity noise (LPN). This was the turning point: iO no longer lived only on shaky, uncertain assumptions.

In 2025, another milestone arrived: Diamond iO, which further streamlined the foundations by avoiding functional encryption bootstrapping. These advances remain far from practical — current iO schemes are astronomically inefficient. But now for the first time, cryptographers can seriously imagine iO built on bedrock, and can get a taste for the first obfuscated programs.

Important papers and achievements in iO

The iO Chasm: Why it’s not here today

The biggest (practical) bottleneck to cryptography is typically computational complexity. If an insecure computation, say a multiplication, takes one clock cycle to compute on a modern CPU, how many would it take to compute the same operation in FHE? In a TEE? Using ZK? Early FHE schemes used to take minutes to do these operations that a computer would do in nanoseconds. Now, advancements have brought this “minutes per operation” overhead to milliseconds per operation.

ZK proofs had a similar lifecycle: once it was proved that ZK proofs could be generated for any (NP) computation, the race was on to make the proving and verifying practical for a personal computer to perform. Proving still is a computationally intense task: a zkP2P proof can take on the order of 5 minutes to generate on a mobile device, but this kind of performance is good enough for on-chain nodes. Despite ZK still being too slow for consumer applications, it is good enough for on-chain use.

iO has two stages to benchmark: obfuscation and evaluation. Obfuscation takes in a program, which may include a secret like a cryptographic key, resulting in an executable that looks unintelligible but preserves the functionality of the program. Evaluation simply takes the obfuscated program and evaluates it on given inputs. The evaluation will leave the evaluator with the same result as the unobfuscated program, without allowing the evaluator to learn anything about how the original program was implemented.

The stages of obfuscation

In a 2022 paper, researchers from the Technical University of Munich set out to benchmark Garg et al.’s construction from 2013. Take a simple 2-bit multiplication circuit:

• Can multiply two numbers between 0 and 3
• 4 bits of inputs (2-bits per operand)
• 4 output bits
• 1–8 AND gates per output bit (4 to 32 gates total)

Any program that is used today can use upwards of billions to trillions of multiplications, all with 64-bit operands (not 2). The researchers found that to obfuscate the 2-bit gate above would take:

• 10²⁷ years to obfuscate (the universe has only existed for 10¹⁰, or ten billion years)
• 20 zettabytes (200 trillion gigabytes)
• 10⁸ years to evaluate (if the universe came with an obfuscated 2-bit multiplication gate built-in and we started evaluating multiplications at the beginning of the universe, we would have only performed 100 2-bit multiplications)

The Diamond iO Benchmark

One of the most promising benchmarks available for iO is that of Machina IO’s, benchmarking the Diamond iO construction. The results are both a win in bringing iO from theory to reality and a stark indicator of how much is still left to be done. While Diamond iO is able to obfuscate a watered-down multiplication circuit in less than a human lifetime (whereas the previous benchmark took more time than the universe has been around), obfuscating a full program would still take much more time than the universe has been around. The benchmark is a lower bound: a few alterations from the theoretical construction were made, including using a simpler FHE scheme and omitting the implementation of a hash function (which remains too complicated to implement).

The Diamond iO benchmark consists of a simple aggregator program: it performs additions and multiplications under encryption on an input and reveals the output. The multiplications are done under FHE encryption; the evaluator is able to perform the FHE encryption and decryption without learning the secret key. The multiplication circuit in this model is public: the obfuscation in this case is useful not to keep the operation secret, but to keep implementation details such as the secret key used private from the evaluator.

The cost of obfuscation. Creating an obfuscated program with Diamond iO is extremely expensive. Even a toy example that adds or multiplies a handful of times requires tens of minutes to hours of computation, consumes tens to hundreds of gigabytes of memory, and produces obfuscated binaries tens of gigabytes in size. This step is done once per program, but its scale illustrates why iO is currently impractical.

The cost of evaluation. Running the obfuscated program is also slow and resource-hungry compared to normal cryptographic tools. Evaluation times are measured in minutes, not milliseconds, and still demand tens or hundreds of gigabytes of RAM. For context, a zero-knowledge proof or a homomorphic encryption operation can often be carried out on commodity hardware in seconds or less, while the iO benchmark shows evaluation bottlenecks that are orders of magnitude slower.

The following tables compare the speed from Machina IO’s benchmarks to other private computations. As multiple constructions and benchmarks exist for FHE and ZK computations with varying tradeoffs in efficiency, we provide a general number in the table and give sources to FHE and ZK resources below.

Approximate execution speed for different cryptographic primitives

The first benchmark was measured by the number of multiplications done on the input: no multiplications, 5 multiplications, 10 multiplications.

If you think this is a very simple benchmark, it is. For comparison, here are some common on-chain cryptographic operations and their multiplicative depth.

On-Chain iO

Smart contracts running obfuscated circuits provide a new bounty of use cases. By being able to embed secrets on-chain, we achieve public functionalities with the following features:

• A trust model that is independent from trusted hardware (TEEs)
• The accountability of a public ledger in the use of secrets (who accesses the obfuscated functionality)
• The programmability of smart contracts (whitelists on who can use the functionality, etc)

In the case of encryption and decryption, a trusted setup can be performed in which a set of encryption and decryption keys are generated. The decryption keys can then be embedded in a program which is then obfuscated and put on-chain, and the encryption key can be given to relevant parties. Now, anyone who has the encryption keys can post encrypted values to the blockchain which can then be processed and decrypted by the obfuscated program/smart contract on demand. Implementation details such as the processing ciphertexts using secret keys can now be kept private from the public nodes running the computation.

The difference between this and a signature or commitment scheme is the ability to process the encrypted value: the encrypted values that are posted can be processed by the smart contract with only the output being revealed, with inputs and intermediate values remaining hidden.

In the context of a proof of reserve, this can be powerful: treasuries can post encrypted data corresponding to proof of reserves on-chain. This data cannot be read by anyone; it can only be used by the obfuscated program. Any node running the obfuscated program however, cannot see this encrypted data in the clear, even when running the obfuscated program: the node can only compute and decrypt the output. As long as treasuries post updated data, proofs of reserve would now be able to be computed on demand (anyone doubting the veracity of the data can request a proof that the encrypted data is correct).

Taking this a step further, this provides a model for oblivious on-chain state and advanced permissioned functionalities. Encrypted data can be posted on-chain, unreadable and unusable by anyone other than the obfuscated functionality: this functionality could be a proof of reserve, as in the case above, the computation of specific proofs, or even something as simple as reading the private on-chain balance of an address.

The secret embedded in a program need not be restricted to that of a secret encryption key. An on-chain program can have an API token embedded in it, which can then be used to generate API requests. As long as the secret token that proves the program’s identity cannot be copied or learned by any node running it, iO can give us a framework for privileged on-chain computation.

Standing at the Edge of the Maze

Indistinguishability obfuscation sits at a strange frontier: it exists, but only just. For cryptographers, it has already re-drawn the map of what is possible. For builders in blockchain and Web3, it dangles the promise of governance without coercion, markets without exploitation, bridges without betrayal. At the same time, it raises sharp new questions: what does verification mean when logic itself is hidden? How do we keep a dark forest from turning into a black box?

iO is not ready for production blockchains today. But it has shifted the Overton window: we now know that software can be made runnable yet unreadable. If history is any guide, the gap between theory and practice will narrow — perhaps suddenly, as it did for zero-knowledge proofs and homomorphic encryption. When it does, iO may prove not just a master key for cryptography, but a cornerstone for the next generation of decentralized systems.

Resources

iO

• On the Impossibility of Obfuscating Programs, Barak et al, 2001 https://www.iacr.org/archive/crypto2001/21390001.pdf
• Candidate Indistinguishability Obfuscation and Functional Encryption for all circuits, Garg et al, 2013 https://eprint.iacr.org/2013/451.pdf
• Cryptanalysis on the Multilinear Map over the Integers and its Related Problems, Cheon et al, 2014 https://eprint.iacr.org/2014/906.pdf
• Limits on the Power of Indistinguishability Obfuscation and Functional Encryption, Asharov, Segev, 2015 https://eprint.iacr.org/2015/341.pdf
• Implementing BP-Obfuscation Using Graph-Induced Encoding, Halevi, Halevi, Shoup, 2017 https://eprint.iacr.org/2017/104.pdf
• Indistinguishability Obfuscation without Multilinear Maps: New Paradigms via Low Degree Weak Pseudorandomness and Security Amplification, Ananth et al., 2019 https://eprint.iacr.org/2019/643.pdf
• iO: State of the Art https://sites.google.com/view/iostate-of-the-art/home
• Indistinguishability Obfuscation from Well-Founded Assumptions, Jain, Lin, and Sahai, 2020 https://eprint.iacr.org/2020/1003.pdf
• Idea: Benchmarking Indistinguishability Obfuscation — A candidate implementation, Banescu et al, 2022 https://mediatum.ub.tum.de/doc/1246288/1246288.pdf
• Diamond iO: A Straightforward Construction of Indistinguishability Obfuscation from Lattices, Suegami, Bottazzi, and Park, 2025 https://eprint.iacr.org/2025/236
• Hello, World: The First Signs of Practical iO, Suegami, Bottazzi, and Park, 2025 https://machina-io.com/posts/hello_world_first.html

ZK

• Evaluating the Efficiency of zk-SNARK, zk-STARK, and Bulletproof in Real-World Scenarios: A Benchmark Study, El-Hajj and Roelink, 2024 https://www.researchgate.net/publication/382138687_Evaluating_the_Efficiency_of_zk-SNARK_zk-STARK_and_Bulletproof_in_Real-World_Scenarios_A_Benchmark_Study
• Benchmarking ZK-Friendly Hash Functions and SNARK Proving Systems for EVM-compatible Blockchains, Guo et al, 2024 https://arxiv.org/pdf/2409.01976
• Benchmarking ZKP Development Frameworks https://ethresear.ch/t/benchmarking-zkp-development-frameworks-the-pantheon-of-zkp/14943
• ZKBench https://zkbench.dev/

FHE

• Making FHE Faster for ML: Beating our Previous Paper Benchmarks with Concrete ML, Zama https://www.zama.ai/post/making-fhe-faster-for-ml-beating-our-previous-paper-benchmarks-with-concrete-ml
• Cross-Platform Benchmarking of the FHE Libraries: Novel Insights into SEAL and OpenFHE, Faneela et al, 2025 https://eprint.iacr.org/2025/473.pdf
• FHEBench, Jaing and Ju, 2022 https://arxiv.org/pdf/2203.00728
• SEAL FHE https://github.com/microsoft/SEAL
• OpenFHE https://openfhe.org/
• HELib https://github.com/homenc/HElib
• Zama https://www.zama.ai/