InvisibleNet Presents IIP 176
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."
Looks very promising (Score:3, Insightful)
... except that you can't see it :-) (Score:1)
Re:Looks very promising (Score:4, Insightful)
Here's to hoping the whole thing doesn't come tumbling down.
Re:Looks very promising (Score:3, Funny)
I've been poking around the similar idea (Score:3, Interesting)
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.
Re:I've been poking around the similar idea (Score:3, Informative)
Initial data gathered suggests that it could scale well, preserving low latency and reasonably high throughput.
Unfortunately, with this model, there are a few anonymity concerns -- the current issue being pondered is node discovery (how to keep an attacker from learning large numbers of nodes) and how to anonymously route messages back to the user. But don't worry, it's being worked on.
Re:I've been poking around the similar idea (Score:1)
IIP2 is in the works which aims to include a completely different architecture. It will most likely be totally peer-to-peer (as in no distinction between clients, proxies, and servers; all nodes will share all roles) and incorporate a lexical routing system (addresses derived from channel or user names and routed accordingly).
[snip]
It's all good, but you have to realize that there is no anonymity without proxying, and there no proxying solution without scalabilty problems. As simple as that.
Re:I've been poking around the similar idea (Score:2)
Re:I've been poking around the similar idea (Score:1)
>How cany you both trusted and anonymous
You trust those who you are proxying for.
Replying to myself :) (Score:2, Informative)
>>> you create trusted network of anonymous
>>How cany you both trusted and anonymous
>You trust those who you are proxying for.
Just to explain a bit more - every node would serve as a client and a proxy server.
As a client it would have at least one proxy node that it would use to communicate with the network on other side of the proxy. Client obviously cannot have an anonymity with the proxy, hense it must have a trust with proxy.
Consider the example - I have a number of friends (F) I trust. These friends have their own friends (FF) that I am neither trust nor is aware of . So F nodes will be serving as proxies for all communications happening between me and FF nodes. I will not know FF's identities, they will not know mine, but this all will work only if -I trust F- and -FF trust F-. See ?
Re:Looks very promising (Score:1)
Re:Looks very promising (Score:1)
Re:Looks very promising (Score:2)
AOL has "rooms".
bonus points (Score:2)
Re:bonus points (Score:2)
horray something to download! (Score:5, Funny)
Re: horray something to download! (Score:1)
> I gotta love slashdot, just before I decided to cave in and do homework, theres a post on slashdot involving downloading, irc AND encryption!
Tell your mom to turn off the nanny filter - a couple of goatse links will have you back on your homework in no time.
Re: horray something to download! (Score:1)
If intended to be insulting: In addition to those who may be under some sort of "nanny filter" adults often also do homework. Though some don't bother and instead attempt to make themselves look more intelligent by implying that improving yourself through study is somehow childish.
If not intended to be insulting: That was lame.
Re:horray something to download! (Score:1)
You should too.
All this encryption ... (Score:4, Insightful)
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 ... (Score:3, Insightful)
It's probable that no one cares who you are, but if they do, well...
Re:All this encryption ... (Score:2)
Or post as an AC....
Re:All this encryption ... (Score:2, Funny)
!woY ?secived noitnevmucric sa dessalc won era scixelsyD
--
Evan
Re:All this encryption ... (Score:2)
Re:All this encryption ... (Score:2)
Yes, it will. The purpose of encryption is not to conceal who you are, but to conceal what you are saying. More correctly, it's goal is to ensure that only the people you send a message to will be able to understand it.
Re:All this encryption ... (Score:2, Interesting)
Why do you think there's an old 'hacker proverb' of "every third one is a fed"?
Yes, they do still keep their eyes on the "hacker community"; even those who aren't doing anything illegal. Don't take my word for it; use FOIA to request your files--the addresses & instructions you need to do so can easily be located online.
Re:All this encryption ... (Score:2)
Re:All this encryption ... (Score:3, Funny)
Re:All this encryption ... (Score:1)
It sounds like this network at least secures the technological aspects of privacy. If you post messages describing what kind of car you drive, what your house looks like, and where you hang out on Friday nights...well, that's your problem if someone pieces that together.
MY NAME IS 06x0 (Score:1, Funny)
--- 06x0
Clever, 0x90, but I'm changing my name to 0x120... (Score:4, Funny)
... that way I'll be "too gross."
This sig is false.
Re:Clever, 0x90, but I'm changing my name to 0x120 (Score:3, Informative)
0x90 is the instruction code for 'NOP' (No OPeration) on IA32.
In case anyone wondered. (I'm guessing... not)
Re:Clever, 0x90, but I'm changing my name to 0x120 (Score:2, Interesting)
It's also gross in decimal, as in, a gross (144).
This sig is false.
Re:Clever, 0x90, but I'm changing my name to 0x120 (Score:1, Redundant)
Re:Clever, 0x90, but I'm changing my name to 0x120 (Score:1, Offtopic)
Re:Clever, 0x90, but I'm changing my name to 0x120 (Score:3, Interesting)
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...
stupid moderation (Score:1)
DCC and CTCP disabled (Score:5, Insightful)
But ofcourse you can paste freenet keys and urls.
Don't you know who's really using this?!?!?!? (Score:5, Funny)
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>
Re:Don't you know who's really using this?!?!?!? (Score:1)
Re:Don't you know who's really using this?!?!?!? (Score:2, Funny)
Don't worry. If 0x90 is doing all that while building bombs, there's a good chance that we'll be rid of him very soon. No need to do anything
Re:Don't you know who's really using this?!?!?!? (Score:1)
Re:Don't you know who's really using this?!?!?!? (Score:1)
Secret channels and practical uses? (Score:5, Insightful)
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?
Re:Secret channels and practical uses? (Score:1)
Re:Secret channels and practical uses? (Score:3, Informative)
to create a !channel type:
to join an existing !channel type:
Then set mode +a:
Why? IRC weirdness.
mircryption - strong encryption suite for mIrc (Score:2, Informative)
one nice open source one (only runs on win32 with mIrc irc client):
http:\\mircryption.sourceforge.net
Invisible IRC (Score:5, Funny)
It worked Right away (Score:4, Informative)
Re:It worked Right away (Score:2)
very intresting (Score:3, Funny)
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
how about not banning people? (Score:2)
Re:how about not banning people? (Score:2)
Making
One might as easily ask why Usenet needs moderated groups when killfiles exist -- and if you need to question the existance of those, I daresay you've not used usenet much.
Nickserv / Chanserv clone called Trent (Score:3, Informative)
For help:
To register your nick:
To identify:
See also the IIP manual [invisiblenet.net]
Re:Nickserv / Chanserv clone called Trent (Score:2, Insightful)
IIP uses the
Is this such a good thing? (Score:1, Interesting)
Is this really such a good idea, keeping in mind the terrorist attacks last year? Bare with me, I do have a point.
I'm one for privacy and also for secure ways of doing things on the internet, BUT, and its a BIG BUT, think of the other uses this could have, especially for terrorists. This sort of thing could give more fuel to the fire for governments to try to crack down on the internet and create more of a big brother state where they are able to monitor everything and encryprion is outlawed.
On the other hand, think about the earlier post today from Chris Tresco, where he says that encryption is only as strong as your weakest link. What if one of the machines along the way was compromised? Could it be used to monitor data and then be analysed to connect the dots so to speak?
None-the-less, I think it's an interesting project and wish them the best of luck.
Re:Is this such a good thing? (Score:5, Interesting)
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
Re:Is this such a good thing? (Score:1)
I'm most certainly not going to bare anything! And you shouldn't either!
But anyhoo...
[i]
think of the other uses this could have, especially for terrorists. This sort of thing could give more fuel to the fire for governments to try to crack down on the internet and create more of a big brother state where they are able to monitor everything and encryprion is outlawed.
[/i]
Terrorists, by being terrorists don't have to give up their freedom of speech. If governments want to monitor terrorist activity by randomly sifting through internet traffic... it's the goverments that are infringing upon your rights - On the other hand... if they are targetting a particular individual, and trying to access his information, they can prolly do it just as easily using a key logger or something like that... I daresay that these terrorists haven't been using Windows Update on their registered copy of Windows 2000. Also, the government could use M$ to work with them in adding confidential security holes in all copies of Windows YP so that they can get easy access to the system if needed.
blah! I'm drunk anyhow.. so I hope that all that made some sorta coherent sense - Also, I'm sick of 90% of internet traffic having to go through the bleedin US (no offense)
DECENTRALIZATION!!!!!!!!!!!!! should be the highest priority!!!!!!!!!!!!!
Hats off to IIP...
-SirDude
Hats back on now...
Scalability? Resistance to Attacks? (Score:3, Interesting)
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.
Re:Scalability? Resistance to Attacks? (Score:3, Insightful)
Chapter 10 of IIP Documenetation from CVS [sourceforge.net]
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!
This is way long overdue... (Score:1, Redundant)
Re:This is way long overdue... (Score:1)
Trillian (Score:2)
Through the AOLIM protocol... I take it this is much more secure though?
Re:Trillian (Score:2, Informative)
It's susceptable to man in the middle, and many other problems.
Re:Trillian (Score:1)
Re:Trillian (Score:2)
Now, the MITM threat can be managed by a couple means. There is a superset of DH that uses signed keys to avoid MITM. You can also secure the network between the 2 communicating parties.
SecureIM does not use the more secure superset of DH, so it can be MITM'd. The networks that trillian supports secureIM over are AOL and ICQ (both owned by AOL). This means that the US government could compel AOL to automate MITM attacks against secureIM. I wouldn't doubt if this was built into dcs1000/carnivore, echelon and other similar schemes.
Re:Trillian (Score:1)
be perpetrated by anyone in a position to substitute
the components of the shared key: AOL, or the ISP at
either end (including the carnivore box at the ISP).
And, while I'm no number theorist (or a mathematician,
for that matter), I don't see any way that either end
could verify the shared key was generated by his/her
secret parameter without knowing the other's secret
parameter, which would be as bad as sending a symmetric
key in the clear, it appears. This document [rsasecurity.com]
for illustrates the attack you described.
So what the world needs
is a chat program that will still use AOL/ICQ as
a transport, be easy to use, and support the use
of gpg keys out of the box, it seems.
Meanwhile, at MI-5 (Score:1)
M: Agent 007, you've got stop 0x90!
007: Er, what's his name, Q?
M: 0x90, the man is involved in all kinds of cracker activity
007: Um yes, just working on the pronunciation...
distributed irc? (Score:5, Insightful)
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 0x90 himself: (Score:4, Insightful)
<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
Incredible (Score:1)
oh and
Bravo
More decentralized IRC please (Score:1)
Reading the docs briefly tells that this works by connecting through "proxies" before the actual servers. The proxies will provide the anonymity because they don't know what the transferred data is and servers don't know what the client's IP is, only the proxy's.
I guess this is fine as long as anonymity is all you want, but I don't see this getting mass attention. It's just yet another IRC network. Don't know about you but I'm sick of having different IRC networks, it'd be so much easier to just connect to "IRC" and be able to talk to everyone. Allowing everyone to run servers which all could talk to each others would effectively do this, just like SMTP protocol with emails. There's a few projects that have been meaning to do this, but none of them is anywhere close to a working implementation AFAIK.
Some links: irc+ [irssi.org], irc++ [holoweb.net]. Also jabber does pretty much the same, but it seems much more about instant messaging than containing all IRC's functionality.
SF User Agreement Violation? (Score:2)
I don't advertise for anything on my own sf project page just because I read that you're not supposed to profit from your SF web space....
Re:SF User Agreement Violation? (Score:1)
We had their banner / link, because they were running a public relay for us.
CS-IIP protocol (Score:3, Insightful)
* 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)
A few more reasons this is not secure (Score:4, Insightful)
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.
Re:A few more reasons this is not secure -by 0x90 (Score:1, Interesting)
Thanx.
0x90
Re:A few more reasons this is secure - 0x90 (Score:1, Interesting)
0x90
Re:A few more reasons this is secure - 0x90 (Score:4, Insightful)
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...]
Re:A few more reasons this is secure - 0x90 (Score:1, Interesting)
THnx.
0x90
Re:A few more reasons this is secure - 0x90 (Score:2)
How the heck are you going to watch the big routers? Don't you need access to them?
Re:A few more reasons this is secure - 0x90 (Score:2)
It is really not that hard to do, and with the recent CALEA provisions here in the US and other anti-terrorism efforts by other countries such monitoring capability has almost become a requirements for the equipment used at these major exchange points... Sad, but true.
Re:A few more reasons this is secure - 0x90 (Score:1)
Re:A few more reasons this is not secure -by 0x90 (Score:2)
The onion routing work suffers from the same problem IIP does, it does not enforce constant bandwidth connections so it is not difficult to discover routes based upon statistical analysis. If you want a model to examine, I suggest you check out Wei Dai's pipenet for a general model and be sure to look at the work Roger Dingledine and others have been doing with MIX-cascades.
Re:A few more reasons this is not secure (Score:1, Insightful)
Re:A few more reasons this is not secure (Score:4, Informative)
Re:A few more reasons this is not secure (Score:2)
It is true that adding random noise into the channel won't completely thwart traffic analysis. However, I think you're considering this from the point of view that the goal is to keep the node associations from the attacker (a talked to b, b talked to c, c shows up in manila with a submarine full of gold) or that the intent is to provide anonymity to the users.
I don't think this is the case. IIP rotates keys between nodes every 52 blocks using Diffie Hellman. You are correct that an attacker can exist within the iip network and use the messages in the channel to do the traffic analysis. Diffie Hellman can be MITM'd, so it is smart to make it difficult to predict when the negotiation takes place. If the amount of blocks that traverse between the hosts can not be guessed by hanging out in the chat and counting how many times they exchange info, you make it more difficult to attack the key negotiation.
Furthermore, from the security in depth department, the data is encrypted for point to point communication, so even if the key exchange at the node level is MITM'd, they still only get cyphertext.
The creators also recognize that the anonymity isn't perfect. Until they can get that working, they've set it up so people have plausible deniability. A malicious node can find the IP's it's connected to, but it never knows if those are end users or another node in the network. So even though you've been identified, you can still deny that you are actually you.
I understand and agree with you about how chaffing data does not provide anonymity or good steganography for the communications. However, I don't think that is why it's used in IIP. It's used to make Diffie Hellman exchanges a moving target. Anonymity, stego and plausible deniability are provided by other means.
Linux RPMS and a public server (Score:2, Informative)
Great (Score:2)
before you pick it apart... (Score:2)
What IIP does is meld these two schemes in a chocolate-peanut butter kind of arrangement. Inter network node communication uses the first method, but then it layers on the end to end properties of the second (albeit with a second DH exchange).
It also mitigates the client issue. Right now, mac and windows users can't exchange secure IM's because trillian uses one scheme and fire uses the other. IIP bridges this gap for everybody by simply proxying IRC.
So yes, IIP is a hack and you may regard it with a bit of scrutiny. However, you should step back and see how this protocol is similar/different than others in the context of its goals. I think they've done a good job using peer reviewed cryptosystem components when they were available to fit requirements and incorporated some of the better aspects of cryptographic solutions that are around to solve similar problems.
Re:before you pick it apart... (Score:1)
Last Post! (Score:1)
the sun; there's a large meteor blocking transmission; someone loaded Star
Trek 3.2 into our video processor.
- this post brought to you by the Automated Last Post Generator...
So . . . (Score:1)
Re:what kind of faggy name is 0x90? (Score:2, Funny)
Yeah, that name is pretty gross.
p.s., If you don't get the joke, don't moderate this post.
Re:what kind of faggy name is 0x90? (Score:2, Funny)
</pun>
Re:what kind of faggy name is 0x90? (Score:1)
Re:what kind of faggy name is 0x90? (Score:1)
And yes, it was a idiotic joke. I "got it" immediately. Still wasn't funny.
Re:what kind of faggy name is 0x90? (Score:1)
Re:Unfortunately IIP is broken! (Score:1)
0x90
Re:Unfortunately IIP is broken! (Score:1)