Check out the different parts:

  • Part I: protocol for a cryptographic desk clock (this page)
  • Part II: time reference
  • Part II: agreement protocols
  • … sometime in the future … client implementation

Slightly annoying fact: clocks are normally synced with a protocol (NTP - Network Time Protocol) that provides zero cryptographic guarantees. On the surface this is totally fine, but when we start composing security-sensitive protocols (think certificate expiration checks, audit logs or time-bound credentials), we need to turn a blind eye…

Not today! let’s build a simple cryptographic desk clock to set the House Standard Time in proper cryptographic fashion. Here is the limited edition, mission-critical clock sitting in my home office:

Protocol #

The protocol we’ll be using for clock synchronization is roughtime. This is a pretty new protocol introduced in by Adam Langley (Google). It’s pretty barebones, and simple enough you can write a client in an evening — so much fun.

roughtime is essentially a challenge-response protocol. The client sends a random 32-byte challenge to the server, which replies with a signed message containing the client challenge and the current time. (There’s some machinery to make this efficient, like packing requests in a Merkle tree, but this isn’t important now.)

Since you’re probably familiar with NTP, here are the key differences:

  Roughtime NTP
Target time precision Coarse: ~seconds. Fine for human consumption, certificate expiration Excellent. Sub-second
Security model Excellent. Architecture tolerates a few actively malicious servers, no SPOF. Network is considered untrusted: packets are cryptographically protected Bad. Network is assumed trusted (there are some extensions for adding a secure transport layer)
Protocol maturity Very new, although very simple and solid Golden standard
Software/libraries availability Bad. DIY land, mostly one-off efforts that get abandoned. Mostly targeting beefy machines, almost nothing for embedded targets Excellent, very mature. Reference implementation has been maintained for 20 years, multiple implementations
Software/libraries quality Good. Mostly written in memory safe languages Vary a lot
Server ecosystem maturity Very bad. Highly concentrated, few players. Main developer (Google) seems to have abandoned development. Cloudflare runs servers. Google is still offering this without any availability guarantees Very good. There are global pools of NTP servers.
Who uses it? Current deployments ??? probably a few nerds, unclear Virtually everywhere., etc
Client code complexity apart from crypto, easy very easy if high precision isn’t required, high otherwise. Reference implementation is extremely complex 100k LoC of C
Suitable for embedded? Suboptimal. The public-key signature scheme is ed25519, which is notoriously RAM-hungry, plus needs SHA512 code yes
History, context, motivation Introduced in 2016 by Adam Langley (Google) to solve Google needs. Little public involvement after initial release Introduced around 1985 by Dave L. Mills, who continued improving it on a life-long effort
Algorithms Marzullo, ed25519, Merkle trees Marzullo, phase-locked loop