jrandom | 1 Oct 2005 16:59

0.6.1.1 is available


Hi all, thanks for upgrading to 0.6.1 so quickly.  As a reward, we've
got a new 0.6.1.1 release ready for use :)  This one fixes several
long standing performance and reliability bugs in the streaming lib,
lets Syndie export pet names to your router's new pet name database,
reduces Syndie's bandwidth requirements, more carefully accepts IP
autodetection, and offers alternative methods for telling I2P not to
reseed on startup.  As always, for the details, just see 
http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD

This release is backwards compatible and should be a fairly smooth
upgrade, so give 'er a go whenever you can.  Reports suggest that the
in console updater is working, though may wait a day or so before 
notifying you of the update, so you can use the alternate techniques
listed on http://www.i2p.net/download if you prefer.

Thanks again for your patience as we improve I2P!

=jr
jrandom | 4 Oct 2005 22:08

weekly status notes [oct 4]


Hi y'all, time for our weekly status notes (insert cheering here)

* Index
1) 0.6.1.1
2) i2phex
3) syndie
4) ???

* 1) 0.6.1.1

As announced on the usual places, 0.6.1.1 came out the other day, and
so far, reports have been positive.  The network has grown to a
steady 3-400 known peers, and performance has been pretty good,
though cpu usage has increased a bit.  This is probably be due to a 
long standing bugs which incorrectly allows invalid IP addresses to get
accepted, which in turn causes a higher than necessary churn.  There
have been fixes to this and other things in CVS builds since 0.6.1.1,
so we'll probably have a 0.6.1.2 later this week.

* 2) i2phex

While some may have noticed the discussion on various forums
regarding i2phex and legion's fork, there has been additional 
communication between myself and legion, and we're working on merging
the two back together.  More info on this when its available.

In addition, redzara is hacking away on merging i2phex with the
current phex release, and striker has come up with some further
improvements, so there's some exciting stuff coming down the pipe.
(Continue reading)

Matthew Toseland | 5 Oct 2005 12:30
Picon

I2P conspiracy theories flamewar

I have found the following mirrored to Freenet from I2P. I would like to
discuss this, if people don't mind. This will probably induce a flame
war between Freenet and I2P, but the issues at stake are more important
than that. Please read the below, and read my response to it, before
replying.

Freenet URI:
http://127.0.0.1:8888/CHK <at> oaP3GuqiTb3t-krpzvllua4pd6cNAwI,9Z~9tQliGmdaXWGlrUw0ig/not_invented_here.html

Contents:

identiguy@...
Not Invented Here	Friday, September 23, 2005

"A few days ago, Toad posted a message to the Freenet devl list, arguing
in favor of re-implementing I2P inside of Freenet.

Of course, that's not the way he put it, but that's what his comments
amount to. He believes that, with a large amount of effort, it would be
possible to allow low-latency communication between parties on Freenet
(presumably using the same means as pre-mix routing), allowing for
applications such as IRC to operate over Freenet. He believes this is
necessary because the recent low activity levels on Freenet are the
result of a lack of communication between users and developers. He says
he'd rather not recommend they use IRC over I2P, because users who begin
to use I2P tend to abandon Freenet.

This, it seems to me, is a blatant admission on the part of the primary
Freenet developer that Freenet development no longer serves any rational
purpose.
(Continue reading)

Matthew Toseland | 5 Oct 2005 12:37
Picon

Re: I2P conspiracy theories flamewar

Note that I am not here arguing that you should abandon I2P or anything
of the sort! I apologize if I appear somewhat combative. I2P is useful;
it works, better than Freenet last I heard. However, as you can see I
feel there are clear reasons to experiment with Freenet 0.7's new
darknet routing - mostly for the reason that it isn't harvestable and
therefore can be used in fairly hostile regimes. This is not purely
hypothetical - the Freenet 0.5 session bytes are blocked by the Chinese
firewall, and it's only a matter of time before I2P is too, if it has
any predictable setup. It is quite possible that both will be harvested
and blocked, given that somebody went to the effort to find the protocol
bytes...

On Wed, Oct 05, 2005 at 11:30:16AM +0100, toad@... wrote:
> I have found the following mirrored to Freenet from I2P. I would like to
> discuss this, if people don't mind. This will probably induce a flame
> war between Freenet and I2P, but the issues at stake are more important
> than that. Please read the below, and read my response to it, before
> replying.
> 
> Freenet URI:
> http://127.0.0.1:8888/CHK <at> oaP3GuqiTb3t-krpzvllua4pd6cNAwI,9Z~9tQliGmdaXWGlrUw0ig/not_invented_here.html
> 
> Contents:
> 
> identiguy@...
> Not Invented Here	Friday, September 23, 2005
> 
> "A few days ago, Toad posted a message to the Freenet devl list, arguing
> in favor of re-implementing I2P inside of Freenet.
> 
(Continue reading)

TLorD | 5 Oct 2005 14:41

Re: I2P conspiracy theories flamewar


toad@... wrote:
> I apologize for provoking a flamewar, but the article is utterly untrue
> and a personal attack. This may not be the author's intention, but it is
> the fact of the matter.

Is this a flamewar? Oh well. Whatever.

As an ex-freenet user, I've moved to I2P for some reasons: speed, usability,
the fact it's dynamic rather than static, the feeling it's more versatile
overall. This was back when freenet was 0.5-something.

I reckon I2P wouldn't last more than few seconds in China. Minutes, perhaps,
but that's not the point. Harvesting makes things very hard in countries where
it's forbidden. I do recognize the darknet idea is a good thing.  But, I have
a few doubts regarding what you say about darknets.

First, why would it be a slow process to catch the darknet users? once you
have a mole in the network, you (governmet agency) can rather easily check on
traffic flow between users and outline the network. You just need the traffic
logs for a week or so. Also, once you catch a node, you can easily see the
direct peers and repeat the (abduction) process. What mechanism do people have
to remove the proof that they used the darknet?
Unless you implement the darknet as a hidden feature of a modified
pre-existing P2P program (say eMule), so that its trafic is submerged between
the other requests, you're open to traffic analisys.

Secondly, why do you think the network would become a small world? (a FAQ or
paper link would be enough) Somehow, I can hardly imagine why someone would
build loops in the chain. I'm more prone of thinking about a rather
(Continue reading)

Matthew Toseland | 5 Oct 2005 14:55
Picon

Re: [i2p] I2P conspiracy theories flamewar

On Wed, Oct 05, 2005 at 02:41:14PM +0200, TLorD wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> toad@... wrote:
> > I apologize for provoking a flamewar, but the article is utterly untrue
> > and a personal attack. This may not be the author's intention, but it is
> > the fact of the matter.
> 
> Is this a flamewar? Oh well. Whatever.
> 
> As an ex-freenet user, I've moved to I2P for some reasons: speed, usability,
> the fact it's dynamic rather than static, the feeling it's more versatile
> overall. This was back when freenet was 0.5-something.

Right. This is perfectly reasonable. I2P is faster, and more usable,
today. It offers reasonable security. Possibly better security than
Freenet in some contexts.
> 
> I reckon I2P wouldn't last more than few seconds in China. Minutes, perhaps,
> but that's not the point. Harvesting makes things very hard in countries where
> it's forbidden. I do recognize the darknet idea is a good thing.  But, I have
> a few doubts regarding what you say about darknets.
> 
> First, why would it be a slow process to catch the darknet users? once you
> have a mole in the network, you (governmet agency) can rather easily check on
> traffic flow between users and outline the network. You just need the traffic
> logs for a week or so. Also, once you catch a node, you can easily see the
> direct peers and repeat the (abduction) process. What mechanism do people have
> to remove the proof that they used the darknet?
(Continue reading)

TLorD | 5 Oct 2005 16:19

Re: [i2p] I2P conspiracy theories flamewar


Matthew Toseland wrote:
> On Wed, Oct 05, 2005 at 02:41:14PM +0200, TLorD wrote:
>>toad@... wrote:
> (note that traffic
> flow analysis is rather expensive at present and tends to produce false
> positives)

AFAIK that's quite correct. But consider this scenario: computers are divided
in two groups, servers and private users, possibly on different networks or IP
space. Now, all traffic user-to-user is likely P2P of some sort (and possibly
DCC, internet games and a couple of others, but that'd be at best sporadic
traffic). The number of P2P applications is rather small and methods of
recognizing them are known. How hard and expensive would it be to log all
"strange looking" traffic in that scenario? My guess is that it'd be far less
hard and expensive than the Great Firewall of China.
I'd also argue that false positives aren't that much of an issue in state regimes.

>>Secondly, why do you think the network would become a small world? (a FAQ or
>>paper link would be enough)
> There are some papers indicating that social networks are small world,
> however it is by no means certain at present.

While I tend do agree that usual social networks are small worlds, I'm not
convinced this specific darknet would become a small world by itself.

>>darknet, in which case I suspect the gentle users on the our side ot the wall
>>would quickly get blacklisted, once again cutting out chinese users (and
>>paying them a visit for connecting to a forbidden address)
> 
(Continue reading)

Matthew Toseland | 5 Oct 2005 16:24
Picon

Re: I2P conspiracy theories flamewar

On Wed, Oct 05, 2005 at 04:19:26PM +0200, TLorD wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Matthew Toseland wrote:
> > On Wed, Oct 05, 2005 at 02:41:14PM +0200, TLorD wrote:
> >>toad@... wrote:
> > (note that traffic
> > flow analysis is rather expensive at present and tends to produce false
> > positives)
> 
> AFAIK that's quite correct. But consider this scenario: computers are divided
> in two groups, servers and private users, possibly on different networks or IP
> space. Now, all traffic user-to-user is likely P2P of some sort (and possibly
> DCC, internet games and a couple of others, but that'd be at best sporadic
> traffic). The number of P2P applications is rather small and methods of
> recognizing them are known. How hard and expensive would it be to log all
> "strange looking" traffic in that scenario? My guess is that it'd be far less
> hard and expensive than the Great Firewall of China.

It would probably be easier to lock down the entire network so that P2P
is impossible. Yes you can identify traffic by session bytes and so on;
but if we use steganography, they will have to do traffic *flow*
analysis.

> I'd also argue that false positives aren't that much of an issue in state regimes.

Maybe. It depends on what level of collateral damage is acceptable. E.g.
it seems very unlikely that the Wall would block ssh.
> 
(Continue reading)

TLorD | 5 Oct 2005 16:49

Re: [i2p] I2P conspiracy theories flamewar


Matthew Toseland wrote:
> It would probably be easier to lock down the entire network so that P2P
> is impossible. Yes you can identify traffic by session bytes and so on;
> but if we use steganography, they will have to do traffic *flow*
> analysis.

I think we both agree that stego is a necessity for the successful deplyment
in hostile places.

>>I'd also argue that false positives aren't that much of an issue in state regimes.
> 
> Maybe. It depends on what level of collateral damage is acceptable. E.g.
> it seems very unlikely that the Wall would block ssh.

I was thinking more in the lines of "trying to come in the graces of a suspect
and see if he agrees to have you join", or just plain old "hacking into
someone's computer/room/life and check that out"

>>While I tend do agree that usual social networks are small worlds, I'm not
>>convinced this specific darknet would become a small world by itself.
> 
> Well, it's a subset of a social network...

Still, that doesn't prove anything. A subnet of a network with given
proprieties doesn't necessarily have the same proprieties. Eg. a coverage tree
of the social network.
I for once think that, even if I would invite all the friends I think could be
interested, I wouldn't bother to look into finding more than one access nodes
to the (dark)network. I might be the only one tho :D
(Continue reading)

jrandom | 5 Oct 2005 17:12

Re: I2P conspiracy theories flamewar


Hi Toad, et al

I've also read identiguy's blog, and I must say that while I don't entirely
agree with his interpretation (as there /are/ ways for Freenet to move forward
to meet real user's unmet needs) it does seem that a large amount of the 
motivation and tech being worked on could be reused from other sources, rather
than reinvented.  

Its a bit of a shame, as for hard anonymity, users *need* medium to high 
latency comm, the likes of which Freenet is in a position to specialize in.
In addition, for those who need hard anonymity against state level 
adversaries, low latency comm will never be sufficient.  Turning Freenet into
yet another low latency mix network doesn't seem like a great idea.

You've also suggested ulterior motives behind this duplication, both in 
private and in public, but I'll only respond to the technical issues here.  I
think you owe it to your users to put any ulterior motives out of bounds when
evaluating the technical needs for anonymity.

With all the discussion of working against hostile regimes, I'm not sure the
skill and dedication of state level adversaries has been sufficiently taken
into account.  They're not going to sit there with static passive attacks,
but move on to dynamic active ones.  There's a whole lot that hasn't been
explained about how the darknet will offer any sort of anonymity against
traffic analysis, blending attacks, local view attacks, intersection attacks,
predecessor attacks, or even, yes, harvesting attacks.  Harvesting is slower
in a trusted links network, but it merely slows it down, not stops it.

To be a little more provocative, how many dead users is OK with you?
(Continue reading)


Gmane