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

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

Re: GCJ support is on the way

Ugh. We're using generateSeed(). And IIRC we don't add anything to the entropy estimate. On Tue, Oct 25, 2005 at 12:18:53PM -0400, jrandom-Po2eaMWI3R0@xxxxxxxxxxxxxxxx wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Of course, further sources to seed the PRNG on first install would > > > be good. Who knows, perhaps some timing / execution information > > > during the installer to generate a prngseed.rnd file. > > > > /dev/urandom you already use; IMHO you should use SecureRandom too if it > > is available as it's the easiest way to get to CAPI on Windows. > > Agreed, worth doing, though java.security.SecureRandom doesn't > always do the trick [1]. > > [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481 > > =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

Next Message by Date: click to view message preview

Re: fwd: i2p tunnel bootstrap attack

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > It would also work without a teardown message as long as the CBR > traffic followed immediately behind the tunnel construction > message rather than waiting for a reply, and the nodes started > their timers when they processed the tunnel construction message. Ah, true. > For bursty traffic that's true, but for traffic that does a pretty good > job of filling the pipe anyway (like BitTorrent) there's not much > overhead. But I take your point - it's not worth the overhead in the > general case. Unfortunately, even with BT you've got a mismatch on peer capacities, meaning tunnels have different CBR rates, which drops the cover of using CBR to the subset of tunnels using the same rate as you. And then there's the trivial pipenet DoS (aka stop transmitting data). Though, as always, it depends upon your threat model - perhaps the added protections of a group of K peers with the same CBR is sufficient. =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDXl5iWYfZ3rPnHH0RAs5hAJ43QrJniqxkT7pWcZ2MohDXVd7hVACfY4gF gmBEjOl+U1RAiwZ6xrL1Z5g= =VxDP -----END PGP SIGNATURE-----

Previous 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

Next Message by Thread: click to view message preview

Re: fwd: i2p tunnel bootstrap attack

On Tuesday 25 October 2005 8:56 am, jrandom-Po2eaMWI3R0@xxxxxxxxxxxxxxxx wrote: > [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. > > I'd like to keep these tunnels unidirectional if possible, both for > anonymity and topological reasons, but we could probably pull that > off: > * 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) > * inbound tunnels would simply have the data structure tunnel routed > to the inbound tunnel gateway (garlic encrypted). > > 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... I always assumed that this was what was meant by telescoping tunnels. I thought the objection was that it puts a bound on the maximum tunnel length. If the first and last hops are evil, they can do a timing/message counting attack to find out they are in the same tunnel, and if the tunnel is of the maximum length, then they know both the owner and who they are talking to. ( This occurring with in proportion to (c/n)^2 )