The TimeVault line revisited: the past attested, the future enforced by an external time quorum
Continues the entry of 2026-07-14: enforcing the future now exists for individual entries — through an external time quorum rather than a time-lock puzzle, with its trust boundaries stated — the place condition has moved from application policy into the key, and the negative results since July are published together with corrections to statements of the July entry that no longer hold.
Koch Laboratory — the TimeVault line revisited: the past attested, the future enforced by an external time quorum
The entry of 2026-07-14 closed with the thesis that timestamping proves the past but does not enforce the future. Since then the TimeVault line has enforced the future for individual entries — by an external time quorum, not by computation — and the place condition has moved from application policy into key derivation.
Method. Problem → state of the art → falsifiable criterion → method → result with boundary conditions → next step. The construction is not described here.
1. Direction 3 revisited: enforcing the future through an external time quorum
Problem. An entry must stay unreadable until a chosen moment — to its owner, the author of the application and the operator of the service alike — whatever the device clock shows.
State of the art (published). Time-lock puzzles (Rivest–Shamir–Wagner, 1996) and VDFs (Boneh et al., 2018) require sequential work, so the moment of opening depends on hardware; with timelock encryption against a threshold randomness beacon (drand, tlock) it depends on a signature the beacon publishes only in the given round — at the price of trusting the beacon.
Criterion (falsifiable). Before the chosen moment no single key holder — neither the operator, nor the author of the application, nor the owner — opens the entry, and the device clock plays no part; afterwards the entry opens from publicly released data, and an envelope from one implementation of the format opens in a second one, and vice versa.
Method. The public envelope format beattime-seal-v1: a quorum of a public randomness beacon, operators’ key servers and the owner’s recovery code; the entry stays inside the encrypted vault. Interoperability is checked layer by layer, in both directions: against a reference library, a signature the beacon actually published, and a second implementation of the format.
Result. Confirmed within the criterion for individual entries in the line’s mobile application, also together with the place condition; measured against the July question, partial: the trusted party has been replaced by a quorum whose independence is organisational.
Boundaries.
- Operator independence is organisational, not cryptographic: the format cannot tell two shares held by one organisation from shares held by two. At present the key server is run by the lab’s public time service, so against the author of the application the protection is the beacon and the recovery code held by the owner.
- A beacon chain can disappear; the recovery code compensates for the loss of one beacon, not of both.
- The recovery code is a static secret: whoever holds it together with an operator share released early — by error, coercion or collusion — opens the entry early.
- A release on a date carried out by a server or by device software remains policy; the quorum covers only entries in this format.
Next step. More operators — separate organisations on separate infrastructure — so that opening early requires collusion among more parties. Status: implemented + interoperability tests; puzzles and VDFs — outside the implementation; enforcement without trusted parties — open question.
2. Place: from application policy to cryptographic binding
Problem. A condition “open only here”, checked by the application after decryption, is policy — a modified build or a spoofed location gets around it. That is how the place condition worked in the TimeVault line before the redesign. State of the art (published). Geofencing as access control in applications; geo-encryption, i.e. location as an input to key derivation (Scott and Denning, 2003). Criterion (falsifiable). Away from the place the key does not exist, so there is nothing to withhold; the file contains nothing about the place — no coordinates, no radius, not even the fact that a binding is in use; the recovery code stands in for the place, never for the other factors. Result. Confirmed within the criterion, for a vault and for a single entry; on a device, a place-bound entry refused to open in another city. The construction of the binding is not described here. Boundaries. A place carries little entropy: the binding protects against someone who holds a backup and does not know where to stand, but hardly against someone who has the phone and knows the owner’s town — an additional factor, not a substitute for a strong password. Without the place and without the recovery code the content stays closed for good. Next step. Measuring the effective search space for an attacker who knows the town; so far this boundary is described qualitatively, not measured. Status: implemented + tests, including on a device.
3. Negative results and redesigns since July
- Access conditions in the readable header. In an earlier container version the place and the opening date sat in the header — authenticated but readable: anyone with the file knew the coordinates at which the vault opens. They now sit in the encrypted part. Lesson: authenticated does not mean hidden.
- Identifiers of factor files (direction 2). The readable part of the envelope contained identifiers of the factor files in their declared order — against the July requirement and with no function in recovery: whoever held the container and candidate files could confirm which of them are factors and in what order. The leak has been removed.
Status: fixed and covered by tests.
Corrections to the entry of 2026-07-14
- Direction 3, status “cryptographic enforcement of the future — open research question”. Partly outdated: enforcement of the future exists for individual entries (section 1). Enforcement without trusted parties remains open; the thesis that device policy remains policy stands unchanged.
- Direction 3, timestamping (“implemented + tests”). In the line’s web service this status referred to a stamp format of its own, based on an operator secret; such a stamp evidences trust in the operator, not time, and in that service it also lacked external anchoring. The format has been retired; that service’s stamps are now made by the lab’s public time service (entry “Time as an agreed unit and as evidence”) from a blinded fingerprint of the file.
- Direction 2, the requirement that envelopes must not reveal which files are factors. At the time of publication the implementation did not meet it (section 3); fixed.
- Direction 1 — clarification. The research question — that the service be at no point, including during the release, able to decrypt anything on its own — describes the goal, not a property of the web implementation: its security page states that the server processes data in memory while a session is unlocked, and calls this a trusted session window, not “zero-knowledge”. The tested criterion stands unchanged.
Status of the direction. The past is attested by a separate, publicly verifiable time service; the future is enforced for individual entries by a quorum that spreads trust rather than removing it; place binding is part of the key. None of the constructions described has been externally audited.
Proof of time
This text was hashed and stamped on publication. Verifying it takes both files: the stamp proves that one exact byte string existed at that moment, and only the source below is that byte string. Any later edit changes the hash and breaks the match — which is the point.
SHA-256 of the stamped text: 0423ffe937b37667786bee63fc0abdd635e41e38bf3e3ef523c41e16a85cab7d
- Sigelith anchor portfolio-timevault-capsules.public.md.beattime.json
- OpenTimestamps proof portfolio-timevault-capsules.public.md.ots
- Stamped source text portfolio-timevault-capsules.public.md
Verify with: ots verify <proof> --file <source>