> Specifically a client can generate a unique 128-bit nonce and have the > trusted server timestamp it by signing a message including the nonce and the > current time T. If the time between the request and the reply was dt, the > actual time must be in the range (T, dt) > > We can then extend this to an arbitrary number of clients with a merkle tree > and one or more levels of untrusted servers. The servers combine all the > nonces they receive in some time interval t into a merkle tree, then > timestamp the digest of the tip of that tree. The clients then receive the > merkle paths from the server, a proof of log2(n) size. I'm not sure if I understand you correctly. Do you mean that a time server will store the nonces of all requests from different clients in a given period and afterwards publish a merkle tree of these requests with a signed root node? I think this approach would have roughly the same computing overhead as our approach: one asymmetric signature per time period vs. one asymmetric signature per client and then ~2 hashes per time request vs. 3 in our approach.
> If a client doesn't trust the server at all, they know the time is within (T, > dt); if they are willing to place some trust in the server the server can > measure the interval between when they got the request and sent the proof, > dt', and the client can take that into account for a more precise time. If the server is not trusted, what prevents him from lying to the client and just forging some merkle tree in this case? _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
