Homomorphic encryption is usually discussed in theory. I wanted the numbers: if a server can add and count encrypted values without ever decrypting them, what does that actually cost on a real network under real concurrency. So I built a measurement environment.
Repo: swadhinbiswas/Partially-Homomorphic-Encryption
The setup
The whole thing is one Go process with no third-party modules, standard library only, tested on Go 1.25. That constraint is deliberate. When you are measuring cryptography and queueing, a dependency you did not write is a variable you cannot explain.
flowchart LR
S[Simulation engine<br/>N goroutines] -->|encrypted JSON| P[External proxy pool]
P --> U[Untrusted proxy<br/>latency + fault injection]
U --> G[Gateway :8082<br/>no plaintext access]
G --> W[PHE worker pool<br/>homomorphic sum + count]
The simulation engine generates payloads, encrypts them with Paillier, sends them, and measures latency. Traffic can route through an optional pool of more than a thousand HTTP, SOCKS5 or SOCKS4 proxies, or through a built-in untrusted proxy simulator on port 8081 that injects latency and faults and observes metadata while being honest-but-curious. The gateway on port 8082 is stateless and has no plaintext access. It routes to a worker pool implemented with Go channels that performs homomorphic sum and count while tracking queue wait and compute time separately.
That separation is the point. Queue wait and compute time are different problems, and a single latency number hides which one is growing.
What it measures
The metrics recorder streams CSV and JSONL, chunked and written to disk, so a long run does not exhaust memory. The experiments cover throughput, latency percentiles, the effect of the untrusted proxy, and the overhead of the Paillier operations themselves. The repository documents scaling to a billion requests, and since all components run in one process, the failure modes are the ones under test rather than the ones coming from your orchestrator.
One thing I would tell anyone doing this: measure with the proxy in the path. Encryption cost on a loopback interface tells you about your CPU. Encryption cost behind a proxy at a realistic latency tells you whether the design is viable, and those two answers can differ by an order of magnitude.
Why this matters for data systems
Encrypted compute is often proposed as a way to keep PII out of an analytics layer while still aggregating it. That only works if the latency is acceptable, and the only honest way to know is to measure end to end. This project is the measurement harness, with key management and reproducibility notes so a run can be repeated rather than trusted.
The source and the experiment definitions are in the repository above.
Reach me at swadhinbiswas.cse@gmail.com or on GitHub and LinkedIn.
No comments yet.