On Tue, May 20, 2003 at 01:37:09AM +0200, kjellrs at stud.ntnu.no wrote: > Hi! > > Presumably this post belongs in the tech section, but I didn't see much > except SPAM in the archives. Didn't see anything like it in the devl archives > either, so here goes. > > This is about HTL 25 and identification of the nodes inserting and requesting > informations. To achieve maximum reach, most programs will increase the HTL > on both gets and inserts to 25 if needed. The problem with this is that this > also means the node using that is also the originating node, since the > default HTL max limit is 25, and so any neighbouring node could monitor them. > I wonder whether this problem could be solved by not making HTLs absolute, > but rather probabilistic. This means that a server will decrease HTL with 1 > with a probability p%, or pass it on with same HTL with probability (1-p%). > In fact, I'd consider it a good thing for the entire HTL system as it makes > nothing certain about the number of hops to or from anything, making trafic > analysis difficult. However, to keep it from being too varying, it should be > less and less likely the lower the HTL. I've played around a bit with the > numbers in Excel with @RISK and came up with a TTL (time to live) formula > that g > ives results like this:
Actually, it needs to have an increasing probability for really low HTLs to avoid node probing. We currently have a 30% or so chance of not decrementing the HTL at 1, which rapidly tails off and is insignificant when you get to the starter HTLs you are talking about. Also, the HTL of queries is randomized a bit before they are started in the current codebase - a request at HTL 25 may end up as HTL 22. > > New Old (5%th-95%th percentile) > TTL 5 = HTL 5 (HTL05-05) > TTL 10 = HTL 10 (HTL10-11) > TTL 15 = HTL 16 (HTL15-18) > TTL 20 = HTL 25 (HTL21-29) > > Chance that a TTL20 insert/get is the original inserter/requester: 47% > Chance that a TTL19 insert/get is next to inserter: 22% > > Tranlation: Finding the original inserter will be a really big bitch. The problem is that sometimes people download large bunches of files at once, e.g. splitfiles or large freesites, so the attacker will be able to do statistical attacks. The solution is something called premix routing, where we use something resembling mixmaster so that the first two hops are random, the first hop knows the originator of the request but not the key, and the second knows the key but not the originator. > > Pseudocode: IF(OldTTL^3/15000 < RAND()) THEN NewTTL = OldTTL ELSE NewTTL = > OldTTL-1, where RAND() is a random number between 0 and 1. Hrmm. > > Potentially, the transition could be fairly easy, if the new nodes simply > reduce HTL > 20 to TTL 20 and pass it on. while old nodes use the same as > HTL. In a worst case scenario, you lose 5 hops HTL 25 -> TTL 20 -> HTL again > (or gain 5, if you get both HTL 25->20 + TTL hops). > > My java knowledge is less than stunning, but I think the idea is sound and > the numbers good. Let me know what you other people think, and if you are > interested. I could try to implement it myself, but I'd probably introdouce a > dozen Heisenbugs in the process, so suggest that at your own risk :) Hrmm. > > Kjella -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20030520/ffb7705a/attachment.pgp>
