What a homomorphic biometric vault costs today: five measured criteria

Honest label: the vault described here is research, archived, with no path to production. Hummand’s product uses centralised custody, with key envelopes in a managed key module, per-client isolation in the database and cryptographic destruction at retention, and says so. This note is what we learned by measuring the alternative, and the reason it is not the product.

The thesis, and the gate

The vault’s thesis is to verify identity without the operator ever decrypting the biometric template: the template stays encrypted under homomorphic encryption, the comparison happens over ciphertext, and decrypting the result requires the cooperation of several parties, the client among them. Beautiful on paper, and dangerous for that very reason: it is the kind of architecture that gets promised before it gets measured.

Before any product code, a gate was fixed with six criteria and written acceptance limits: (5) the Python bindings cover the whole flow; (1) the multiparty protocol works end to end with three parties; (2) numerical precision does not contaminate the biometric decision; (4) everything reproduces on the same locked version, weeks later; (3) latency fits an interactive API on representative hardware; (6) someone else reproduces the results from the code and documentation alone. The execution order was 5, 1, 2, 4, and the agreement was: failure on any one reopens the choice of scheme.

The scheme is CKKS, the only homomorphic scheme with approximate arithmetic over reals, which is what an inner product between embeddings asks for. The library is OpenFHE 1.5.1, with the Python bindings locked to an exact version. Parameters: multiplicative depth 1, 50-bit scale, batch of 512, 128-bit classical security.

What passed

Criterion	What was measured	Result	Limit
5, bindings	Every operation of the flow via Python	exposed and functional; smoke test with error of 2e-12	whole flow without C++
1, protocol	Three parties, distributed key generation, addition, multiplication and dot product, one hundred runs	100 of 100; maximum error 8.5e-12	one hundred runs without failure
2, precision (distance)	Squared Euclidean distance, ten thousand pairs, dimension 512	mean relative error 1.69e-13; worst case 3.75e-12	mean below 1e-3; worst below 1e-2
2, precision (face)	Inner product, ten thousand normalised pairs, dimension 512	mean relative error 8.73e-11; worst case 8.27e-8	the same
4, stability	Criteria 1 and 2 repeated 28 days later, same version	identical correctness; numerical variation below 3%	variation below 10%

The precision margin is seven to eleven orders of magnitude. Near pairs, which simulate the same person and are the region where the decision happens, do not have a systematically larger error: in the distance test their error is about five times that of far pairs, but both sit around 1e-13; in the inner product it is smaller. In a smoke test with two hundred pairs of real faces from a public set, the degradation of false acceptance and false rejection rates was zero; the full run of six thousand pairs was abandoned because of machine instability and waived with a recorded justification, since an error of 1e-8 does not move a decision whose gap between distributions is about 0.4.

In short: the arithmetic is not the cost. Regarding CKKS approximation errors, for this operation and this dimension, there is nothing to fear.

What it cost, and where the cost lives

The protocol requires every party, not a subset. The plan was two-of-three custody: any two parties cooperate to decrypt, and one can go down. In the first criterion, decryption with two of three parties threw an exception in one hundred of one hundred runs. OpenFHE’s multiparty scheme for CKKS is N of N. As confidentiality, that is stronger than the plan. As availability, it is the opposite: the permanent loss of any party’s secret makes that client’s base unrecoverable by cryptographic means, and what remains is operational mitigation, with redundant key modules and procedures, not protocol. Restoring the subset property requires an additional secret-sharing layer over the keys, reconstructed inside an attested enclave and discarded afterwards. That was studied and is feasible; it is not code.

Decryption is an oracle, and the scheme is fragile before it. CKKS is insecure against an adversary who observes decryption outputs: with access to that oracle, the key can be recovered. The standard mitigation, flooding the partial decryptions with noise, exists in the library for the exact schemes and does not exist for CKKS, because the noise required would destroy the precision the scheme offers. The consequence is an architectural constraint, not a parameter: only ciphertexts generated by the vault itself may reach the decryption pipeline, never ciphertexts of external origin. It is a sustainable constraint, but it is one more thing that has to be true all the time.

Performance in the reference environment was never measured. Criterion 3 asks for one thousand end-to-end verifications, including ciphertext retrieval and decryption by three parties, on a representative cloud instance, with a median below 500 ms and p95 below 1.5 s. The instance was not contracted and the criterion stayed open. What exists are side latencies, with no gate value: the inner product operation with encryption and decryption in a single process, in a virtualised development environment, cost about 91 ms per pair, and the same distance suite varied from 76 ms to 147 ms per pair between the original run and the repeat, a 48% swing attributed to the environment, with identical numerical errors. None of that includes the network or the protocol between parties.

Independent verification did not happen. Criterion 6 asks for someone outside to reproduce everything from the code and documentation alone. The code and the documentation exist; the outside person does not.

The environment is narrow. The Python bindings only run on Linux, and capture in the browser, which the thesis requires so the template never leaves the device in the clear, has no mature web binding in the chosen library. The research code that exists has only nominal distributed custody: the three keys live in the same process, and the biometric decision threshold was not calibrated with real data.

The honest reading

The gate was designed to fail the scheme, and it did not: CKKS arithmetic, for this operation, is solid and reproducible. What the gate did was more useful than failing. It showed that the cost of a homomorphic vault today is not in precision, but in three places the promise tends to hide: availability under N of N, the attack surface of decryption, and the performance and external verification that remain unmeasured.

It was with that picture that the vault left the product line and became a research track. The product that exists does the opposite, and says so: it decrypts under centralised custody, within declared limits, with cryptographic destruction at retention. It is not the thesis. It is what holds up with what was measured.

Limits

• The criteria were run in a virtualised development environment, with a single machine simulating the three parties. No latency number here is a gate result.
• Precision was measured with synthetic vectors and a smoke test with faces from a public set; the full run with real faces was waived with a justification, not completed.
• The parameters are those of multiplicative depth 1, enough for an inner product. Deeper operations change the cost and were not measured.
• The gate is not complete: two of six criteria remain open, and the track has been idle since 2026-05-31. If it resumes, it starts with them.