...Protocol

Most of this work was done at UC Berkeley and IBM Research. The authors can be reached at
adrian+@cs.cmu.edu, canetti@watson.ibm.com,
tygar@cs.berkeley.edu, skyxd@cs.cmu.edu.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...sender.

The security of this time synchronization protocol relies on the unpredictability of the nonce - if an attacker could predict the receiver's nonce, it could send a time synchronization request to the sender with that nonce, and replay the response later to the receiver.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...nonce.

Interestingly, the processing and propagation delay of the response message does not change $\delta$ (assuming that the sender immediately records and replies with the arrival time of the request packet), since the receiver is only interested in an upper bound on the sender's clock. If the receiver were interested in the lower bound on the sender's clock, the processing delay and delay of the response message would matter. For more details on this refer to the more detailed time synchronization description [30].

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...created.

For details on how to handle broadcast streams of unbounded duration by switching one-way key chains, see [27]. For this article we assume that chains are sufficiently long for the duration of communication.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...resistance.

See our earlier paper for a formal security proof [28].

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.