Slashdot Mirror
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."
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.
I gotta love slashdot, just before I decided to cave in and do homework, theres a post on slashdot involving downloading, irc AND encryption!
... 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...
... that way I'll be "too gross."
This sig is false.
Social Contract? I don't remember signing any Social Contract!
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.
Terrorists! All those IRC Crypto people are terrorists!
All real, patriotic citizens are more than happy to let the government see, read and catalog everything they do.
All those "Privacy" nuts have something to hide.
I'll bet this 0x90 is learning to fly a plane while building bombs, writing free encryption programs, laundering money for the mob, selling drugs to toddlers, writing a violent video game, and *gasp* TRADING MP3S while on IRC with his fellow communist baby eaters!
</humor>
"Live Free or Die." Don't like it? Then keep out of the USA
0x90 is the instruction code for 'NOP' (No OPeration) on IA32.
In case anyone wondered. (I'm guessing... not)
Belief is the currency of delusion.
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?
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
It's great! When the boss comes around the corner, you don't have to minimize the window! Screenshots of Invisible IRC are in the link below.
mund freud.
I find it a bit slower on the outset then regular IRC, but completely painless to run. Only a little more time to tell if it crashes because of the ./ effect.
They also have a chanserve, nickserve named "Trent" if you are wondering, I havent tried to create a channel yet, but we shall see how it works.
If you don't vote, you don't matter, so don't waste your time telling me your opinion
i just tried this, its very cool.
:(
although a bit laggy, and can get confusing on +a channels, where everyone is anonymous, heres an example
sup?
ello
this is working?
no
you broke it!
no ok
wtf
who are you?
im anonymous
nobody loves me
I love you
and with everyones host being anon.iip it must be hard to ban people, but its a very intresting idea
We have a nickserv/chanserv clone called Trent
/squery trent help /squery trent nickreg password /squery trent identify password
For help:
To register your nick:
To identify:
See also the IIP manual
Resistance to Deliberate Attacks is often strongly related to scalability. Sure, there are other ways to attack systems - find bugs in the code, or do social engineering attacks like posting Scientology documents and Metallica songs and ratting out any identifiable network operators. But attacks on the network's scalability can be really hard to fix, because they abuse things the system _is_ supposed to do rather than things it isn't. Have you looked at what parts of the network are easy to overload with data volume or small-message quantity or CPU-burning public-key crypto calculations or other critical resources?
.
.
Oh, also, Invisibility is Cool, huh huh, huh huh, Invisible, yeah cool.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I worked on the project for some time so I have some accedotal evidence to support IIP.
... or a place for critque of the American government's actions post 9/11. I don't know about you, but if I were an American and I sympathized with the Middle-East view of the western world, due to the Patriot Act, speaking my mind in a public forum where I can be traced is the last thing I would want to do.
Some time ago, a very generous individual set up a #scientology channel for people who needed to find refuge from the cult and to critque it in a public forum. (Think censorship of xenu.net).
Other times it's been an excelent forum for discussion of topics such as this
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?
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!
so what happened? /. people go? ;)
<ArdVark> where did all the
*** 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
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
yes, and this extract from the interview seems to confirm
that yours is the 'correct' decoding of the nick -
still like the 'gross' interpretation but...
I've worked in VPN and P2P space for past few years and have been poking around the similar ideas for quite some time.
The basic idea is very simple - you create trusted network of anonymous -proxies- and if node sees the traffic coming from the peer it's just unable to tell if it belongs the peer or some proxied node behind it. Hense the anonymity is built into the infrastructure.
While looking at this, I got as far as putting together formal design document and protocol spec, and passed them around for the "peer review". The common problem everyone pointed out was the fact that this approach will not scale. It might be fine for IRC traffic, but it cannot and should not be applied to bulk data transfers. This is something InvisibleNet still has to realize.
It's good that they have a momentum, which may (or may not) allow them to overcome principal problems of the architecure.
3.243F6A8885A308D313
IIP 'security protocol' seems to be pretty amamteurish piece of design. I might be excessively picky, but here are some points anyway:
... So why to reinvent the wheel ?
* 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)
3.243F6A8885A308D313
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
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.
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...]