Talk:IIP

From iA wiki

Related

• Warning about IIP SSK@wHOf1LwI6PUVcgDwqEu0CuZ6bRAPAgM,W6k8nbDP~T9StSHXQg5D9g/1.html (Freenet key)

Could you quote the Freenet page? VERY FEW PEOPLE are on Freenet so linking to it is essentially useless. Webfork

Here you go. This warning is incorrect on some of the main points. It would be good if someone could quote the rebuttal to this that was also published on freenet.

QUOTE SOMEONE WITH A TINFOILHAT ON FREENET I have been looking into the anonymity provided by IIP, and it appears to me that it really doesn't provide much anonymity, at least not more than regular IRC via an anonymizing IRC proxy with SSL (if such a beast existed)1. This isn't a problem in itself, however I get the impression many people are trusting IIP to be anonymous to a greater extent than it actually is, it's often seen as a companion for freenet, which though it has plenty of anonymity problems too is a lot more secure. In my opinion the IIP server should have really big banners warning those who would use it in ways in which loss of anonymity could cause actual real life problems. link to freenet key SSK@wHOf1LwI6PUVcgDwqEu0CuZ6bRAPAgM%2cW6k8nbDP%7eT9StSHXQg5D9g/2

Issues I've found after looking at the source for 15 minutes (ie. there's probably more, and ie. I might be wrong):

• The path through relays is determined randomly and ad hoc.

Unlike Mixmaster, each IIP relay picks the next hop to send a connection to itself, so the client cannot choose which relays it trusts and which it doesn't, apart from hoping all relays he contacts directly will have trimmed their noderefs to something he agrees with.

• There is no chain length regulation

Your connection will happily bounce about until it happens to reach the server. Not only does this mean you often get very unstable connections, but when you eventually have a stable connection this will probably be one going through very few servers, and quite possibly be directly to the main IRC server, not using any relays!

• It's trivial to find the IIP server

Which means the local law enforcement agency (the US law enforcement in this case, the server (iip.invisiblenet.net) appears to be located in the US) can come knocking on NOP's door and install a wiretap (and quite probably demand he not tell anyone about it), and read all your conversations. Or just wait until you connect directly to the IIP server and grab your IP. (with the current number of relays, this happens once in every 24 attempted connections (on average) to invisible IRC you make. Assuming they also get their hands on inform.invisiblenet.net (which isn't entirely unlikely) this number comes down to 1 in 12. 1 in every 12 times you connect the IIP server operators know exactly who you are (unless you're running an in use public relay)

• All communication is plaintext once it reaches the server

Even for private /msges, the text arrives as plaintext on the server. This means that anyone with control of the server can read all messages. (you could ofcourse use gpg to encrypt every message you type and have all readers use gpg to decrypt, but it would make a lot more sense to have isproxy do this.)

• Anyone can become a relay

For freenet and many other systems this is a strength, but IIP relays have so many methods of attack that this is probably a bad thing. For instance just by keeping track of local connects from non-relay hosts and cross reference with /join's to popular channels and anyone with a relay can construct nick<->ip mapping in no time.

• IIP is connection oriented, and connects/disconnects are publicly visible.

Another problem caused by trying to adapt a protocol not designed for anonymity, IIP works with connections that get broken as soon as any link in the chain breaks the connection. An even quicker attack than the one mentioned above is as follows: One by one start killing connections and watch who drops off IIP. This is an active attack and will probably get noticed if you do it too often, however if you only want the mapping once it'll work.

• Finally, it's not really a flaw in IIP but still not exactly encouraging, the IIP wiki description claims portscanners cannot detect the listening port for isproxy. This is not possible unless one does interesting things with TCP/IP, and even then it would require root. Isproxy shows up on port scans just fine. (In all fairness, this was probably just someone being let loose on the wiki who should have been kept off)

I don't think IIP is a bad initiative and I understand that progress comes in small steps, however claiming it provides any significant amount of anonymity at the current state of the project is a bad idea.

1Actually, IIP provides less security than using anonymizing proxies, as anybody can set up a public relay and as far as I can tell get it onto the public nodes.ref, while using a single anonymizing proxy would only have one proxy admin that could be corrupted or could snoop. 2To name a few: the people running illegal (in most countries) banks or gambling operations, child pornographers, and those who post deep personal secrets to their flogs. There might be a next edition if I have any corrections or additions. ENDQUOTE

QUOTE REBUTTAL FROM 0x9 my minimum rebuttles, please add if you like.

we know the connection per node is random in the node.ref but we have certain distances already decided in the private relay server side, the ircd server is not on that public list, as you do not know the topology of the network, you will not be able to ascertain how you can attack the anonymity with your 15 minute preview of code. See chaining below to learn about setting up your own routes.

Second, iip.invisiblenet.net is definitely not the iip server or even close, it's not relevant, it's literally another node, thanks for the assumption though.

3rd, inform has no more information that what's in the node.ref list, all it's duty is is to make sure routes are stable. Also, that's outside the US either way, just by coincidence, but it doesn't hurt. If inform goes down or is attacked, it has no effect on the current state of IIP.

Chaining and hopping, you have the option of private relays, what we call neighbor noding to chain your own hops by choice, and the future versions would like to make this more user friendly. CofE has expressed that he uses this feature. Inside the directory of your iip software (if you become a private relay, please see

mynode.ref). Feel free to hand that to your friends as their node.ref.

Addressed is the plaintext into the ircd server, that doesn't eliminate anonymity, as it's as good as a public channels knowledge of the text seen, all we see is nick and words if we were to monitor. This is agreed that we want to decentralize, however it does not reveal users identities, such as freesites don't reveal identify from their messages. (We have an optional anonymous mode flag that could be used to hide nicks as well, for the extremely paranoid, or those who do not choose to use their pseudonym to converse).

In response to the users becoming relays and timing attacks against killed connections. If you look inside the node.ref at the network protocol, first marker states closedelay: we use delay to assist against this attack, as it delays the disconnect of a user at random intervals to make it not exactly obvious of who is connected to what IP. This is specifically prevalant as there are many channels and it adds doubt that you can

possibly monitor them all since you are limited to being in 10.

And for the users that do not join channels at all and converse privately,

somehow they are not anonymous?

I will admit there are a few things to do at the ircd level, removing notice is one, and /whois is two. But stating that you have eliminated anonymity on IIP with the data and lack of facts you have demonstrated is rather vague and I'm glad you took 15 whole minutes to review our code and you know everything about the topology of IIP networking.

The more recent developers on this project are still

taking quite a bit of time getting through the code, and you have miraculously eliminated the security of IIP in 15 minutes after 2 years in existance and it having been peer reviewed by certain members of the cryptography community (including a presentation on it's protocol at codecon 2k2), as well as certain scientists at MIT.

P.S. SSL compared to our cryptography protocols is quite different. we have implemented certain properties in order to protect against traffic analysis and quite a bit other stuff that is specific to anonymity needs. Thanks for the opportunity and we do appreciate your review of it. Hopefully next time before calling out the scare patrol, you'd like to consult with the developers before making such assumptions.

0x90 ENDQUOTE