QTL timing formula and glossary¶

Revision: 2, 5 October 2026; reserved physical-clock model added
Status: Mathematical model and design clarification; no change to existing locks, key derivation or measured results
Requested target: 312 elapsed seconds per unlock on different machines

Result in plain English¶

The current offline QTL cannot guarantee that a computation taking 312 seconds on one CPU takes 312 elapsed seconds on every other CPU. Memory capacity and clock frequency do not supply such a guarantee. The same fixed computation can be completed at different rates.

We can normalize the amount of work into reference seconds, or calibrate a new lock to approximately 312 elapsed seconds on a specified machine. Those are different operations. Neither is physical spacetime dilation. ART’s simulated QEpoch remains a third, purely visual clock and must not be used as an access-control guarantee.

One timing model¶

For fixed algorithm, memory, parallelism and implementation, define:

W = m_eff * t                              nominal workload, KiB-passes
T_device approximately = W / R_device      elapsed seconds
T_reference = W / R_reference              reference-work seconds
alpha_device = R_device / R_reference      dimensionless rate ratio
T_reference approximately = alpha_device * T_device

Here m_eff = 4*p*floor(m/(4*p)) is Argon2’s effective number of 1-KiB memory blocks, expressed as KiB. W is a bookkeeping proxy, not a count of every instruction or actual memory transfer. R_device must be measured for the selected settings, not inferred from the processor’s advertised GHz. Setup overhead, cache behavior, memory traffic, implementation differences, thermal throttling and other work can make the approximation inaccurate.

The normalized quantity T_reference = W/R_reference is a definition of assigned work in reference seconds. Estimating it as alpha_device*T_device additionally assumes the measured rates apply during the run. Defining a rate from that same run merely restates the measurement; it does not independently validate a timing guarantee.

The 312-second example¶

Suppose a fixed workload W takes 312 seconds at the reference rate. The following is an illustration, not a benchmark of any named CPU:

Machine rate relative to reference	Actual elapsed time, assuming steady proportional throughput	Assigned reference-work time
0.5 times	624 seconds	312 reference seconds
1 time	312 seconds	312 reference seconds
2 times	156 seconds	312 reference seconds
4 times	78 seconds	312 reference seconds

Multiplying the fast machine’s elapsed time by its rate ratio makes the reporting units comparable. It does not make the user or attacker wait longer. A displayed value of 312 reference seconds must never be labeled 312 elapsed seconds unless that time actually passed.

Calibration before creating a new lock¶

Choose memory m and parallelism p first, perform a warm-up, and measure several sample derivations at a known pass count t_sample. A first estimate is:

T_target = 312 seconds
T_sample = median of measured sample durations
estimated_passes = ceil(t_sample * T_target / T_sample)

Validate the proposed workload on the reference machine before claiming measured timing. This approximation assumes roughly proportional pass cost; a short pilot can misestimate long-run performance. Reject settings outside the supported resource policy rather than silently changing the parameters or overstating precision.

For a more detailed local timing model, measure several pass counts at the same m and p and fit T(t) approximately = a + b*t, with b positive. Then ceil((312-a)/b) is another candidate pass count, subject to bounds and direct measurement. Neither fit predicts every machine or every future run.

312 seconds is a newly proposed target. Earlier experiments targeted 300 seconds and observed approximately 312 to 324 seconds in particular runs. Those observations must not be retroactively described as deliberate 312-second calibration.

Memory and time¶

At fixed parameters one can also report:

J = m_eff * T_device    memory-time product in KiB-seconds

This is a descriptive resource metric. It is not spacetime, entropy, a lower bound on attacker cost, or a guarantee of equal runtime. Increasing memory can restrict the number of simultaneous guesses, but the effect depends on the attacker’s memory capacity, bandwidth, hardware and algorithms. Doubling memory does not necessarily double runtime. Re-benchmark after changing memory; do not extrapolate only from bytes or GHz.

Argon2 explicitly supports memory, pass and parallelism parameters and has analyzed time-space trade-offs. In that context space means computational storage, not distance or a gravitational field. RFC guidance also discusses maximizing attacker cost under a defender’s latency budget; maximizing the number of passes alone is not the same optimization. RFC 9106, sections 3, 4 and 7

Why parameters cannot be adjusted during unlock¶

The existing construction derives:

P = UTF8(format) || 0x00 || UTF8(credential_kind) || 0x00 || credential_bytes
K = Argon2id(P, salt, memory=m, passes=t, parallelism=p, version=19, output_bytes=32)
plaintext = AES256GCM_Decrypt(K, nonce, ciphertext, authenticated_header)

Memory, passes and parallelism are cryptographic inputs, not speed knobs that can be changed while preserving K. The header is also authenticated. The same password with changed parameters will generally derive a different key and fail authentication against the existing envelope, as Test Two demonstrated. Obtaining exactly the same derived key by coincidence is not a supported access mechanism.

Therefore:

Seal a new lock with the calibrated parameters and retain them for unlocking.
To migrate an existing lock’s parameters, first authenticate and recover it, then create a new envelope with fresh salt and nonce and verify recovery. This migration is not performed by this document.
Do not silently modify the stored parameters, clock fields or ART values to force a desired display time.

Why a local clock-cycle read does not enforce the target¶

A CPU cycle counter or monotonic clock can measure a local interval and guide calibration. It does not force an adversary’s implementation to use the same clock or follow a waiting rule. GHz also omits instructions per cycle, memory stalls, vectorization and accelerator differences.

For the current deterministic offline construction, the attacker can execute the same derivation on different hardware. If its effective rate is k times the reference rate, the model predicts roughly 312/k elapsed seconds for the same work. Without an enforceable upper bound on that rate, the file alone supplies no universal 312-second duration. Sequential-work techniques can restrict parallel speedups but do not make different devices equally fast.

If the requirement is instead do not release a necessary secret before 312 real seconds have elapsed, a trusted external release service or protected hardware clock is a different design. Its condition might be:

release permitted only if trusted_elapsed >= 312 seconds

That is an earliest-release policy, not a promise of release at exactly 312 seconds: computation, transport or service failure can delay access further. It must protect a secret that the attacker does not already possess. No such service, hardware gate or waiting timer is implemented here.

Relationship to ART QEpoch¶

Art v3 integrates the simulated clock rate:

Delta_QEpoch approximately = Delta_monotonic_time * sqrt(1 - beta^2)

The implementation numerically integrates this rate as the decorative dial’s virtual speed beta varies. Its Live value uses the system wall clock. QEpoch is a simulated special-relativity-inspired display, not measured physical time dilation, quantum entropy, Argon2 work, or an authentication timestamp. CPU speed must not be substituted for beta: computation rate is not velocity divided by light speed.

No stationary black-hole model or physical measurements are present in QTL. Adding those names or a simulated dilation factor does not supply a missing timing guarantee.

Reserved subformula for physical time dilation¶

Research clause only. Activate this model only for a specified physical clock-comparison problem with measured inputs, reference frame, uncertainty and independent validation. It is not part of the current KDF, file format or ART implementation.

Let tau be elapsed proper time at the device, t_R a specified physical reference-coordinate time, and f = d(tau)/d(t_R). For constant f:

Delta_tau = f * Delta_t_R
Delta_t_R = Delta_tau / f

For varying conditions, integrate Delta_tau = integral f(t_R) d(t_R) along the device’s trajectory. The following are separate special cases, not a universal formula to multiply indiscriminately:

Flat spacetime, moving clock: relative to a chosen inertial frame,

f_velocity = sqrt(1 - v^2/c^2),     0 <= v < c

Static clock in Schwarzschild exterior: for a nonrotating, uncharged spherical source, held at fixed radius r outside its horizon, using time normalized at infinity,

r_s = 2*G*M/c^2
f_gravity = sqrt(1 - r_s/r),        r > r_s

This static-clock expression does not describe an observer held stationary at or inside the horizon. General motion or rotation requires the appropriate spacetime model. Cambridge relativity notes on clocks and proper time, Schwarzschild geometry.

Optional connection to workload accounting¶

For bookkeeping only, define R_proper as measured computation per device proper second. If f and R_proper are constant and the nominal workload approximation applies:

Delta_tau approximately = W / R_proper
Delta_t_R approximately = W / (R_proper * f)

This is a change of time reference, not a way to force equal execution time. For example, 312 device seconds at f=0.8 correspond to 390 reference-coordinate seconds. Conversely, 312 reference-coordinate seconds correspond to 249.6 device seconds. These are mathematical examples, not observations about either computer in our experiments.

The device speed v is physical motion, never CPU frequency. The source mass M is kilograms, never RAM capacity m. No measured r, M, v or independently validated f is available for QTL here. Hardware-rate ratio alpha_device and relativistic rate f are distinct quantities. Do not infer either from the other.

Revision acceptance conditions¶

Any future use must identify which clock defines the requested interval, obtain trustworthy measurements, propagate their uncertainty, and separately demonstrate the access-control mechanism. It must preserve existing envelope compatibility or define an explicit migration. Physical clock corrections alone do not prevent offline copying, malicious clock reports, faster computation, or retention of a previously obtained decryption key. Until those conditions are met, this subformula remains explanatory and supplies no additional security claim.

Glossary and definitions¶

Symbol or term	Definition	Units or important distinction
QTL	Project name for the experimental access construction	Currently classical Argon2id plus AES-GCM
QTLO	Project label for denied or delayed access concerns	No standardized lockout mechanism implied
T_target	Desired local elapsed duration for calibration	312 seconds in this proposal
T_device	Observed elapsed execution time	Seconds measured locally
T_reference	Work expressed using a specified reference rate	Reference-work seconds, not necessarily wall-clock seconds
m	Requested Argon2 memory	KiB; 1 KiB = 1,024 bytes
m_eff	Effective Argon2 memory-block allocation	Multiple of 4p KiB under the formula above
t	Argon2 pass count	Positive integer; not a timestamp
p	Argon2 parallelism parameter	Number of algorithm lanes; not simply total available CPU cores
W	Nominal memory-pass workload proxy	KiB-passes
R_device	Measured effective work rate for a particular configuration	KiB-passes per second
R_reference	Fixed documented reference rate	Same units as R_device
alpha_device	Device/reference rate ratio	Dimensionless calibration factor
J	Memory-time product	KiB-seconds; descriptive, not a security proof
P	Framed credential input	Bytes; password bytes or disposable test-key bytes
K	Derived AES key	32 bytes; distinct from a hash commitment
Salt	Public per-envelope random derivation input	Existing implementation uses 16 bytes
Nonce	Per-encryption AES-GCM input	Existing implementation uses 12 bytes; must not repeat with the same key
Authenticated header	Metadata included as AES-GCM associated data	Tampering is detected when authentication is checked
Elapsed time	Duration between observations	Separate from computation completed
Unix epoch timestamp	Seconds counted from the Unix epoch	A timestamp, not an attack cost
Monotonic clock	Clock intended for measuring successive durations	Not a trustworthy remote enforcement authority
Clock cycle	Hardware timing/execution unit	Not a universal number of seconds across processors
Memory hardness	Design intended to make efficient computation require substantial memory	Does not equalize all hardware
Time-space trade-off	Using different amounts of storage and recomputation	Computational space, not physical spacetime
beta	ART virtual speed divided by light speed	Dimensionless; simulated, currently 0 to 0.95
QEpoch	ART’s accumulated simulated epoch	Not an access-control or security measure
Time dilation	Physical difference in elapsed proper times under relativity	Not established by CPU benchmarking or memory allocation
tau	Proper elapsed time measured locally along a physical clock’s trajectory	Seconds; distinct from Argon2 pass count t
t_R	Chosen physical reference-coordinate time	Seconds; distinct from normalized workload T_reference
f	Proper-time to reference-coordinate-time rate	Dimensionless; requires a specified physical model
v	Physical speed relative to the chosen inertial frame in the flat case	Metres per second, not CPU frequency
c	Speed of light in vacuum	299,792,458 metres per second
G	Newtonian gravitational constant	Units m^3 kg^-1 s^-2
M	Mass of the source in the Schwarzschild example	Kilograms; not memory m
r	Schwarzschild areal radius of the static clock	Metres; must exceed r_s in that example
r_s	Schwarzschild radius 2GM/c^2	Metres
R_proper	Computation rate per local proper second	Work units per second for the chosen workload proxy
Earliest-release policy	Withhold a necessary secret until a trusted deadline	Requires assumptions absent from the offline prototype

Reviewable decision¶

Retain fixed cryptographic parameters for each existing envelope. Treat 312 seconds as a proposed reference-machine calibration target, and use reference seconds only with an explicit label. Exact hardware-independent elapsed-time enforcement is an unmet requirement of the current offline architecture. The equations clarify that limit; they do not claim to solve it.