On Sep 29, 2011, at 20:15 , Stephan Beal wrote: > Given the relatively high overhead fossil has when it opens a db or runs a > query, and network latency, i cannot imagine that someone could accurately > time the difference of a memcmp() operation on 8 or 10 bytes. The number of > factors involved before and after COMPARE is called are just too great. As > was written in the post about sha1 collisions someone linked to earlier: the > chances are higher that all of the members of your dev team will be killed by > wolves in separate incidences on the same night.
I posted a link about this concern: http://rdist.root.org/2010/01/07/timing-independent-array-comparison/ "The other misconception is that jitter is too great to get anything useful out of the measurements, especially in a network. There is an excellent paper by Crosby and Wallach* that debunks this myth by carefully analyzing noise and its causes as well as how to filter it. They conclude that an attacker can reliably detect processing differences as low as 200 nanoseconds on a LAN or 30 microseconds on a WAN given only 1000 measurements. If your server is hosted somewhere an attacker can also buy rackspace, then you are vulnerable to LAN timing attacks." *) http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf -- Dmitry Chestnykh _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
