[i2p] weekly status notes [jan 18]
jrandom
jrandom at i2p.net
Tue Jan 18 12:30:27 PST 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, weekly update time
* Index
1) Net status
2) 0.5
3) i2pmail.v2
4) azneti2p_0.2
5) ???
* 1) Net status
Hmm, not much to report here - things still work as they did last
week, size of the net is still pretty similar, perhaps a little
larger. Some neat new sites are popping up - see the forum [1]
and orion [2] for details.
[1]http://forum.i2p.net/viewforum.php?f=16
[2]http://orion.i2p/
* 2) 0.5
Thanks to the help of postman, dox, frosk, and cervantes (and
everyone who tunneled data through their routers ;), we've
collected a full day's worth of message size stats [3]. There are
two sets of stats there - height and width of the zoom. This was
driven by the desire to explore the impact of different message
padding strategies on the network load, as explained [4] in one of
the drafts for the 0.5 tunnel routing. (ooOOoo pretty pictures).
The scary part about what I found digging through those was that by
using some pretty simple hand-tuned padding breakpoints, padding to
those fixed sizes would still ended up with over 25% of the
bandwidth wasted. Yeah, I know, we're not going to do that.
Perhaps y'all can come up with something better by digging through
that raw data.
[3] http://dev.i2p.net/~jrandom/messageSizes/
[4] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/
tunnel.html?rev=HEAD#tunnel.padding
Actually, that [4] link leads us into the state of the 0.5 plans for
the tunnel routing. As Connelly posted [5], there has been a lot of
discussion lately on IRC about some of the drafts, with polecat,
bla, duck, nickster, detonate and others contributing suggestions
and probing questions (ok, and snarks ;). After a little more than
a week, we came across a potential vulnerability with [4] dealing
with an adversary who was somehow able to take over the inbound
tunnel gateway who also controlled one of the other peers later in
that tunnel. While in most cases this by itself wouldn't expose the
endpoint, and would be probabalistically hard to do as the network
grows, it still Sucks (tm).
So in comes [6]. This gets rid of that issue, allows us to have
tunnels of any length, and solves world hunger [7]. It does open
another issue where an attacker could build loops in the tunnel, but
based on a suggestion [8] Taral made last year regarding the session
tags used on ElGamal/AES, we can minimize the damage done by using
a series of synchronized pseudorandom number generators [9].
[5] http://dev.i2p.net/pipermail/i2p/2005-January/000557.html
[6] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/
tunnel-alt.html?rev=HEAD
[7] guess which statement is false?
[8] http://www.i2p.net/todo#sessionTag
[9] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/
tunnel-alt.html?rev=HEAD#tunnel.prng
Don't worry if the above sounds confusing - you're seeing the
innards of some gnarly design issues being wrung out in the open.
If the above *doesnt* sound confusing, please get in touch, as we're
always looking for more heads to hash through this stuff :)
Anyway, as I mentioned on the list [10], next up I'd like to get the
second strategy [6] implemented to hash through the remaining
details. The plan for 0.5 is currently to get all of the backwards
incompatible changes together - the new tunnel crypto, etc - and
push that as 0.5.0, then as that settles on the net, move on to the
other parts of 0.5 [11], such as adjusting the pooling strategy as
described in the proposals, pushing that as 0.5.1. I'm hoping we
can still hit 0.5.0 by the end of the month, but we'll see.
[10] http://dev.i2p.net/pipermail/i2p/2005-January/000558.html
[11] http://www.i2p.net/roadmap#0.5
* 3) i2pmail.v2
The other day postman put out a draft plan of action for the next
generation mail infrastructure [12], and it looks bloody cool. Of
course, there are always yet more bells and whistles we can dream
up, but its got a pretty nice architecture in many ways. Check out
what's been doc'ed up so far [13], and get in touch with the postman
with your thoughts!
[12] http://forum.i2p.net/viewtopic.php?t=259
[13] http://www.postman.i2p/mailv2.html
4) azneti2p_0.2
As I posted to the list [14], the original azneti2p plugin for
azureus had a serious anonymity bug. The problem was that mixed
torrents where some users are anonymous and others are not, the
anonymous users would contact the non-anonymous users /directly/
rather than through I2P. Paul Gardner and the rest of the azureus
devs were quite responsive and put out a patch right away. The
issue I saw is no longer present in azureus v. 2203-b12 +
azneti2p_0.2.
We haven't gone through and audited the code to review any potential
anonymity issues though, so "use at your own risk" (OTOH, we say the
same about I2P, prior to the 1.0 release). If you're up for it, I
know the azureus devs would appreciate more feedback and bug reports
with the plugin. We'll of course keep people informed if we find
out about any other issues.
[14] http://dev.i2p.net/pipermail/i2p/2005-January/000553.html
* 5) ???
Lots going on, as you can see. I think thats about all I've got to
bring up, but please swing by the meeting in 40 minutes if there's
something else you'd like to discuss (or if you just want to rant
about the stuff above)
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFB7XCWGnFL2th344YRAmhxAKC9tc+9ocOgu02PBAH1iBEghzpVXQCbBHLB
LFh9H55UFtsLPRFk7hxdv1c=
=0FdX
-----END PGP SIGNATURE-----
_______________________________________________
i2p mailing list
i2p at i2p.net
http://i2p.dnsalias.net/mailman/listinfo/i2p
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144 http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
http://moleculardevices.org http://nanomachines.net
[demime 1.01d removed an attachment of type application/pgp-signature]
More information about the cypherpunks-legacy
mailing list