Black Hat Asia 2026 (Singapore, Apr 23–24) — Briefings Deep Dives

CLOAQ: Ensuring the Cloud Quantum Computer Runs Your Program, But Learns Nothing

Talk 31 · Quantum computing security · analysis from the speaker's published deck

Sep 24, 2026 · conferences · 10 min read · 2037 words intermediate

CLOAQ — hide a quantum circuit's secrets, unlock them with plain classical logic.

conferences blackhat quantum-computing cryptography intellectual-property

Official recording, Black Hat YouTube channel · open on YouTube ↗

Amal Raj and Vivek Balachandran (Singapore Institute of Technology) tackle a problem specific to quantum computing's current era: if you write a proprietary quantum algorithm but need a third-party compiler to make it run on real, noisy hardware, how do you stop that compiler from reading your intellectual property? Their answer, quantum circuit obfuscation with a purely classical key: scramble the circuit's output by inserting extra quantum gates before compilation, send the scrambled circuit to the untrusted compiler and quantum hardware, then undo the scrambling with simple classical bit-flip logic after the results come back, no second quantum circuit, no barriers, no physical-to-virtual qubit-mapping bookkeeping. Tested across five standard quantum algorithms, the technique achieved a median statistical divergence above 0.5 and consistently negative functional-correctness scores, both signs of effective obfuscation, while the correction step remains lightweight enough to run on an ordinary laptop.

Post 31 of my Black Hat Asia 2026 series. This is defensive intellectual-property research, not an attack technique, so unlike several other entries in this series I can walk through the full method in detail.

1. Why quantum circuits need obfuscation at all

Today's quantum hardware lives in what's called the NISQ era (Noisy Intermediate-Scale Quantum): machines with limited qubit counts, significant noise, and a restricted set of native operations. Getting a theoretical quantum algorithm to actually run well on a specific chip requires a compiler, a tool that translates the abstract circuit into the hardware's native gate set and maps its logical qubits onto the chip's physical qubits, all while trying to minimise the errors that accumulate from extra gates. Several vendors (IBM's Qiskit, Quantinuum's t|ket⟩, Rigetti's Quilc) offer these compilers, often as cloud services.

That's convenient, but it means a company developing a valuable proprietary algorithm, for chemistry simulation, optimisation, or cryptanalysis, has to hand its actual circuit design to a third party to get it compiled and run. As quantum computing becomes commercially significant, that circuit is exactly the kind of intellectual property a competitor or an untrusted service provider would want to see. The researchers want a way to protect it without giving up the third-party compiler's optimisation benefits.

1a. The minimum quantum background needed

A qubit can exist in a superposition of the two classical states, described by two complex numbers (amplitudes) whose squared magnitudes give the probability of measuring a 0 or a 1. Quantum gates are reversible operations on qubits: some (like Pauli-X) flip a qubit's basis state the way a classical NOT does; some (like Pauli-Z, or the S/T phase gates) only change the qubit's phase, a property invisible once you measure; some (like Hadamard) create superposition itself; and two-qubit gates like CNOT can entangle qubits together. Measurement is the one-way step that collapses a qubit's superposition into an ordinary classical bit, 0 or 1, with probability set by the amplitudes just before measurement.

2. Why earlier obfuscation approaches were clunky

Prior techniques generally fell into two camps, both with real downsides:

  • Quantum-reversal approaches: insert a random circuit (or dummy gates) into the original, then compile and run a separately-computed inverse circuit to undo it. This works, but needs access to a personal quantum compiler or computer to prepare that inverse, needs barriers in the circuit to stop the untrusted compiler from optimising across (and potentially removing) the inserted gates, and those very barriers can tip off an attacker that something was inserted there. It's also fragile if the same or a related compiler sees both the obfuscated circuit and its inverse.
  • Logic-locking approaches: borrow a hardware-security idea, encode a secret key into extra "ancilla" control qubits so the circuit only behaves correctly if the key is present. Effective in principle, but adds circuit complexity and crosstalk, a real problem on noisy NISQ hardware where every extra gate and qubit degrades fidelity, and some variants only work for circuits that already contain particular gate types.

The common thread: earlier methods try to quantum-mechanically undo the obfuscation, which is expensive, constrained, and sometimes detectable by its own scaffolding (the barriers).

3. The core idea: obfuscate quantumly, decrypt classically

The insight the authors build on is a set of well-known facts about how quantum gates interact with measurement:

  • Phase-only gates vanish at measurement. A gate that only changes a qubit's phase (S, T, Z and similar) has zero effect on the probabilities you actually observe when you measure. It's as if the gate was never applied, from the measurement's point of view.
  • State-flipping gates produce a predictable, classical bit flip. A gate like Pauli-X (and its controlled variants, which flip conditionally on other qubits) changes what bit value comes out in a way that's fully determined and easy to reverse with ordinary classical logic once you know which gate was applied to which qubit(s).
  • Combination gates (like Pauli-Y) just combine both effects, and can be corrected the same way.

The one deliberate exclusion is Hadamard gates (and controlled variants): because they introduce superposition itself, their effect on the final measurement distribution can't be undone with simple classical post-processing, so they're left out of the obfuscation gate pool entirely.

Original circuitproprietary + encryptor gatesphase/state-changing only Untrusted compiler + QPUsees only obfuscated circuit Classical bit-flip correction (the key) The compiler never learns which gates were added or where

Fig. 1 — Obfuscate with quantum gates, decrypt with a classical key. No second quantum circuit, no barriers.

The method, concretely:

  1. Choose an encryption gate pool (any of Pauli-X/Y/Z, controlled versions, phase gates, excluding Hadamard), and assign each a short numeric index.
  2. Insert chosen gates onto chosen qubits at the end of the original circuit, either manually or randomly for stronger security. This is the "encryption layer."
  3. Record the key: for every inserted gate, its index and which qubit(s) it touched, in the order added. Decryption later applies corrections in reverse order (last inserted, first corrected), a simple stack.
  4. Send the obfuscated circuit to the untrusted compiler and quantum hardware as normal, and collect the (now corrupted) measurement results.
  5. Classically correct the output: for each recorded gate, apply its known classical equivalent (identity for phase gates, a bit flip or conditional bit flip for state-changing gates) to the measured bitstrings, walking the key in reverse.

Because correction is just applying a short, deterministic sequence of classical bit operations to the returned bitstrings, no quantum computation is needed to decrypt, it runs instantly on an ordinary computer, and there's no separate inverse circuit or barrier for an attacker to notice.

4. Worked example: QAOA for MaxCut

The authors demonstrate the method on a QAOA (Quantum Approximate Optimization Algorithm) circuit solving a MaxCut graph-partitioning problem. Before obfuscation, running the circuit many times produces a histogram of measured bitstrings with clear peaks corresponding to the optimal graph partitions. After inserting a handful of extra gates (a mix of swap-like, phase, and controlled bit-flip operations) and recording their indices and target qubits as the key, running the same circuit produces a histogram whose peaks now correspond to entirely different, meaningless bitstrings, the functionality is genuinely hidden from anyone who only sees the obfuscated circuit and its raw output. Applying the recorded key's classical corrections, in reverse insertion order, to those corrupted results restores the original histogram's peaks exactly. The output is functionally recovered without ever running a second quantum circuit.

5. How obfuscation quality is measured

The paper uses two statistical metrics, both computed by comparing the obfuscated circuit's measurement distribution against the original's:

  • Total Variation Distance (TVD): how different the two output probability distributions are, ranging from 0 (identical, meaning obfuscation had no effect) to 1 (maximally different). Higher is better for obfuscation strength.
  • Degree of Functional Corruption (DFC): compares how often the correct answer appears versus the most common incorrect answer, ranging from 1 (obfuscation had no effect, correct answer always appears) to -1 (obfuscation is total, correct answer never appears, or an incorrect answer dominates). Lower is better for obfuscation strength.

6. Evaluation results

The method was tested in simulation (a noise-free Qiskit simulator, so results isolate the effect of obfuscation from hardware noise) across five standard algorithms spanning very different application domains: Shor's (factoring), QAOA (combinatorial optimisation), Bernstein-Vazirani, Grover's (search), and HHL (linear systems), with circuit sizes from 4 to 10 qubits, each run 100 times at 1,024 measurement shots per run, using a single shared, randomly-applied gate pool across every algorithm rather than anything algorithm-specific.

AlgorithmMedian TVDMedian DFC
Shor's0.5381-0.2583
QAOA0.7817-0.1123
Bernstein-Vazirani1.0-1.0
Grover's0.9097-0.8169
HHL0.8047-0.5522

Every algorithm's median TVD sits above 0.5 (statistically significant divergence from the original output) and every median DFC is negative (the obfuscated circuit's correct-answer rate is consistently beaten by some incorrect answer), confirming both statistical and functional obfuscation across a genuinely diverse set of algorithms, using nothing more than a generic, shared gate pool rather than anything tuned per algorithm. Bernstein-Vazirani hit the theoretical maximum on both metrics, complete obfuscation.

7. Limitations and future work

The authors are candid about two constraints:

  • Random gate selection isn't optimal. Choosing insertion gates based on the specific gate types and structure already present in the target circuit, rather than uniformly at random from a shared pool, is likely to push TVD and DFC scores even higher; they flag this as future work.
  • Single measurement basis only. The current classical-correction approach assumes the circuit measures in one basis per execution. Some variational algorithms need simultaneous or repeated measurement across multiple bases (for Hamiltonians made of mixed Pauli terms), and extending clean classical correction to that case isn't solved yet.

Neither limitation undermines the core result; they mark where the next iteration of the technique needs to go.

8. Why this matters beyond quantum research labs

The immediate audience is anyone developing proprietary quantum algorithms who must rely on third-party compilation and cloud quantum hardware, a real and growing situation as commercial interest in quantum computing increases. The broader pattern is worth noting too: this is a case of finding a cheap correction mechanism in a different domain than the corruption (classical logic correcting quantum-circuit output), rather than trying to reverse the corruption in its native, more expensive domain (a second quantum circuit). That's a generally useful move whenever protecting IP in an expensive-to-compute domain, look for whether the corruption can be undone somewhere cheaper.

Does this protect against a compiler that's actively malicious, not just curious?

The paper's threat model is IP exposure to an untrusted compiler that sees the circuit, i.e. confidentiality. It isn't designed as a defence against a compiler that deliberately tampers with the circuit's logic to sabotage results; that's a different threat model (integrity) the paper doesn't claim to address.

Does obfuscation increase how much quantum hardware time you need?

Yes, a small amount, extra gates are added to the circuit, though the paper reports this remains modest and the correction step itself needs no quantum hardware at all, just classical post-processing on a normal computer.

Why exclude Hadamard gates from the obfuscation pool?

Hadamard gates create superposition, and superposition's effect on final measurement probabilities can't be reliably undone with simple, deterministic classical bit operations the way a state or phase flip can.

Has this been tested on real quantum hardware, not just simulation?

The reported evaluation used a noise-free simulator specifically to isolate the obfuscation effect from hardware noise. Testing on real, noisy NISQ hardware is a natural next step not covered in these results.

Takeaways

  • Third-party quantum compilation creates a real IP-exposure risk for proprietary circuit designs, a NISQ-era problem with no established classical analogue.
  • The proposed technique inserts extra quantum gates to corrupt measurement output, then corrects it with simple classical bit-flip logic, no second quantum circuit, no barriers, no qubit-mapping tracking.
  • It rests on a clean quantum fact: phase-only gates vanish at measurement; state-changing gates produce a deterministic, classically-reversible bit flip.
  • Across five diverse algorithms, median TVD stayed above 0.5 and median DFC stayed negative, confirming both statistical and functional obfuscation, using only a generic shared gate pool.
  • Open work: smarter, circuit-aware gate selection, and support for algorithms needing measurement in multiple bases.

References & further reading

← prev: AlgoBuster (UDS 0x27) next: JVM Memory Shell Search →
© cvam — written in plaintext, served warm