The presets and the threat model belong together because every preset carries a caveat. For this audience the honesty of this document is part of the artifact's credibility. No em-dashes; references as Title: Link.
- Ship two presets, both clearly labeled:
demo(1024-bit modulus, known factorization, fast, intentionally insecure) andillustrative(2048-bit, slower, still uses a locally generated modulus so still not production-secure). Neither is safe to deploy, and the README must say so in the first paragraph. - The single most important caveat is that the wall-clock of a puzzle is hardware-relative and not a real-time guarantee; the second is that the generator holds the trapdoor and can cheat. Both flow directly from how the construction works, not from implementation sloppiness.
- The threat model is deliberately narrow: this PoC demonstrates correctness and the homomorphic property, not soundness against a resourced adversary, and it makes no constant-time or side-channel guarantees.
Pick T per-host after the Phase 1 benchmark, since squarings/sec is hardware-dependent. The values below are starting points to be replaced by measured numbers.
| Preset | Modulus bits | Setup | Target wall-clock | T (retune per host) | Use |
|---|---|---|---|---|---|
demo (auction) |
1024 | RSA, known factorization | a few seconds | 2^22 (measured ~3.4 s on the dev host) | fast local demos, tests, CI |
vote |
1024 | RSA, known factorization | a few seconds | 2^22, plus per-ballot 0/1 NIZK | the privacy-tally demo with ballot proofs |
illustrative |
2048 | RSA, locally generated | tens of seconds to ~2 minutes | 2^24 (~40 s) to 2^26 (~165 s) | the headline demo, blog gifs |
classgroup |
256-bit discriminant (illustrative) | transparent, no trusted setup | ~0.5 s | 2^14 (measured ~0.5 s) | the honest no-trapdoor variant |
Notes on choosing T. The relationship is wall-clock = T / (squarings per second), where squarings per second is measured by the bench subcommand. MEASURED on the development host (Linux x86_64, Intel Broadwell, release plus LTO), recorded in the lab notebook:
- 1024-bit RSA: 1.29 M squarings/sec. T = 2^22 is about 3.2 s, 2^24 about 13 s, 2^26 about 52 s.
- 2048-bit RSA: about 0.38 M squarings/sec. T = 2^22 is about 11 s, 2^24 about 44 s, 2^26 about 175 s.
- The demo auction at T = 2^22, 1024-bit measured 3.4 s end to end (including setup).
These numbers are specific to this host; timing is hardware-relative, so re-measure with htlp-demo bench on the target machine before quoting a wall-clock. Class-group squaring is much slower (about 40x at 256-bit on this host), and the 256-bit class-group discriminant is illustrative only; a secure discriminant is on the order of 1500 to 2000 bits.
State what the PoC defends against and, more importantly, what it does not. The negative space is the honest part.
In scope (what the PoC demonstrates):
- Correctness: solving a freshly generated puzzle recovers the locked message; solving a homomorphically combined puzzle recovers the aggregate.
- The homomorphic property: individual inputs stay hidden until a single solve reveals only the aggregate.
- A believable sequential delay on the host hardware.
Explicitly out of scope (what the PoC does NOT guarantee):
- Secure modulus generation (RSA path). The RSA modulus is generated locally with a known factorization, so on that path the generator can break every puzzle instantly; a real deployment needs a trusted-setup ceremony. The
classgrouppath removes this: it uses a transparent discriminant with unknown class number and no trapdoor (it is, however, time-lock encryption, not the additively homomorphic scheme; see MATH.md). On the RSA path the base g is sampled as a quadratic residue (the square of a uniform unit), matching the paper. - Real-time release. T squarings is hardware-relative. A faster solver opens puzzles sooner. The canonical evidence is LCS35: a ~35-year puzzle solved roughly 15 years early, on both a commodity Core i7 and an FPGA.
- Side-channel and constant-time resistance. The library is not constant-time. As partial hardening, the secret-exponent exponentiations use GMP's side-channel-resistant modexp on the RSA path (
secure_pow_mod) and a fixed-width Montgomery ladder on the class-group path (pow_ct), which removes the classic square-and-multiply Hamming-weight leak. The underlying GMP arithmetic, the form composition and reduction, and key generation are not constant-time, so a resourced side-channel adversary is out of scope. SeeSECURITY.mdfor the precise accounting. - Input validity: partial. For 0/1 ballots,
gen_ballotandverify_bitgive a zero-knowledge proof that each puzzle locks a bit, so a malicious voter cannot corrupt the tally (thevotedemo rejects a forged ballot). For auction bids there is no in-range proof yet, so a malicious bidder could still lock an out-of-range value; that general range proof is future work (see MATH.md, Section 8). - Denial of service via no-solver. If nobody runs the squaring, the puzzle never opens. The PoC assumes a cooperative solver.
- Adversarial parallelism beyond the standard assumption. We assume sequential squaring cannot be meaningfully parallelized, per the standard time-lock assumption; we do not defend against a break of that assumption.
These three sentences should appear near the top of the README so no reader mistakes the artifact for a deployable tool.
- This is a research proof-of-concept demonstrating a linearly homomorphic time-lock puzzle and its homomorphic aggregation property. It is not secure for production use.
- The modulus is generated locally, so the generator knows the trapdoor and can open any puzzle instantly; a real deployment requires a trusted-setup ceremony or a class-group instantiation with no trusted setup.
- The opening time is hardware-relative and is not a real-time guarantee; a faster solver opens puzzles sooner, as the LCS35 puzzle showed when it was solved roughly fifteen years ahead of its design schedule.