Invisible IRC Project Presentation and Speech by 0x90 (transcript of the MP3 from the speech given at CODECON by 0x90) "Lance is going to be talking about the Invisible IRC Project."... ...Lance steps up to the mic.... Lance: "Hi guys, I'm lance, and I'm the founder of the IRC Project. The concept was actually thought of, well it was not really an original concept, the idea hit me when I was playing around with Freenet. I was getting tired of waiting a day to get an answer back about a question about Freenet. So I thought, ok... these anonymous users probably want to be able to get together in a room and talk about Freenet.... So that was the idea and then I heard a few requests about it. There is a lot of studies and readings on anonymous IRC, it has been long awaited. So we are starting to do something with it. Right now we have IIP 1.0 released. It is in a primitive state but it is what I would say virtually anonymous under normal circumstances. I would not put the government under it, or someone who is really trying to look us up, so I would not sit there and try and push my luck with them.. but... At this moment it is a working demo for Windows, Linux, Mac OSX, and BSD. It uses pretty much a three tier concept right now. We do plan on making it more decentralized, but at this point we were looking for a viable solution for right now, as we move pace-fully to a decentralization. So what we have done is we have taken the IRCD daemon, we are using 2.10.3, and we have modified it quite a bit. We have made it pretty much so that when you log in it thinks it literally is from localhost clients, so that everyone pretty much gets the same address. We have set it up where basically there is a set of relays each user that wants to participate that has fair enough bandwidth, like a cable modem or DSL, can participate as a relay in the network. Right now it is a primitive manual algorithm, it is nothing serious at this point. Basically you have a node ref list, which contains a list of other nodes in it, and reads off the list randomly using a yarrow implementation (yarrow is a secure pseudo random number generator), will link to one of those nodes on a per connect basis. I would probably rather just as a concept, just physically demo it quick and then I will open the floor for discussion." ........Lance sets up the demo machine and projector, tells a few jokes.... ".....For a lot of people that are visual so it's probably easier not to demonstrate it from a prompt. We were nice to the Windows users".... more projector fiddling and jokes.... "So basically what we do for the Windows users, we set up a nice system. What the node refs contain, how it accesses the system is that you have a local port number it asks you to use like, 6667 or 6668 whatever, a standard port number, whatever you want. Preferably anything higher than 1024 up to 65535. Then you log in with your IRC Client: /server localhost:port What it does from that point is it accesses a node.ref file (which is a list of relays in the network). The relays act kind of like a firewall for the actual server, no one knows where the server is. The concept I came up with as a viable solution in a centralized concept was: hide the server from the users, hide the users from the server. In a sense it makes your IP anonymous because you are having encrypted traffic end to end and node to node throughout the network. There are issues with it like, you have to trust the IRC operator, so this is why we want to head over to peer to peer. Where we would have channel encryption and different concepts there." Lance gets network and software setup... "Ok, we are now connected, I have to authenticate with a third party authorization Bot. Its really kind of a quick hack for that, but what we want to have is the public key exchanged with a third party that holds public keys of users for authentication. .... Our famous channel is called #anonymous right now. A lot of people just hang out. This is actually a live working demonstration of it, and mostly all the users on here are Freenet users. Usually come together, work on little things, learning about Freenet, or exchanging Freenet keys. The issues with Freenet being you can lose data quickly, if you exchange keys right away, you can most likely get your data off Freenet. Pretty much how it works is, you log in, it randomly picks a node relay, right now, there is about 15 in experiment. We are working on node assimilation and a lot of different concepts. It is very primitive right now, but it just started 3 or 4 months ago, but it is working. What we have is a set of protocols in there, we have an optional spurt protocol, which is fake random messaging, within the encryption, so if you analyze the traffic, it will be sending random data randomly every 0-30 seconds, from 5 to 50 bytes of traffic. We also have an optional steady streaming protocol for the extremely paranoid which would be more for if you want to connect to a relay and constantly have a streaming pipe. Messages could definitely not be picked out of that. You would not be able to see what is going on there. I would rather have questions now, then I know where I can go with this. The idea obviously is anonymous real time chat using hopefully a peer to peer environment. Although right now it is in a centralized state. Any questions?" ---------------------------------------- Audience member asks: "How do you chain relays?" "The way that the system IIP works is, we have a listen.ref and what it does... say I have a couple of relays started, all they have to do is have those two in their node.ref, and from that point it gathers on... They exchange that relay with another set of people so there is now 3 in there. And then it just builds up, and builds up, layer upon layer with relays right now. The routing right now is very primitive routing. It will work for right now though, they are stacked upon each other, and they just relay each other. Actually surprising or not have not had too much lag in this way. The only thing that takes a little time is connecting in, because you have two diffie-helman key exchanges, and we are using 128 blowfish for encryption. We do want to move over to reindel when we go to a peer-to-peer environment, but right now blowfish is pretty acceptable." ---------------------------------------- Audience member asks: "Can the users specify a certain number of relays, as in I want to go at least through 2 hops, 3 hops, and can the user explicitly specify the hops that the user wishes to go through?" "At this point technically it is random unless you have only one relay in there. Now we have had a few users who have created their own routes. So what they do is link to each other, like trusted routes. So then they know, I am coming in, coming in, coming in... like that. At this point it is using yarrow to randomly pick a relay. Now, if you only have one relay in there of a friend, one that you trust, and you he relays through a friend that he trusts... what we call neighbor-noding, that is possible. In the peer-to-peer model we want to have a spread-spectrum, what might be termed as garlic routing, where you would have messages going through multiple connections at one time, they basically go down a different pipe to the same end point. I don't know if that would answer your question." - Audience member responds: "You mean two "parts" of the same message?" "We are not doing the half-data concept, its a small transmission, its not really worth piecing the messages together back at the other end. What I mean is, here is my node, I'm connected to this, this and this, and I send one message this way, and then maybe there is fake traffic going through the other node connections, and then the next message would go into a different hop, but the messages would go to the same endpoint, like a channel. ---------------------------------------- Audience member asks: "You say that there is end to end encryption between all of the people reading and writing, so is this right now just implemented against like path of attacks? So that you make up the keys as you go along?" "Actually, no, what happens is the node ref.....1.1 is sitting in CVS, it's not configurable easily for windows users and thats why we are waiting on it. It is in beta testing and people are using it. What we do, is for each node ref, they have a public key that is static, they generate a key-pair, and in their node ref it says host=this, port=this, protocol=cryptraw or cryptcore and then it says public key= and then it has a 1024 bit public key, on the inside of that, they have a listen.ref thats host=0000 port, same thing... and then private key= and it has their private key. So basically for reasons of man-in-the-middle attacks and authorization, you are statically assigned when you generate it via the command line. ...So... is that what you mean?" - Audience member responds: "My question is, say you have 5 people all chatting with each other, so if they all really want end to end encryption between all those 5, they have to all agree on a key to use or send 5 times the data." "Actually the problem with centralization has some limits, because end to end is user to wherever the server is in the world." - Audience member says: "So it's, end to end, user to server, not user to user?" "We are writing client to client encryption system. It actually has to be a third party written client. Specifically for IIP right now. Because its not worth going into the modifications in an IRCD, we would rather make it [IIP] peer-to-peer and then work on it there where we can do it that way. What we plan to do is have a virtual IRC server in each node. So when they connect, they go straight in there, and it interprets for their client. So the client does not know, it is just dumb, it thinks it is just IRC, but the actual protocol will handle client to client encryption, end to end, from channel to user, because we will be treating channels like a network. So each channel you join has a public key and a private key. What we have for end to end now, is we have a network ID for the network, so you have to have that at the top of your node ref. It's network ID and network Protocol (which is the crypt protocol). Then you have all your node refs which all have their public keys that you authenticate with. So if you do not have that network ID, you cannot get into the network. but.. the problem, then, is that you you basically must trust the IRC operator. That is an issue because he can sit there and tap into those all day. So this is one of the reasons right now, the only solution that we want to go to is, we have someone writing a client for it right now, for client to client private messaging. Then we are pace-fully moving over to the decentralized environment with channel encryption." ---------------------------------------- Audience member mumbles a question..... "?" "Scalability... with the centralized environment its the same limitations. This all just started 3/4 months ago. We are still theorizing on many things. There is still a lot of research to be done on the peer to peer model. A real time environment is really hard... You have an option of scalable, and an option of anonymity... With the delays and different tactics to keep a user anonymous, you might lose some scalability, because it is going to use some bandwidth. We are trying to find the optimal answer to that. I'd love to open the floor for discussion on different ideas, I am learning as I am going along. I started the project to learn a lot about the concept of anonymity on the networks." ---------------------------------------- Audience member asks question without a mic. ended with something about OSX something... "?" "Right now its command line, I am not a GUI person, I am a backend guy. Any volunteers?... ... Can you define what you mean by the port hopping? ... The spread-spectrum.. we have started slightly on an IP stegonography, concept also as well, but what we have right now, the network is very linear. Its like, if you are on a relay, you are on that relay. If you get disconnected, you hop on to another relay. So we do not have any advanced port hopping, or anything like that at this point. We do want to have the spread spectrum, we want to have like a fake-services kind of mode in there so with that to an ISP it looks like they are just browsing the web, or something similar to FTP. Things like that are not very suspicious. We did actually start what we call a masquerading protocol. It is not in effect yet, it is still in development. There is a lot of work. We literally only have two developers working on this. In 3 or 4 months I think it has gone a pretty good ways of being a viable virtually anonymous solution, but there still definitely is a lot of work to be done." ---------------------------------------- Audience member asks: "Can you gateway these anonymous IRC deamons with just standard IRC networks easily? Is that a simple thing to do?" "A lot of people ask 'Can you use it on a public IRC?'" - Audience member continues: "...or just have just one anonymous node in an IRC network?" "You technically could, but I would not consider it being anonymous, because the encryption only goes as far as the IRC operator allowing IIP to be... Its best as a pure protocol. It will not give you true anonymity in the sense of end to end encryption. You will have node to node encryption only. You will have the IP address of the last node that goes into IRC. So its not what I would consider anonymity on IRC. I did find a neat little DNS cache hack for IRC. What you can do for a type of pseudo anonymity is you can actually have a forward and reverse DNS and do a dyndns right as you connect in, then if you reverse lookup your IP, it will be whatever you wanted to set it to. That is the closest I have come to for coming up with a solution other than bribing IRC operators to get involved. Any other questions?" ---------------------------------------- Audience member asks: "Do you have plans to implement DCC, and DCC channels different than the main communication channels?" "We took out DCC and CTCP at this point, because obviously it grabs your IP address. I have been focusing on Chat, and a lot of people say "Oh I want to get file sharing...", and I really do not want to get into the file sharing wars.. but... What we are going to implement is an integration with Freenet's ez-fcp library. So you could do a "/DCC SEND file.x" to a user, and once it is done inserting the file into Freenet, give the user the Freenet key, and the other client automatically start downloading the file. Our plan is to integrate file sharing with Freenet. We do not want to implement a complete file sharing solution. Because Freenet, when it is finished, and completed as a stable environment, I think it has a lot of potential to be a great data distribution system, and I think that IIP will have a great communications system. Our focus is just the communication at this point, because of the small size of chatting and the scalability and all of the issues that are in front of us. So we do not want to push in file sharing unless it is integrating into another peer-to-peer environment. The closest thing we will have to file sharing is integrating into Freenet." ---------------------------------------- Audience member asks: "What do you intend to do to detect and deal with compromised nodes?" We have been thinking about this, and we have worked out the theory, at this point technically, we don't. This is why end to end encryption is important. Now if they crack the encryption there is nothing we can do but shut down the network, and get a new network ID. In the peer-to-peer environment core we are actually looking at a voting system, where say a node decides to start to cancer another node with extended messages, with something that goes through him, plus a message goes in like "I hacked your node" or whatever... what we want to do is have a voting system where we will basically do voting in pairs. We would be mirroring the messages. Channel servers will have nodes that run channels, they will be pairing each other. They will check for incongruence and inconsistency in messages. One mirror will ask another, "Did you get an incongruent message?" "Yeah, I got it, lets vote, and lets send it down the path and have a vote there." If it goes through the network with two pair votes, and everyone agrees that the message is incongruent, it will reject the nodes communication. The reason for voting in pairs is because someone could decide to flood the network for voting, so if we try to do that, we stop at a point, because obviously, not everyone agrees on the incongruent messaging. We will probably be using a one way hash algorithm for checking messages. Any other questions?" no more questions.... ...audience is in a breathless speechless awe... "Thats It! OK." ..... Applause..... THE END