Scott Bennett wrote:
On Thu, 23 Jul 2009 17:32:27 -0400 Niels Elgaard Larsen <elga...@agol.dk>
wrote:
Yes, that was why i suggested only using it to set the time zone by
changing the clock a number of hours.
I don't think that would be good enough to satisfy tor's requirements
for time consistency.
No, but what i meant was that if the system time is wrong, there is a
good chance that it is a time-zone mismatch in which case adjusting a
clock a multiple number of ours should be safe.
Using an average of three entry-nodes could also work. Maybe add a
little random time.
Actually, no, three would not be enough, but statistical quality
control of some sort would be necessary. First off, this kind of thing
should be a last resort option, not a common approach.
Well, if done right it could be a good way for the client to set it time.
...
GPS or DCF77 would be good, but requires hardware.
Right. Those are no good in this situation.
But GPS might be an option on e.g. Android platforms in the future.
Exactly. Also, NTP is not encrypted, so an observer would know the
set of time values from which one value would be used by the client.
Lest another point be forgotten, the methods of determining the correct
time that we are discussing here would only be available in the case of
client operations. tor should still not set a clock or offset itself if
it is to run as a relay.
No, but maybe a hidden node
