Roughtime: signed time

What Roughtime is

Roughtime is a protocol that distributes time roughly (to the second) but provably. The client sends a random number (a nonce); the server signs that number, the current time and an uncertainty radius in a single packet and sends it back. If the signature is valid, the reply really came from that server and was produced after the request was sent — replaying an old reply does not work.

It does not replace NTP; use NTP or NTS for microsecond accuracy. Roughtime's job is to make you cryptographically sure the clock is roughly right.

How it works

1. Request: the client sends a UDP packet of at least 1024 bytes containing a 32-byte random nonce. Keeping the request large prevents the server from being used in amplification attacks: the reply is always smaller than the request.
2. Batch signing: the server gathers requests that arrive together into a Merkle tree and signs the tree root together with the time in one signature. Each client receives the path that links its own nonce to the root.
3. Key chain: the short-lived key that signs replies is regenerated every 24 hours and endorsed by the long-term key above (delegation). The long-term key does not change; clients only need to know that one.
4. Verification: the client checks the delegation, the signature and that its nonce is in the tree; if everything holds, it accepts the time.

Where it is used

Devices without a clock

Battery-less boards and devices booting for the first time cannot validate a TLS certificate without knowing the time, so NTS cannot start either. Roughtime only needs a public key known in advance: the device gets a signed, roughly correct time and then moves on to NTS.

Auditing time servers

A client asks several Roughtime servers in turn and derives each request's nonce from the previous reply. If one server states a time that contradicts the others, the contradiction can be proven to anyone with the signed replies.

Record and document integrity

If you send a document's hash instead of a random nonce, the reply becomes signed evidence that "this hash existed no later than this moment". We keep our own clock log on the same idea: see time proof.

Try it now

Any client that speaks the current version of the protocol (IETF draft, version 14) works. With a Rust toolchain installed:

cargo install roughenough-client
roughenough_client time.nerzen.com 2002 \
  -k BEbDQsYfxJjs6U1oFHoGthN4p/cvSFCVsyjpcqtNP0s=

Entry for clients that use a server list:

{
  "name": "time.nerzen.com",
  "version": "IETF-Roughtime",
  "publicKeyType": "ed25519",
  "publicKey": "BEbDQsYfxJjs6U1oFHoGthN4p/cvSFCVsyjpcqtNP0s=",
  "addresses": [{ "protocol": "udp", "address": "time.nerzen.com:2002" }]
}

Technical details

Limits

• Resolution is one second. Use NTP or NTS for precise synchronisation.
• One server is one witness. Roughtime's strength appears when several independent servers are asked; do not trust us alone.
• Not a legally qualified timestamp. A legally valid timestamp requires an authorised provider.
• A stamp proves an upper bound: "it existed no later than this moment". It does not show that it existed earlier.
• UDP only. Unreachable from networks that block 2002/udp.
• The standard is not an RFC yet. The protocol is still a draft; when the version changes the server will be updated and old clients may stop working.
• The server is stratum 2. The signed time is the same clock published on the measurements page; we have no primary clock of our own.

Frequently asked questions