confusion about RELAY EXTEND cell payloads & other little Tor questions

[Nick Mathewson]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070117/1cc6c8f9/attachment.pgp>