Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Roughtime: a protocol for secure, auditable time synchronisation

imperialviolet.org

Post reply on HN
Print view View original

1–10 of 17 posts

Re: Roughtime: a protocol for secure, auditable time synchronisation

#3

Post by agl »

zmanian wrote: post #2

This is awfully similar to Ben Laurie's good ideas about how to run a distributed time stamping service for a cryptocurrency. http://www.links.org/files/distributed-currency.pdf Great to see these ideas used for general security applications.

(Ben was involved in the design of Roughtime.)

Re: Roughtime: a protocol for secure, auditable time synchronisation

#4

Post by amluto »

I'm curious why the clients chain requests but the servers don't chain replies. It would be straightforward for servers to emit a CT-style log as they go, thus forcing servers to prove that all their timestamps are in order. With a bit of refinement, it would also allow servers to prove that they didn't generate, say, Thursday's timestamp prior to learning a nonce that was sent to them on Wednesday. If nothing else, this would substantially strengthen its use as a timestamping service.

Also:

> It is the case that the signature, even assuming one request per batch, will add some number of microseconds of latency to the reply. Roughtime is not going to displace PTP for people who care about microseconds.

I'm not convinced that this should prevent extremely precise timestamping a la PTP. The server just needs to indicate, outside the signature, how long its processing took. Sure, this prevents authentication of the fine-grained time, but a client could easily bound the amount that a server can cheat.

Re: Roughtime: a protocol for secure, auditable time synchronisation

#5

Post by zmanian »

agl wrote: post #3
zmanian wrote: post #2

This is awfully similar to Ben Laurie's good ideas about how to run a distributed time stamping service for a cryptocurrency. http://www.links.org/files/distributed-currency.pdf Great to see these ideas used for general security applications.

(Ben was involved in the design of Roughtime.)

Just intended to point out this is a great example of the general applicability of crytocurrency inspired research.

Re: Roughtime: a protocol for secure, auditable time synchronisation

#6

Post by marknadal »

This is great, I work in distributed systems and am always dealing with wall clocks. Most people ignore/forget about clock sync or reject using wall clocks entirely because of it. But you can get very practically reasonable results by thinking these things through and doing sync. I'm glad to see other people doing more work on improving and validating NTP servers.

Re: Roughtime: a protocol for secure, auditable time synchronisation

#7

Post by pcl »

amluto wrote: post #4

I'm curious why the clients chain requests but the servers don't chain replies. It would be straightforward for servers to emit a CT-style log as they go, thus forcing servers to prove that all their timestamps are in order. With a bit of refinement, it would also allow servers to prove that they didn't generate, say, Thursday's timestamp prior to learning a nonce that was sent to them on Wednesday. If nothing else,…

I'm curious why the clients chain requests but the servers don't chain replies.

One challenge would be around server scale -- for the servers to maintain a strict chain, they would need to coordinate amongst themselves, which can be costly. The proposed approach doesn't introduce that requirement.

But they could get close by maintaining a branching history, like what you might see in a git history, or a vector clock. Neither of those approaches provides the same causality assurances as your proposal, but either would provide something close without incurring any blocking server-side state management.

Re: Roughtime: a protocol for secure, auditable time synchronisation

#9

Post by amluto »

pcl wrote: post #7
amluto wrote: post #4

I'm curious why the clients chain requests but the servers don't chain replies. It would be straightforward for servers to emit a CT-style log as they go, thus forcing servers to prove that all their timestamps are in order. With a bit of refinement, it would also allow servers to prove that they didn't generate, say, Thursday's timestamp prior to learning a nonce that was sent to them on Wednesday. If nothing else,…

I'm curious why the clients chain requests but the servers don't chain replies. One challenge would be around server scale -- for the servers to maintain a strict chain, they would need to coordinate amongst themselves, which can be costly. The proposed approach doesn't introduce that requirement. But they could get close by maintaining a branching history, like what you might see in a git history, or a vector clock.…

I just meant for servers to maintain a local chain. Cross-server checking would be free, sort of, as clients that talk to multiple servers would inject the chain state from the first server into the second via their nonces.

Re: Roughtime: a protocol for secure, auditable time synchronisation

#10

Post by rarrrrrr »

SpiderOak might be interested in running a Roughtime service / participating in a Roughtime community to support Semaphor.

As it is, Semaphor clients include a local timestamp among the signed content of most actions, and the server rejects actions that aren't within some tolerance (strict ordering however is accomplished via hash chain.) Roughtime would allow improving this situation from several angles.

One of the logistical challenges is client network traffic footprint. Enterprises that deploy a collaboration solution often want to have a strict definition of which upstream servers it can be expected to talk to. Would it be possible for a single Roughtime service to incorporate verifiable information from a larger Roughtime community, such that end user clients don't have to communicate with additional addresses?

Post reply on HN