On Tue, Mar 29, 2005 at 10:15:13AM +0600, RM wrote: > Hello! > > I see there are quite frequent new releases of TOR, but each time > while reading changelogs I am being disappointed by absence of > progress or any mention of the 512-byte cell size issue: > http://wiki.noreply.org/wiki/TheOnionRouter/TorFAQ#head-b3e179ffbc51549f04f4ad6ece966d34919c44f7 > > I have recently told about tor a couple of my friends, they are very > interested in using it (mostly for IRC), but like me, can't do this > because of its large traffic consumption. Is this an issue for you in practice? Sure, there is inflation on short-chunked protocols like IRC, but IRC is not a very high-bandwidth protocol to begin with. Have you tried this and run into problems, or does it just seem worrisome in theory? In practice, it seems that most high-bandwidth protocols are pretty good at filling up their cells. > So, I have a idea/question: is it possible to create a special version > of TOR that would exchange data between MY computer and the ENTRY tor > node in arbitrary-sized cells (or at least perhaps in 16 or > 32-bytes-long cells?) Would this require such version to be installed > on the remote side(entry node), too? Yes, it would require changes to the entry node. Also, as the protocol is today, it basically requires that *some* cells be at least 256-512 bytes in length, in order to fit the cells that set up circuits. So it wouldn't be just a matter of changing the cell size for your own version; you'd have to make the architecture significantly more complex to allow cells of different lengths. It would also require changes to the other nodes in the network: relay cells (the ones that contain data) can't be completely decrypted until they reach the exit node, so all the servers in between would need to learn about cells of the new length too. Plus, there might be anonymity implications. If you use 32-byte cells and I use 64-byte cells, it is easier to tell us apart than if we use cells of the same size. So yeah -- that's about why we haven't done it so far. It's pretty hard, and we're not sure it's a good idea. yrs, -- Nick Mathewson
Attachment:
pgpr9jMiKkayN.pgp
Description: PGP signature