On Thu, 23 Jul 2009 17:32:27 -0400 Niels Elgaard Larsen <elga...@agol.dk> wrote: >Watson Ladd wrote: >> Niels Elgaard Larsen wrote: > >>> On the other hand it would work better for eg. TOR browser bundle. >> It would enable an entry guard to give a different time to a client, and >> so distinguish that client's connections to sites of interest via >> protocols that use a timestamp sent in the clear. > >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. > >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. Second, choosing a random sample size within a certain range would help. Maybe limiting the contacts to guards in this case should be dropped, allowing a much larger set of relays to be queried for the correct time. Then computing the mean and standard deviation would allow the client to disregard any outlier timestamps that might represent an attack, based upon some set limit, say, 1/4 sigma, but that the entire sample set would be discarded if the variance were too large relative to the mean and a new sample set constructed. Also, it should be obvious that the data collection could not be done over DirPort connections. Another irritating problem is that a tunneled connection probably would entail delays too lengthy to use for setting a time, so an observer seeing a set of direct connections during startup numbering in the range of acceptable sample sizes could make a shrewd guess as to whether the client were determining the correct time or were building tunneled connections for fetching consensus and directory updates. > >Because what is the alternatives for setting time? > >GPS or DCF77 would be good, but requires hardware. Right. Those are no good in this situation. > >Having users setting it from other sources would work, but not is very >user friendly. Especially on a live-cd where we do not even know the >local timezone, we would have to let the user also input the timezone or > ask what time it is in London now. Yup. A discouragingly large fraction of the user population would probably not understand how to set the time, even if told. :-< > >NTP is an option, but if used without authentification it also opens up >for the attack you described. For an organization or a country >controlling an entire network it would be easy to change timestamps in >flight. NTP is even worse because you could change the clock many times >during a session. And which NTP-servers with authentification would you use? > 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. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************