Subject: Re: fwd: i2p tunnel bootstrap attack - msg#00129

Previous Message by Date: (click to view message preview)

Re: fwd: i2p tunnel bootstrap attack

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Regardless of the fact that Bob doesn't know the contents of the > > last four messages, the fact that he sees four messages immediately > > after joining the tunnel tells him there are two hops after him. > > Going back to the assumption that the length is three hops, Bob now > > knows Alice created the tunnel. > > This could be solved by padding the traffic between the gateway and the > endpoint to a constant rate, but obviously that could be expensive. CBR just moves the information around - if you CBR for either the full lifetime of the tunnel or for the first e.g. 60 seconds, the attacker just uses the lifetime of the CBR activity to derive their position (the first hop will have 60 seconds of CBR, the second 59, the third 58, etc). Plus there's that whole cost thing, as you say :) =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDXjSJWYfZ3rPnHH0RAqw+AJ9Ak5YnGCdg5Lfbu0YBZtHA0AxtfQCbB0v/ ymfMj0Z7mIhVnllkTfYvyXg= =9zMp -----END PGP SIGNATURE-----

Next Message by Date: click to view message preview

Re: fwd: i2p tunnel bootstrap attack

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks Michael, this sim data is really helpful - its good to quantify the threats to keep some perspective. > Looks like the attack isn't a major threat as long as m and c are > small. Well, even if m and c are large they're better than the c/n of a plain telescopic tunnel. I think we may be able to get around that though, which would remove the c/n attack, leaving your analysis as the lowest hanging fruit, so we'll want to revise tunnel creation accordingly. =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDXjlMWYfZ3rPnHH0RAm24AJ9uwsoPKMYrA2Nja+retmytk+RPmACeJ5uW cTtIqZThHAnNkJw8N+veKlI= =7jk5 -----END PGP SIGNATURE-----

Previous Message by Thread: click to view message preview

Re: fwd: i2p tunnel bootstrap attack

On Tue, Oct 25, 2005 at 12:44:23PM +0100, Michael Rogers wrote: > jrandom-Po2eaMWI3R0@xxxxxxxxxxxxxxxx wrote: > > Regardless of the fact that Bob doesn't know the contents of the > > last four messages, the fact that he sees four messages immediately > > after joining the tunnel tells him there are two hops after him. > > Going back to the assumption that the length is three hops, Bob now > > knows Alice created the tunnel. > > This could be solved by padding the traffic between the gateway and the > endpoint to a constant rate, but obviously that could be expensive. Hrrrm, okay... can't we make this one message, using a similar trick to the mixmaster? Mixmaster I think uses something vaguely like the following: We have a tunnel of length 3. So we have a datastructure with 3 elements - A, B, and C. Each element is as follows: - Session key, encrypted asymmetrically - Symmetrically encrypted: -- The identity of the node to forward to. -- The location of the node to forward to. -- The number of the next block to process. We also have, in plaintext, a number, indicating which block is next. So each node: - Knows which element belongs to it - Decrypts the session key from that element - Decrypts that element - Sees which element is next - Decrypts the new element using its own session key - Replace our own element with random data - Forwards everything to the next node So, on the first hop, A is immediately readable by node A. It tells it to decrypt B (obviously in reality we would randomize the order!), and send the whole package to B, having updated the plaintext pointer number. Node B sees that it is supposed to be decrypting element B, and does so. It then sees that it is supposed to be forwarding to node C, and that the next pointer is for element C, so it does likewise. So one message outwards, fixed size. Now, to return: We can reuse the pointers. We have a similar structure: 3 elements. Each contains a certificate encrypted with the session key established with that node. C fills in its own one, and blanks out the other two with random data. B does likewise, as does A. Then it goes back to the originator. One message inwards, fixed size. If we are sending error messages back along the chain, we can use the existing session keys etc, and there will only be one message. I don't see what the problem is here. That is, unless you can't use asymmetric encryption on each hop. But if you can't use asymmetric encryption on each hop, aren't you screwed anyway? *How else can you possibly do it?* > > Cheers, > Michael -- Matthew J Toseland - toad-EI5O+8PHWbJeeLb3ft/vUmD2FQJk+8+b@xxxxxxxxxxxxxxxx Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature _______________________________________________ i2p mailing list i2p-vxOoL5ZvrKHR7s880joybQ@xxxxxxxxxxxxxxxx http://dev.i2p.net/mailman/listinfo/i2p

Next Message by Thread: click to view message preview

Re: fwd: i2p tunnel bootstrap attack

On Tue, Oct 25, 2005 at 09:56:26AM -0400, jrandom-Po2eaMWI3R0@xxxxxxxxxxxxxxxx wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [cut] > > So one message outwards, fixed size. > [cut] > > One message inwards, fixed size. > [cut] > > Hmm, I like this. A lot. > > Beyond the statistical data, it'd cut down on spurious tunnel > creation failures too, as the only peers to blame for failure > would be peers in the tunnel. I'm not sure about the specifics of > what you describe, but its a promising direction. Isn't this precisely what mixmaster has been doing for the last 10 years? Also, it would be possible to do a timing attack. > > I'd like to keep these tunnels unidirectional if possible, both for > anonymity and topological reasons, but we could probably pull that > off: Well, I strongly agree with the basic principle of data tunnels being unidirectional. Now, as far as tunnel construction feedback goes - sure, include a preexisting tunnel to send the feedback to. The first few tunnels have the feedback go back along the chain; the rest use a couple of preexisting tunnels (different for each node, of course). However, I'm having doubts about the basic architecture of a scalable distributed any-to-any mixnet, but I've privately emailed you about that. > * the outbound tunnel endpoint of a newly created tunnel would take > the structure received (and rewritten by hops along the way), wrap > it in a garlic using a provided key, and forward it to the inbound > gateway of some other tunnel (which would in turn forward the > message down to the tunnel creator, where the rewritten data > structure is parsed and interpreted) Right. And if there is an error, you need a different inbound tunnel to send the error message to. So you need to include at least one for each node. > * inbound tunnels would simply have the data structure tunnel routed > to the inbound tunnel gateway (garlic encrypted). Inbound tunnels are constructed outwards, right? So what you're saying is that inbound tunnels would send the feedback back to the originator in-line as I described, and outbound tunnels would send it via a separate tunnel? > > This would mean the outbound tunnel endpoint and inbound tunnel > gateway would talk to a peer not in the tunnel, but, well, thats > their *job* - they talk to peers not in the tunnel. Peers further > inside the tunnel would only talk to their predecessor and > successor. > > Hmm... > > =jr -- Matthew J Toseland - toad-EI5O+8PHWbJeeLb3ft/vUmD2FQJk+8+b@xxxxxxxxxxxxxxxx Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature _______________________________________________ i2p mailing list i2p-vxOoL5ZvrKHR7s880joybQ@xxxxxxxxxxxxxxxx http://dev.i2p.net/mailman/listinfo/i2p