InvisibleNet Presents IIP

An anonymous submitter writes: "A new and ever growing project has launched into the alternative network realm, changing the pace by focusing directly on speech, rather than file sharing. The Invisible Irc Project, a peer distributed secure and anonymous internet relay chat network has popped up at some of the recent conventions this past year. The creator, and project leader, known as 0x90, has been seen at CodeCon 2002 introducing it to the public, at that time in more of a primitive state, and today, almost a year later, the software has noticeably been more usable by the masses. 0x90 just gave a talk at ToorCon 2K2 on designing a robust & secure Peer-2-Peer framework, and their InvisibleNet site just released new software along with a two part interview that was taken in July. A good read that details the depths of their project, including the state it is in now, and the future vision of a privately distributed steganographical crypto-net. I have tried out the software and it is very easy to set up, and it supports the freenixes, OS X, and Win32 machines. You can use any irc client with it seemlessly, and the cryptography is handled transparently within your "IIP" node. It's GPL so peer review is welcome, as it also states this on their site. It appears to have a nice community of users with a range of discussions. So if you have a bit of time on your hands to engage in some chatting online, give this a try. It's alternative, creative, and possibly a standard setting step to securing IRC as we know it."

Comments

Looks very promising

[ymgve]

I tried it, and it worked very well right out of the box. I am really looking forward to seeing them develop the InvisibleNet platform further - it might even become a serious competitor to what FreeNet is now.

Re:Looks very promising

[Puggles]

It's performing very well out of the box right now, but IIP is about to have its scalability tested, Slashdot style.

Here's to hoping the whole thing doesn't come tumbling down.

All this encryption ...

[Xenographic]

... still won't help if you tell people who you are.

Your nick + the personal information you give out, even inadvertently, is more than enough to let people figure out who you are. You can build rather complete profiles of most people, even the security concious, from nothing but public information. I should know...

Re:All this encryption ...

[Anonymous Coward]

Very true. The very best way to protect your anonymity is to have several 'standard' alternate identities (e.g. *give* them personal information; several different sets thereof & reuse some of them more than once so they can't find the real information for all of the gibberish...)

It's probable that no one cares who you are, but if they do, well...

DCC and CTCP disabled

[MiDS]

Keep in mind that DCC and CTCP are disabled due to anonymity reasons, you can't use the current IIP network for filetransfer.
But ofcourse you can paste freenet keys and urls.

Secret channels and practical uses?

[Istealmymusic]

I've been using IIP for the past couple months now, but have yet to see a any interesting useful channels. /list only shows -s (non-secret) channels, I'm sure there has to be something more interesting out there... Anyone have any more information?

On a related note, on IIP you can /mode #channel +a to make even the nicknames anonymous. Yours still shows up in your own client though, but others will see you as "Anonymous". Pretty useful, but otherwise theres not much activity on IIP. The technology is there, wheres the application?

distributed irc?

[ergonal]

IIP claims to be peer distributed, but does that mean there's no primary target for packet kiddies to inflict their hundreds of megabits of anger upon? If so, this indeed would be an ideal solution to the massive DDoS problems facing the big IRC networks lately (DALnet in particular).

I think the primary focus of IRC development at the moment should be on inventing methods to stop the packet kiddies, otherwise IRC's lifetime looks pretty bleak. Maybe distributed IRCing is the way to go?

Re:Scalability? Resistance to Attacks?

[jdclucidly]

From the docs that I helped write:
Chapter 10 of IIP Documenetation from CVS
This is also why peer review is requested. I think most of your doubts will be put to rest by the docs though. Go read it! :)

From 0x90 himself:

[Istealmymusic]

so what happened?
<ArdVark> where did all the /. people go?
*** crappy has joined #anonymous
<echelon> <nop> not really I turned off the server
<echelon> <nop> there is still semi centralization
*** hobbs has joined #anonymous
<echelon> netsplit ;)
*** iip has joined #anonymous
*** anonymoose has joined #anonymous
<ArdVark> netsplit? no
*** echelon sets mode: -o Aprogas
*** echelon sets mode: -o Chocolate

CS-IIP protocol

[apankrat]

IIP 'security protocol' seems to be pretty amamteurish piece of design. I might be excessively picky, but here are some points anyway:

* Excessive use of pubkey cryptography (two DH exchanges ? How about regular Master/Derived key approach ?)

* Home-brewed replay protection (see SSL/ESP for design ideas). In particular, having no explicit sequence ID in the packet may potentially allow for the replay or packet reuse.

* No packet hashing to allow discarding malformed packets without decryption (see SSL/ESP for design ideas).

* Unproven key rotation algorithm, which seems more of 'obscurity through security' thing than anything else.

* No sign of declared on the main page Perfect Forward Secrecy (PFS) in the published specs.

* Complete intolerance to minimal payload twitches (bitflips), ie heavy inter-packet dependency.

The bottom line is the protocol is very rare and can use a lot of much needed peer review.

The fine print is WHAT IS WRONG WITH SSL ?! SSL already has all the goodies (replay, rekey, authentication, etc) and it's stable and proven. It's not like IIP-CS allows to work over unreliable media or something, it's still layered over sessioned, reliable transport (TCP) ... So why to reinvent the wheel ?

Re:Nickserv / Chanserv clone called Trent

[MiDS]

That is not true. /msg is a totally different command.
IIP uses the /squery command.

A few more reasons this is not secure

[Jim McCoy]

The creators of IIP seem to have fallen for the seductive "if we keep adding cool things we read about in Applied Crypto it will magically become anonymous/secure" fallacy. There has been a lot of good research and test implementations done on real anonymous networking over the past few years, unfortunately the creators of IIP seem to have been unaware of all of it. I will not waste too much time ripping on this because it is a noble (albeit doomed) effort.

One example of why this system does not offer the level of anonymity/security it is claiming is the mistaken belief that adding random "cover traffic" prevents traffic analysis. For some reason amateurs seem to think that if you add a few random bits of message traffic and delay a few messages between nodes then this "noise" will make observation and message correlation harder for an attacker. This is incorrect. The simple example that should help the /. crowd understand this is that an attacker can simply view the entire internal network as a black box and do statistical analysis on the inputs and outputs of this black box. There is only one way to prevent this sort of statistical analysis -- fixed bandwidth (or at least constant traffic) pipes. For a recent paper on this subject check out this paper that describes some of the techniques.

There are several lists out there populated by people who actually know what they are doing when it comes to this stuff and simply lack the time/initiative to code up what they know. If the creators of IIP had simply asked a few pertinent questions they would have learned a lot and saved themselves a lot of frustration given that most of this will have to be completely re-coded if it is actually going to live up to the claims being made by this project.

Re:A few more reasons this is not secure

[Anonymous Coward]

Which lists?

Re:A few more reasons this is secure - 0x90

[Jim McCoy]

Not true. Take a quick scan of recent work by Albert-Laslo Berabasi et al. regarding the structure of the internet (there was a recent paper in the Proceedings of the NAS and he published a book on this titled Linked that every slashdot reader should check out) which shows that there are a few key nodes which handle a bulk of the traffic. You have to stop thinking about this network as if it was a random network. There will be well-known, stable nodes that will become preferred nodes and relays within the network -- an attacker will start by watching these nodes. If that is not enough the attacker will watch the major routers and relay points within the net using these well-known nodes as the hook to find additional nodes. It does not matter how widespread your nodes are for these sorts of attacks; in fact, wide geographic distribution of the nodes makes the traffic analysts job easier because this will force more of the packets through major interconnects (and into view of the observer) instead of keeping them localized.

It does not matter that the traffic is encrypted in this case. An attacker is not necessarily interested in getting the contents of the messages, they will start off wanting to know who is talking to who. For this it is not necessary to break the encryption, you treat the whole network as a black box and apply some signal processing tricks to get the conversation flows. [Sorry if all of this sounds negative, but you have decided to tackle a very hard problem that lots of very smart people have been thinking and tinkering on for more than a decade...]