IRC Improvements

SUIDNet writes: "The first ever secure IRC network has opened. All your communications on the SUIDNet are completely encrypted so no one can just sniff the network and watch your conversations. In addition, anyone who connects unencrypted automatically has a "-insecure" appended to their hostname and are banned from all SECURE channels. Check it out for yourself at http://suidnet.org or irc.suidnet.org." We also got a submission about a plan to improve IRC routing, Open Redundant-Link IRCd.

Re:Negative people on slashdot.

Much as you may not like it, you can't set limits on free speech without it becoming un-free. I've seen a lot of jabbering about kiddie porn in the comments. So what? If some people, for their own reasons, like trading that stuff, who are you to tell them they can't, just because you don't like it?

What if they said that the picture of your kids at the beach, building a sand castle constituted kiddie porn?

My point is that you can't draw a fuzzy line in an issue like this. Just saying 'Kiddie Porn Is Bad' won't get you anywhere. Sure, it'll make you look better in your community, because the majority of people will agree with you. But that leaves the door open for too much abuse. Where does porn start? Where does your picture at the beach fit into this?

A hard line, like "Kiddie Porn is when Nipples Are Showing On Children Under 18" is also ridiculous. Ever seen a Huggies commercial? Would you call it porn? This also leaves room for they people you are trying to stop to maneuver around the law. ("See? She's not showing her nipples!")

If you support an encrypted IRC network, then great. If you don't support an encrypted IRC network, then great. If you support a specially monitored, only 'nice' channels allowed, Absolutely No Kiddie Porn network, you're in for a tough time. How are you going to regulate it? Are -You- going to do it? Who would come to your network, anyways?

Comments like 'Encryption makes spreading kiddie porn' easier are pretty silly. Of course it does. Does that mean I shouldn't use encryption? Does that mean there should be a trusted IRCop in every channel, watching for any kiddie porn? Much as it's nice to have morals, whining won't solve your problem.

PS- If you really want help your kiddie porn crusade, I suggest you contribute to developments in AI. If you accept the idea that people will eventually create a self-aware computer program, you can accept the idea that it will probably be used to monitor internet traffic.

SILC

It seems secure IRC-like systems are spranging up. Quite understandable. From the land of Linux comes one.

SILC [silc.pspt.fi] takes a new approach. It's not about adding encryption via SSL to existing networks, but building secure network and clients from ground up.

And no, it's not intended as a replacement for IRC. It's an alternative. - And if I understood C any better, I'd be developing this one as well.

Demystifying Suidnet

I am one of the suidnet admins and I'd just like to comment to some of the posts here to make things a little more clearer.

Suidnet is a very new network, it has only been around for less than a week and we're still working on getting the kinks out, and we have never fully guaranteed security. All we do guarantee is that your link to the server and the links connecting the servers will be encrypted and that we are trying our best to ensure that all of the servers are secure. This is not fully implemented yet, but it will be within a week, so please do not exchange sensitive information until notified on the website.

Currently the ircd source is experimental but will be publicly released when fully finished (it is based on hybrid6rc4). I can say that we use stunnel to ssl wrap all of the connections between the servers and for connected clients (useful for running one server for encrypting/decrypting and one for ircd). I can also say that we only made modifications to the ircd to obtain hostnames of users connected through stunnel and to append -insecure to unencrypted connections and that none of them are run in debug mode.

The basic idea is that unencrypted users get -insecure appended to their hostname so if you are connected securely and want to run in secure mode, you can /ignore *!*@*-insecure, or if you want to run a secure channel you can /ban *!*@*-insecure, etc.

Oh, and all of the swapping of MP3s and kid porn that is done over /dcc will not be encrypted unless both ends run irc clients that encrypt dcc. We can't even guarantee that dcc will work the same as with normal irc yet.

Any/all comments are welcome as always, and I'm glad to see all of the discussion going on here on /.

-Ttyl

That's great!

Can we make it completely anonymous, too?

That way, no one else has to know who you are, or what you're saying... wait, if I wanted that, I could just lock myself in the closet...
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].

Depends

Friend of mine works at (large computer manufacturing company). They have a non-official irc channel, sort of an e-WaterCooler...

Anyway, internal MIS dept. found out about it and started sniffing the network, and logged EVERYTHING that was said in the channel over a three week period. Talk of stupid bosses, who was screwing who, drug taking at weekend parties, the works.

Upshot: 6 people fired, 3 more severely reprimanded.

So, yeah, if you want to chat at work without "the man" hearing everything, this is a pretty important development. :^)

--

Traffic analysis and secure messaging - thoughts..

We ditch the IRC model, which is fundamentally insecure inasmuch as it requires an extra layer of trust (the server op), who's in a prime position to be leaned-on by [insert powerful party].

Something I haven't seen brought up in these discussions is traffic analysis. Foiling TA is the key to truly secure communications. This is tougher than it sounds, as there are many ways to glean info from an encrypted channel.

The "Buddy List" (or, if you prefer, list of users on a channel) is the most useful piece of intelligence for any security force. Start with an individual under suspicion, watch who that individual communicates with, when, and how frequently, and you know who to investigate next. Encrypted message traffic doesn't affect this channel of info.

Consider encrypted ICQ - messages may be encrypted, and broadcast point-to-point, every user's "buddy list" lives on AOL's servers. Every sign-on or -off is recorded. At this point, say you've got a "buddy" in your list who's sharing MP3s or hosting DeCSS. RIAA/MPAA subpoenas user's buddy list from AOL (whoops, since it's AOL/TW, a court order probably isn't necessary!). Now you are brought under suspicion or targeted for harassment, or otherwise dragged into a case you may have known nothing about.

Now, this has me thinking, what would it take to defeat TA in an instant-messenger type product. I'm not a coder by any means, but I have a few ideas:

• No centralized servers, of course. "Buddy lists" stored at each client, exclusively

• Clients continuously send/recieve encrypted traffic to neighboring hosts. Within fixed-sized encrypted blocks there might be user messages (w/ routing information encrypted in an "onion skin" fashion, so that a routing host doesn't know the final destination of the message, nor its true origin), client messages (newly connected client advertising its presence on the network, etc), or padding, if necessary to fill space. Continuously sending and recieving fixed-size chunks means others can't trace messages by monitoring traffic volume over time.

• The network should only support messaging. The latency and scalability limits to this system should be tolerable for text messages, but would be shot to hell by file transfer.

Any thoughts on this? Anyone working on such a system already?

-Isaac

Negative people on slashdot.

My god... I can't believe you people sometimes. You think carnivore is bad, and you pontificate about encryption being the only way to secure your email from the Government's prying eyes. Then this story comes out, and of the comments so far, no one has anything good to say about it.

Don't you think the Government already has some sort of monitoring system for IRC? Don't you think that this would at least provide some higher level of security than none at all? Sure, none of you all will admit to using IRC, but that doesn't matter, because hundreds of thousands of other people do use IRC, and in the end, we are the ones that know how to protect ourselves, they are the ones that don't.

I think this system is a good idea, and while some of you have valid points, there are limits to the security of a public messaging system. After all, all security eventually boils down to trusted authority regarding identity, which is something IRC may never have.
-

How secure is this really?

All IRC is, is a glorified multiplexor on steriods
with delusions of grandeiur. If all the links are
encrypted from clientsservers then how much security have you really gained? Noone can sniff your network, but do you trust the admin's of the servers not to patch the daemon and sniff your traffic? What about the local SS coming and forcing you to install those patches? You'd be far better to extend the CTCP (Client To Client Protocol) that runs over the top of irc to support encryption. IRC already has this in the 'SED' CTCP, which unfortunately isn't too secure. Someone with some spare time could easily hack this up.

The next point is how much cpu do you have? Encryption is
all very fine, but having the servers do all the work causes all sorts of problems, when you hit 10k clients per server as some networks have done how much cpu are you going to need to use then?

In other news....

Today was the announcement of the encryption toilet, SecureJohn (SJohn). When flushed, it scrambled it's contents as to render them useless to prying eyes. Microsoft has chosen to implement it's own version in it's latest OS with stand alone versions available for purchase. While MS John will not be full compatible with SJohn, open source proponents are rumored to be working on OpenJohn for the various flavours of Unix.
Back to you CmdrTaco.