On Wed, Jan 17, 2007 at 11:22:30AM -0800, Christian Seberino wrote: > > >> Yet in another place it says Relay *EXTEND* cell payloads consist of: > >> > >> address > >> port > >> onion skin > >> indentify fingerprint > > > > Those are the "data" in a relay cell. > > Thanks! You may want to consider changing wording to refer to this in > spec as 'data' rather than 'payload'. We use 'payload' to mean either the payload part of a cell, or the payload part of a relay cell. See the paper, for example in the section titled "Cells". This could probably be clearer in the spec, though; feel free to submit a patch. [...] > > you can have a > > running SHA1 hash of a stream of bytes, and the intermediate hash values > > are meaningful. > > > > See tor-design.pdf for more details about the integrity-checking hashes. > > I read section '4.4 Integrity checking on streams' in design doc. If I > understand correctly, we have an initial derivative hash based on result > of Diffie-Hellman exchange. Routers keep appending all Relay cells to > that initial derivative hash to create new hashes whose first 4 bytes form > digest fields. > > In order to keep calculating this running digest, it appears ALL Relay > cells must be saved for entire lifetime of session. Why? Because how else > can you calculate the current digest? Because SHA1 works that way. The SHA1 state is (IIRC) 160 bits: if you have the state after the first N bytes of data, you can compute SHA1(N|M) using only the state and M. Thus, if you know the SHA state after a bunch of relay cells, you don't need to store those cells in order to compute the state in the future: you only need to store the current state, and observe more cells as they come in. SHA1 is documented in RFC 3174; the wikipedia page has a nice pretty diagram; there is code for it all over the web. One of those sources would probably be useful. peace, -- Nick Mathewson
Attachment:
pgp0YTyMgK7jX.pgp
Description: PGP signature