On Thursday 03 January 2008 01:17, Michael Rogers wrote: > Matthew Toseland wrote: > > - It should be possible with such a simple request/response to make it > > extremely difficult for two nodes to realise they are on the same path, > > except in the case where they are actually adjacent. > > I think that's optimistic - they could use the tunnel construction time, > or the delay between the tunnel being constructed and used, or (for > two-way tunnels) the delay between the request and the response. > > Let's say the attacker controls the exit node of tunnel X, and it > normally takes 5 seconds to construct a tunnel. If an interesting > request is sent through tunnel X, all the attacker's nodes record > predecessor samples for any outgoing tunnels constructed in the 5 > seconds before tunnel X was constructed, and successor samples for any > incoming tunnels constructed in the 5 seconds after tunnel X was > constructed. It doesn't matter that most of the samples are wrong - all > that matters is that the initiator is more likely to be recorded than a > random node (or a random member of the cell).
Okay, so it's a predecessor sample, a very noisy source, but it will eventually reveal the originator if one of the attacker's nodes is connected to it. And the frequency data will also eventually show nodes close to the originator but not equal to it. So suppose we use long lived tunnels. Tagging on long-lived tunnels is trivial. So we have a high quality sample on every new tunnel. It will be essential to have multiple tunnels for adequate performance and reliability. What is the impact of the node creating two parallel tunnels each through one of its peer nodes which is run by the attacker? If he can link them, there is still the possibility that they are both from intermediary nodes from another originator - but this is probably less likely than the node being the originator, so if we have any long term data we can catch him. What about tunnel padding? I know a lot of people think this is impossible, and it would be a performance issue, but here's a proposal I made a while ago; as far as I can see, it would make tagging impossible except when we have on the chain attacker - relay - attacker. ----------------------------------------- For each tunnel, we send exactly one 512 byte packet every second. This has a 16-byte MAC internally, and externally has a flag. The former is encrypted, and generated by the endpoint; the latter is readable as plaintext by the node we forward the packet to. There may also be an external MAC, and an internal sequence number, but these are irrelevancies. If the internal MAC is invalid on a packet, the endpoint silently drops the packet. The external flag is true if the packet was forwarded (usually), and false if it is bogus. If in a second we need to send a packet down the tunnel, and we don't have a packet to send, we send a bogus packet. We generate a random 512 byte packet, including the MAC, and send this to the next hop, with the flag turned on. If in a second we have too many queued packets to send, we drop one. If we know some are bogus, we preferentially drop them. Now, when we forward a bogus packet, we make it un-bogus. All we have to do is turn the flag back off. Thus, the next node on the chain can identify that the packet was bogus, but this is irrelevant because he knows he is on the same tunnel anyway, if both nodes are run by an attacker (duh!). If the two nodes are not in direct line on the tunnel, then it is very difficult for them to establish that they are on the same tunnel (admittedly there are setup timing issues and so on; these can be solved by having tunnel setup take a long time). This wipes out a huge swathe of attacks. Admittedly it does so at a considerable cost in bandwidth! ---------------------------------------------------- > > If the attacker knows that tunnels always contain more than two nodes > and don't pass through any node more than once, he can also eliminate > samples from the exit node and its immediate neighbours. But that's not > vital, it just reduces the level of noise. > > > However, it *is* > > known that it is one of the nodes along that path that is the problem, and > > this may be enough. > > Yup, if we can trust the topological information then we should be able > to identify unreliable nodes and avoid using them in tunnels (but on the > other hand that allows an attacker to attract more tunnels and thus > gather more samples by performing well, as in I2P).
pgpaedwOcHy0c.pgp
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
