Roughtime: signed time

Roughtime is a network protocol for getting signed time from a server. The client sends a random value; the server signs the current time, its error margin and the client's value together with Ed25519 and sends them back. The client verifies the signature with the server's public key, which it knows in advance. That proves the reply really came from that server, was not altered on the way, and was produced after your request.

Google started the protocol, Cloudflare and Netnod developed it further, and it is now being standardised by the IETF NTP working group as draft-ietf-ntp-roughtime. The "rough" in the name refers to resolution: time comes in whole seconds, but it is highly trustworthy.

Four main purposes:

• Giving a device that has no idea of the time a secure starting point. A device with a dead battery, no RTC, or one that sat powered off for a long time cannot validate TLS certificates; Roughtime needs no prior correct time.
• Bootstrapping NTS. NTS key exchange runs over TLS, so it needs roughly correct time first. Roughtime makes that first step secure.
• Auditing time servers. Querying several servers in a chain catches a server that reports the wrong time and shows it with signed proof.
• Producing evidence. Showing that a file, log or incident record existed before a given second, in a way that can be verified later without network access.

No, they do different jobs. NTP keeps your clock continuously disciplined to milliseconds or better. Roughtime answers "what time is it" with one-second resolution, but every answer is signed. The usual setup runs both: at boot the device gets a rough but verified time from Roughtime, then moves on to NTP protected by NTS. Section 6 of the draft describes this combination.

That is how the standard defines it: the timestamp (MIDP) is sent in whole seconds and the radius (RADI) is also in seconds and may not be zero. The goal is verifiability, not precision. One second is plenty to check certificate validity, to show when a record existed, or to catch a server that reports the wrong time. For precise time use the NTS service on the same server.

You derive the random value in the request (the nonce) from a hash of the file. Because the server signs that value together with the time, the signed reply is cryptographic proof that "this hash existed before this second". The roughtime-stamp tool does this automatically across three independent operators in two passes and writes a small proof file that can be verified later without network access. The commands are in the document timestamping section.

This is not a feature defined in the draft; it is an application pattern built on the protocol. The proof only shows an upper bound: the file existed before that moment and has not changed since. It does not show when the file was created.

The nonce is a 32-byte one-time random value the client generates for each request. The server includes it in the signed part of the reply. Because it cannot be predicted, the signed reply cannot have been prepared before your request: an attacker replaying an old reply cannot know the nonce you generated.

If you derive the nonce from a hash of some data instead of randomly, the same logic runs the other way: now it proves the data existed before the reply. Document timestamping rests on this idea.

The time the server sends (MIDP) is not a single point but the middle of an interval. The radius is half its width: the server commits, and signs, that "the true time is between MIDP − RADI and MIDP + RADI". The standard puts the radius in seconds and forbids zero.

On our server the radius is not a hand-written constant; it is derived from the maximum error the operating system keeps for the clock. While GPS is locked it is 1 second. If the clock falls out of sync, the radius grows automatically.

Ed25519 is fast, but signing each of thousands of requests per second separately still costs CPU. So the server places requests that arrive together at the leaves of a Merkle tree, signs the tree's root together with the time once, and sends each client the path from its leaf to the root. The client uses that path to check that its own nonce is bound to the signed root. One signature covers hundreds of requests, with no loss of security.

The server's identity is a long-term key; clients only know its public half. Keeping that key on an internet-facing machine to sign every reply would be risky. So the long-term key signs a certificate that authorises a short-lived online key for a given time window (MINT–MAXT). The online key signs the replies, and the certificate is sent along with every reply.

Our root key is kept offline; the delegation on the server is valid for one year and is renewed every year. Details are in the key management section.

The client queries at least three servers in turn and derives each nonce from a hash of the previous reply. That creates a cryptographic order between replies: the second reply must have been produced after the first. If a later reply's time interval lies entirely before an earlier one's, one of the two servers is lying.

The chain of signed replies you hold is then publicly verifiable proof of the contradiction. The draft defines a standard JSON format for reporting it, called a "malfeasance report".

UDP completes in a single round trip, keeps no connection state and is simple enough for a device that does not know the time. Its well-known risk is spoofed-source packets that make a server send large replies to someone else (a reflection attack). Roughtime prevents this by design: the client pads its request to at least 1024 bytes and the server never replies with more than it received. Shorter requests go unanswered. The draft also defines TCP; our server speaks only UDP for now.

Because the draft is not yet an RFC, IANA has not assigned Roughtime an official port. The community has used 2002/udp for years; most servers, including Netnod, roughtime.se and Time.nl, are on it. If a port is assigned when the standard is published, we will open it too and keep 2002 running in parallel for a while.

Not today. Common NTP clients, including the chrony 4.8 we run, have no built-in Roughtime support. You use Roughtime with a separate client: with the Go or Python clients you can check the clock, timestamp documents, or run it in your boot script as a verification step before NTS. Keep using NTP/NTS to keep the clock disciplined.

No. The draft says so plainly: a large enough quantum computer could break Ed25519 signatures, and when that day comes a new version of the protocol will be needed. Some implementations experimentally support a post-quantum signature (ML-DSA-44), but it is not part of the standard yet and we do not offer it. For now, Ed25519 is considered secure.

If a single server gives the wrong time, you cannot notice it without another source as long as its signature is valid. If two servers disagree, you cannot tell which one is right. With three or more servers run by different organisations you see what the majority says and can prove who lied with the signed chain. That is why the draft asks clients to use at least three independent servers.

No. Qualified timestamps (in Türkiye under Electronic Signature Law No. 5070, in the EU under eIDAS) are issued by accredited trust service providers, and we are not one. Roughtime replies are technical evidence: anyone can verify them independently with the public key, and they can be cross-checked against several operators. They suit audits, incident investigations and showing time consistency between systems; they do not replace a legal procedure.

For every request we answer: the time, source IP address and port, the request nonce, the time and radius we sent, the request length, the position in the Merkle tree and the tree root. These records are kept for 365 days and then deleted automatically. They are not published and are not shared with anyone except where the law requires it. Per-minute totals (how many requests, how many invalid) are kept indefinitely.

Why we keep them: to see abuse, and to be able to confirm from our own records that a given proof really came from this server. When you timestamp a document the nonce is derived from its hash, so the hash ends up in this log too; for sensitive content use a salted hash.

They stay valid. Proofs are verified against the long-term public key, and every public key we have used is listed permanently on this page with its dates of use. The yearly delegation renewal does not change the public key. If we ever suspect the root key has been compromised we will announce it here and in the server list, stating the affected period explicitly.

It is free and needs no registration. To set a device's clock, one query at boot and then one every few hours is enough; there is no need to query more than once a minute. By design a reply can never be larger than its request, so the server cannot be used as an amplifier in reflection attacks.