fhe-ssm-verification-kit

The fhe-ssm verification kit

On 2026-09-18 a 405M parameter recurrent language model (xelananv/fhe-ssm-pbd430a) generated text for 64 prompts at once under CKKS fully homomorphic encryption on a rented 2 GPU server, with the keys generated on a laptop & the secret key never leaving it. This dataset is that session, complete: the keys, every ciphertext that went to the server and every ciphertext that came back, the plaintext rows that were encrypted, the rows the laptop decrypted, and the tokens. With it, anyone can check on a laptop, in a few minutes, that the server's replies decrypt to the model's output, that the requests were the embeddings of the recorded tokens, and that the tokens the session produced follow from the decrypted replies. The code, the server and the session records are at github.com/xelananv/fhe-ssm.

The secret key is published on purpose. It was generated solely for this session, it protected the 64 public prompts in records/demo_prompts_64.txt, and it will never be used again. Publishing it is what makes the session checkable.

What is in it

Two directories, 52.7 GB in all (1,925,558,556 + 50,824,248,962 bytes):

demo_verification_demo_20260918T074952Z/     1.93 GB, 129 files — the session, everything produced on the client laptop
  HOWTO.md                                   the kit's own instructions
  MANIFEST.sha256                            sha256 of the other 128 files
  keys/
    cryptocontext.bin, cryptocontext.bin.dev the CKKS context: ring 2^17, OpenFHE HEStd_128_classic, uniform ternary secret, depth 41
    public.key                               88,086,109 B
    secret.key                               44,044,503 B   <- published on purpose
    contract_r17.json                        the rotation-index contract the evaluation keys cover (73 rotation amounts, 143 indices)
    MAC_KEYS_MANIFEST.sha256                 sha256 of the COMPLETE client key directory as it was when the evaluation keys were uploaded
  session_cts/
    MANIFEST.jsonl                           one line per file (108): tick, request, lanes, d, dpad, bytes, sha256, UTC
    tick_000_req0/ … tick_017_req17/         per tick: req.N.0   88,088,569 B  the ciphertext that LEFT the laptop (level 0)
                                                       req.N.meta            its layout sidecar
                                                       resp.N.0  10,489,656 B  the ciphertext that CAME BACK (level 37)
                                                       resp.N.meta
                                                       input_rows.f64         the 64 × 1,024 embedded rows that were encrypted (float64, lane-major)
                                                       hidden.f64             the 64 × 1,024 rows the laptop decrypted from the reply
  records/
    tokens.json, transcript.json, lanes_text.json, demo_prompts_64.txt, prepare.log, generate.log, audit.log, SESSION_LOG.md,
    pbd430a_config.json, pbd430a_seeds.json, pbd430a_weights.npz.sha256, bundle_pbd430a.bin.VERIFIED
mac_keys_r17/                                50.82 GB, 42 files — the EVALUATION keys of the same key set (needed only to re-run the server side)
  evalmult.bin                               352,338,971 B, the multiplication key
  evalrot.part000.bin … evalrot.part035.bin  36 rotation-key parts, 1,409,337,439 B each (the last 1,057,004,619 B)
  public.key, cryptocontext.bin, cryptocontext.bin.dev, contract_r17.json, MANIFEST.sha256

public.key is the same file in both directories (sha256 4b5fc3ed2d3ceadc471d9bfebcb2ad87b842ded12b38b73150c6742d2d098346), and every hash in mac_keys_r17/MANIFEST.sha256 appears in keys/MAC_KEYS_MANIFEST.sha256: one key set. The server never had secret.key; it received the files of mac_keys_r17/.

The session: 64 lanes (one prompt each), one ciphertext per tick carrying all 64 lanes, greedy decoding, at most 8 generated tokens per lane, a lane stops at its first newline; 18 ticks, 492 generated tokens (records/SESSION_LOG.md). The client's own audit (records/audit.log) replayed the plaintext model greedily on the same tokens: 491 of the 492 tokens agree; the one difference is a near-tie in lane 33 (recorded a newline, plaintext argmax " It", the two logits 0.0053 apart), and a shift test rules out any bookkeeping displacement (lag 0 scores 491/492, lag 1 scores 1/492).

What you can check, and what it gave when checked (2026-09-22, a 16 GB laptop)

Tool: mac_fhe_client from the GitHub tree (hpc_gpu_port/mac_fhe_client.cpp, built against OpenFHE 1.5.1 CPU with hpc_gpu_port/mac_build_client.sh); one decryption of a ring 2^17 ciphertext takes about a second. The scripts that produced the numbers seen below, and the numbers themselves, can be found in the GitHub tree under results/dense-demo-s31/pod_2xbw_20260917/kit_level1_check_20260922/.

cd demo_verification_demo_20260918T074952Z
shasum -a 256 -c MANIFEST.sha256                                                   # 1. integrity
T=session_cts/tick_005_req5                                                        # 2. re-decrypt a reply
mac_fhe_client dec --ctx keys/cryptocontext.bin --sec keys/secret.key --in $T/resp.5 --count 1 --lanes 64 --d 1024 --dpad 1024 \
    --require-meta $T/resp.5.meta --out /tmp/hidden5.f64
mac_fhe_client dec --ctx keys/cryptocontext.bin --sec keys/secret.key --in $T/req.5 --count 1 --lanes 64 --d 1024 --dpad 1024 \
    --require-meta $T/req.5.meta --out /tmp/input5.f64                             # 3. re-decrypt a request
python3 -c "import numpy as np; a=np.fromfile('/tmp/hidden5.f64','<f8'); b=np.fromfile('$T/hidden.f64','<f8'); print(np.linalg.norm(a-b)/np.linalg.norm(b))"

Two decryptions of the same reply are therefore not byte identical and not even within 10⁻¹³: OpenFHE adds noise at decryption, and at the replies' level ("level":37 in every resp.N.meta) it is of the order 10⁻³ (relative). The requests, encrypted fresh at level 0, re-decrypt to 10⁻¹¹. The token decisions are unaffected: every recorded pick is reproduced. Compare with a tolerance, not cmp.

Re-running the server side — feeding the recorded requests, in order, to a freshly started server built from the GitHub tree (docs/RUNBOOK.md) with mac_keys_r17/ as its evaluation keys and the model's bundle_pbd430a.bin from the model repository is technically possible but would need 2 GPUs. It was not attempted, and whether it would come back byte-identical is unknown.

Encrypt something yourself

mac_fhe_client enc --ctx keys/cryptocontext.bin --pub keys/public.key --rows myrows.f64 --lanes 64 --tokens 1 --d 1024 --dpad 1024 --out /tmp/mine

CKKS encryption is randomised: a fresh encryption of input_rows.f64 is not byte-identical to any recorded request; it decrypts to the same rows.

What this does and does not show

It shows that the text the session produced was computed from ciphertexts the laptop made and decrypted with a key that never left the laptop, and that the server's replies are the model's output to CKKS precision. It says nothing about the server's speed (that is in the GitHub tree's records, and the 148-step free-running session of 2026-09-19 ran on server-side test keys and kept no ciphertexts).

Citation and contact

@software{fhe_ssm_2026,
  author = {Ananyev, Alexander},
  title  = {fhe-ssm: a recurrent language model served under CKKS fully homomorphic encryption with free-running generation},
  year   = {2026},
  url    = {https://github.com/xelananv/fhe-ssm}
}

MIT. Alexander Ananyev — [email protected]. X, GitHub, model: xelananv/fhe-ssm-pbd430a.