Blind Oracle
FHE · TFHE-rs · programmable bootstrapping
Encrypt two numbers in your browser, let an untrusted Oracle add the ciphertexts it can never read, then decrypt the sum locally.
THE QUESTIONER
Your keys. Your values. Your world.
HOW THIS DEMO WORKS
- Your browser generates keys and encrypts your numbers.
- Only ciphertext is sent over the wire to the Oracle.
- The Oracle adds ciphertexts and returns ciphertext.
- Your browser decrypts locally and reveals the sum.
This is Fully Homomorphic Encryption (TFHE-rs, programmable bootstrapping bootstrapping = noise reset). The “plaintext world vs ciphertext world” panel below shows why the encrypted result decrypts to the right answer.
The Oracle is a demonstration server: it is for demonstration only and should never receive real sensitive values.
WHEN THE SERVER IS MALICIOUS
An evaluation key cannot directly decrypt. But FHE does not authenticate the server's answer: a malicious server can return altered ciphertext. In a different TFHE/FHEW application, researchers recovered a client key by inducing decryption errors and repeatedly learning from the client's reports of those errors. Here the decrypted result and match/mismatch verdict stay in your browser; this page sends neither back to the Oracle. That closes this particular feedback path, not every possible client side channel. Original attack (2022) · FHE side-channel survey (2025)
Same numbers, fresh randomness → different ciphertext bytes every time. Watch the fingerprints on the Oracle side change.
ENCRYPTED WIRE
The secret key stays pinned in your browser. Only ct_a, ct_b and the (non-decrypting) serverKey travel out; ct_result travels back.
PROGRAMMABLE BOOTSTRAPPING & THE NOISE BUDGET
Every TFHE ciphertext hides its value under random noise. Each operation grows that noise; too much and decryption fails. Programmable bootstrapping (PBS) resets the noise on every operation so you can keep computing — but each reset is expensive, which is why real FHE programs stay small.
rise = operation adds noise · drop = bootstrapping refreshes it
THE BLIND ORACLE
Evaluation key only. Cannot decrypt. evaluation key = can transform ciphertext, cannot decrypt
ct_a preview
awaiting ciphertext A...
ct_b preview
awaiting ciphertext B...
The swatch and digest are a fingerprint of the actual ciphertext bytes. Encryption is probabilistic: re-encrypt the same number and this fingerprint changes — yet the Oracle still adds the two ciphertexts to the correct sum.
PLAINTEXT WORLD vs CIPHERTEXT WORLD
Homomorphism means the same computation runs in both worlds and the answers match:
Enc(a) ⊞ Enc(b) decrypts to a + b. Both worlds use the same 8-bit type,
so both wrap at 256 — the plaintext track adds as a u8 and FheUint8 does the
same. Encrypt and compute above, then watch both tracks fill in.
PLAINTEXT (what you know)
CIPHERTEXT (what the Oracle sees)
decrypt locally with your key → ?
Both tracks landed on the same
number — the Oracle added two values it could never read, and the ciphertext result
decrypted to exactly what the plaintext u8 addition produced. That is
homomorphism, demonstrated rather than asserted.
The two tracks did
not land on the same number. That is a real mismatch, not a rounding
quirk — the decrypted ciphertext result disagrees with the plaintext
u8 addition, so something in the round-trip (keys, transport, or the Oracle's
operation) is wrong. Nothing here is being asserted on your behalf.
WHY ADDING NOISE STILL ADDS: PEEK INSIDE ONE CIPHERTEXT
A TFHE ciphertext is not a locked box holding your number — it is your number plus a pile of random noise. The Oracle can add two of these piles without ever separating value from noise, which is exactly why it computes but cannot read. Open the peek to see one small value buried under that noise.
- Value + noise, added together: adding the two ciphertexts adds both the hidden 3 and 4 (giving 7) and both noise piles — so the result is a noisier encoding of the correct sum. Your secret key subtracts the noise away; the Oracle has no key, so to it the whole strip is random.
- Why bootstrapping exists: each add grows the noise strip. Do too many and the noise overruns the value slot — decryption returns garbage. Gate bootstrapping resets the noise back down after each gate, at real cost, so the computation can keep going. That is the rise-then-reset the noise budget above is about.
LOCAL MULTIPLY BENCH — SPEND THE NOISE BUDGET YOURSELF
The Oracle above does the addition, because Zama's browser build of TFHE-rs ships key generation, encryption and decryption only — it exposes no evaluation operations at all, so the homomorphic step has to run where that API exists. This bench needs no oracle and no network. It runs a second, much smaller homomorphic scheme entirely in this tab, and it will do the multiplication the button above only describes.
Toy scale, stated plainly. This is a DGHV-inspired (van
Dijk–Gentry–Halevi–Vaikuntanathan, 2010) unsigned, base-256 teaching model:
Enc(m) = m + 256r + qp, Dec(c) = (c mod p) mod 256, with a
48-bit secret p. The original paper's security analysis does not apply to
this tiny adaptation, so
this is not secure encryption
and must never be used as such. Here c mod p is the unsigned residue in
[0,p): addition adds the tracked noise and multiplication multiplies it.
Correctness is guaranteed while 0 ≤ noise < p. At p reduction
first wraps; beyond it a byte can still match, but arbitrary operations are no longer
guaranteed correct. The original DGHV paper uses centered residues and a p/2
bound, which is a different decoder. This bench shows noise growth and wrapping; it does
not implement TFHE's parameters or programmable bootstrapping.
Bench idle. Press an operation to encrypt a and start a chain.
| # | Expression | Noise / budget | Ciphertext size | Decrypts to | Should be | Verdict |
|---|