Subject: [saag] Roughtime (Was: software update for teeny-weeny devices)

From: Jeffrey Walton <[email-masked]>
Date: Mon, 17 Oct 2016 20:48:09 -0400

>> Our story for
>> providing time securely to these device isn't that great either since
>> NTP again assumes that you have been configured with the correct time.
>
> How so?
>
> BTW, are you aware of roughtime? https://roughtime.googlesource.com/roughtime

I'm not sure this is entirely correct: "There are essentially only two
ways to achieve this [accurate or fresh time]: nonces or synchronised
clocks.".

If I am on a train with 100 other people or a stadium with 500 people
around me, then it seems like a gossip protocol would be able to
provide the correct time also.

The crowd always seems to converge on the right answer regardless of
how wrong one sampling is. I've been looking for a paper that explains
it for a couple of years now.

Jeff

---

From: Tony Finch <[email-masked]>
Date: Tue, 18 Oct 2016 10:40:37 +0100

> it for a couple of years now.

I did some brief and sketchy experiments along these lines a few years
ago, but instead of a gossip protocol I was looking for consensus of
opinion across many authenticated (but not individually trusted) time
sources. Basically, a wrapper around tlsdate that samples several servers
and looks for the mode.

http://fanf.livejournal.com/128861.html
http://fanf.livejournal.com/129371.html

I am interested if anyone has properly analysed how much security we can
expect to get from this kind of consensus.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
North Fitzroy, Sole: Northwesterly 4 or 5, occasionally 6 in Sole, becoming
variable 3 or 4. Moderate or rough. Fair. Good.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 18 Oct 2016 11:00:38 +0100

> ways to achieve this [accurate or fresh time]: nonces or synchronised

"this" is actually "ensure that information is 'fresh' in secure
protocols", not accurate time.