Clock-dependent security · RFC 5280 · RFC 7519 · RFC 6238
One clock slider drives real signature and MAC verification across six panels, so you can watch a mathematically valid result attached to a wrong security decision — because the clock lied.
Every security check on this page is real — real Ed25519 signatures, real HMAC-SHA-256 tags, verified by code you can read. The one thing under your control is the clock. Drag it and watch verifiers change their minds about bytes that never changed, because time is an unauthenticated input to authenticated systems.
Cryptography can prove who signed something and that it wasn't altered; it cannot prove when "now" is. That gap is where every failure here lives. Throughout, two indicators are kept deliberately separate: the cryptographic result (did the math check out?) and the security verdict (should we accept it?). When a lying clock makes those two disagree — a valid signature on a decision that is wrong — the panel raises an alarm, because a forged-but-accepted outcome is not a success.
Not production crypto — a teaching demo. Keys and secrets are generated fresh in your browser each visit and never leave it. What this does not prove: that any specific real system is vulnerable, or that better cryptography would fix it — the whole point is that it wouldn't.
This is the whole design: one clock. The colored bars below are fixed validity windows — the certificate's, the token's, the URL's. They never move. Only the red NOW cursor moves, and every verifier further down the page re-runs against it the instant you drag.
Real-world analog: the expired-TLS-certificate outages that take whole services offline for hours.
A real, hand-encoded X.509 certificate, self-signed with Ed25519. Run the verifier step-by-step and watch: parsing and the signature check produce the identical output at every clock position; only the final date comparison changes. "Not yet valid," "valid," and "expired" are three different verdicts over one unchanging signature.
What this isn't: full path validation. There is exactly one self-signed certificate and only its validity dates are checked — chain building, name constraints, and revocation are the job of the sibling Chain of Trust demo.
Real-world analog: the OAuth/JWT clock-skew auth bugs where a token works on one service and 401s on the next.
One HMAC-SHA-256 token, checked by two servers whose clocks differ by 90 seconds. The
exp/nbf claims are authenticated (they're inside the MAC), but each
server compares them to its own clock — so the same token is simultaneously valid at
the authorization server and expired at the resource server.
Real-world analog: the authenticator-app "code rejected / code still works" complaints, and phishing kits that replay a just-typed 2FA code.
A real 6-digit TOTP code, 30-second step. The verifier accepts a band of windows to tolerate skew — and as you widen the band, watch the replay window open with it. Then intercept a code and replay it: with the RFC-required used-code record on, it's caught; turn the record off and a genuine HMAC match lets the replay through.
Real-world analog: S3 presigned URLs and CDN signed links whose "expiry" only binds if the serving side's clock is honest.
An expiring signed URL (the S3-presigned / CDN-token pattern). Roll the client clock backward on an expired URL: nothing happens. Roll the server clock back: the dead URL works again. The verifier never reads the client's clock — the only question that matters is which clock is authoritative, and whether the attacker can reach it.
Real-world analog: Kerberos authenticator replay windows, and any "reject requests older than N minutes" API defense running on a fleet with drifting clocks.
"Reject anything older than 5 minutes," enforced by three servers whose clocks disagree. Replay caches are per-server, so a captured request that one server already saw and one rejects as stale can still be replayed through a third whose slow clock still calls it fresh.
Real-world analog: a "revoke this session in 5 minutes" that lands at a different real instant on every node — and never, on the node whose clock lags.
One Ed25519-signed token, three nodes, three independent clocks. Drag any node's skew and the accept/reject matrix shifts — while a running counter proves the signature was verified valid every single time. "The token is valid" has no meaning without answering: valid where, by whose clock?
Not all clock problems are equal. Sorting them is the point:
| Failure | Addressed by | Why |
|---|---|---|
| Honest servers drifting apart (JWT split-brain, replay skew) | NTP | Ordinary drift between cooperating machines. Syncing clocks to a shared reference shrinks the disagreement window. NTP itself is largely unauthenticated, which is its own weakness. |
| Needing a clock you can trust over a hostile network | Roughtime | A cryptographically signed, auditable time source: a server that lies can be proven to have lied. It raises the bar for a network attacker spoofing time. |
| The attacker owns the clock source (rolled-back signed URL, a node with a doctored clock) | Unfixable by timekeeping | If the adversary controls the clock the verifier reads — root on the box, the hypervisor, the NTP server it trusts — no protocol that asks that clock for the time can help. The trust root is compromised. |
This demo is not an NTP or Roughtime implementation — those are named and linked, not built. The takeaway is diagnostic: better timekeeping narrows the honest-drift failures and hardens against network spoofing, but the moment time becomes attacker-chosen, the failure is architectural, not cryptographic.