[tor-bugs] #1926 [Tor Relay]: Extra-info descriptors have corrupt {write, read}-history lines

Tue Apr 17 11:07:13 UTC 2012

#1926: Extra-info descriptors have corrupt {write,read}-history lines
-----------------------+----------------------------------------------------
 Reporter:  karsten    |          Owner:  karsten           
     Type:  defect     |         Status:  new               
 Priority:  minor      |      Milestone:  Tor: 0.2.2.x-final
Component:  Tor Relay  |        Version:                    
 Keywords:             |         Parent:                    
   Points:             |   Actualpoints:                    
-----------------------+----------------------------------------------------

Comment(by karsten):

 I took another look at extra-info descriptors containing corrupt write-
 history lines, and I found an interesting pattern that I can't explain.

 A lot of the obviously wrong write-history timestamps still match the
 900-second period of the write history in the previous or subsequent
 descriptor.

 Here are some examples (fingerprint, descriptor publication time, write-
 history timestamp, *** for corrupt timestamp):

 {{{
 0A8B196D53B02CA93818B0258249C04A5CB60E39,2011-11-18 03:15:42,2010-11-18
 03:09:43 ***
 0A8B196D53B02CA93818B0258249C04A5CB60E39,2011-11-18 03:16:43,2011-11-18
 03:09:43

 3A64376144842654940E09C4D8CC3A5307536C1B,2011-11-09 14:13:20,2004-12-31
 23:01:45 ***
 3A64376144842654940E09C4D8CC3A5307536C1B,2011-11-09 14:17:24,2011-11-09
 14:16:45

 40257810D70D006D0B240D02727ED0C9636A45FA,2012-01-05 16:33:12,2008-07-18
 00:21:50 ***
 40257810D70D006D0B240D02727ED0C9636A45FA,2012-01-05 16:34:13,2012-01-05
 16:21:50

 4373CC0CFF1BAC0B91C61F6E1BF8998C8B6DE4EE,2011-12-19 10:26:13,2011-12-19
 10:22:38
 4373CC0CFF1BAC0B91C61F6E1BF8998C8B6DE4EE,2011-12-19 14:50:20,2011-12-13
 09:52:38 ***
 4373CC0CFF1BAC0B91C61F6E1BF8998C8B6DE4EE,2011-12-19 14:51:20,2011-12-19
 14:37:38

 4C2D42B29791347A9F94E52AB5B54CA1EF2A3F5F,2012-04-08 09:16:02,2002-01-01
 03:16:49 ***
 4C2D42B29791347A9F94E52AB5B54CA1EF2A3F5F,2012-04-08 09:17:03,2012-04-08
 09:16:49

 4C2ED83F581503D2DE73EE5DB11D5DAC20F7986C,2011-10-26 21:47:47,2011-10-26
 21:45:25
 4C2ED83F581503D2DE73EE5DB11D5DAC20F7986C,2011-10-26 22:25:03,1970-01-01
 00:00:25 ***
 4C2ED83F581503D2DE73EE5DB11D5DAC20F7986C,2011-10-26 22:26:36,2011-10-26
 22:15:25

 50C07527F812190CD2719125DB27F5A35E775536,2011-10-17 16:23:15,2010-10-17
 18:05:19 ***
 50C07527F812190CD2719125DB27F5A35E775536,2011-10-17 16:27:51,2011-10-17
 16:20:19

 56113F3CC4FBAF9E2F4E6B020E821CD170B15885,2011-11-22 16:27:39,2011-11-22
 16:14:41
 56113F3CC4FBAF9E2F4E6B020E821CD170B15885,2011-11-22 18:09:22,2011-11-18
 20:59:41 ***
 56113F3CC4FBAF9E2F4E6B020E821CD170B15885,2011-11-22 18:10:20,2011-11-22
 17:59:41
 56113F3CC4FBAF9E2F4E6B020E821CD170B15885,2011-11-22 18:24:28,2011-11-18
 20:59:41 ***
 56113F3CC4FBAF9E2F4E6B020E821CD170B15885,2011-11-22 18:25:32,2011-11-22
 18:14:41

 72F69E6B3575BA258758E5B3FC749D01950210B4,2011-11-19 16:45:23,1999-12-31
 23:30:40 ***
 72F69E6B3575BA258758E5B3FC749D01950210B4,2011-11-19 16:46:22,2011-11-19
 16:45:40

 8875C1AA54E9DA0C2F79AE7E21F03218BC5086F7,2012-02-12 22:45:22,2012-02-12
 22:35:47
 8875C1AA54E9DA0C2F79AE7E21F03218BC5086F7,2012-02-27 01:12:02,2012-02-04
 02:35:47 ***
 8875C1AA54E9DA0C2F79AE7E21F03218BC5086F7,2012-02-27 01:13:03,2012-02-27
 01:05:47

 8DE5D6A67DD16A9C6EABB7EFC69BB81B6E26FCB6,2012-02-07 18:58:01,2005-04-06
 02:21:18 ***
 8DE5D6A67DD16A9C6EABB7EFC69BB81B6E26FCB6,2012-02-07 18:58:09,2012-02-07
 18:51:18

 95C8F4A0C6262FD4B4CAF7D43F446026D35B8C86,2011-12-14 15:34:15,2011-05-14
 15:19:09 ***
 95C8F4A0C6262FD4B4CAF7D43F446026D35B8C86,2011-12-14 15:35:15,2011-12-14
 15:34:09

 97DAAF5C00A4B1E28ED0E9306C59D50E9C6DFC77,2012-01-03 22:32:10,2000-01-01
 07:16:13 ***
 97DAAF5C00A4B1E28ED0E9306C59D50E9C6DFC77,2012-01-03 22:33:22,2012-01-03
 22:31:13

 9CD2B1E09B76503B6ADC0EB90DD399DEC7A3CE76,2011-12-11 18:37:55,1970-01-01
 00:15:42 ***
 9CD2B1E09B76503B6ADC0EB90DD399DEC7A3CE76,2011-12-11 18:39:39,2011-12-11
 18:30:42

 9CD2B1E09B76503B6ADC0EB90DD399DEC7A3CE76,2012-03-26 09:58:20,1970-01-02
 21:30:41 ***
 9CD2B1E09B76503B6ADC0EB90DD399DEC7A3CE76,2012-03-26 10:00:29,2012-03-26
 09:45:41

 A153374361E53C21C673485F65A43E33CAA252D7,2012-02-19 17:58:29,2000-01-01
 00:23:51 ***
 A153374361E53C21C673485F65A43E33CAA252D7,2012-02-19 17:59:30,2012-02-19
 17:53:51

 B47ED35EAD03C6D594A2A0ED1DD807EE5FF69F41,2011-11-10 00:03:16,2010-09-16
 23:01:00 ***
 B47ED35EAD03C6D594A2A0ED1DD807EE5FF69F41,2011-11-10 09:20:28,2011-11-10
 09:16:00

 E163C7D1A1C187EF946EA06732398D1CDC0C9186,2011-10-12 14:03:49,2006-02-09
 22:05:28 ***
 E163C7D1A1C187EF946EA06732398D1CDC0C9186,2011-10-12 14:05:51,2011-10-12
 14:05:28
 }}}

 That means that corrupt timestamps aren't entirely random.

 My first thought was that there are single corrupt bits.  But that's
 unlikely/impossible if we look at the binary representation of, say, the
 first two dates above:

 {{{
 2010-11-18 03:09:43 = 01001100 11100100 10011000 11110111
 2011-11-18 03:09:43 = 01001110 11000101 11001100 01110111
 }}}

 So, there's something else changing the "2011" to "2010" after formatting
 the timestamp string.  I'm running out of ideas what that could be.

 And why are quite a few of the relays publishing another descriptor 1 to 5
 minutes after the one containing a corrupt timestamp?  (Note that
 directory authorities must have accepted these descriptors, or we wouldn't
 have them in the archives.)

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1926#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online