Slashdot Mirror
New Secure IM Client from NTT Due this Year
An anonymous reader writes "NTT in Japan has developed a new TLS-based
secure instant messaging system that it says will comply with corporate compliance regulations, such as the post-Enron Sarbanes-Oxley Act. There's a PC version, as well as a Java one for i-Mode cell phones."
OTR doesn't use TLS, but it does a great job encrypting conversations. Much better approach than SecureIM by Trillian or gaim-encryption.
This is just one more attempt, IMO, to realign privacy and security values to where they were before new technologies. Where IM is replacing conversations around the water cooler in the workplace, securing it from snooping is an okay thing. Logging it as official corporate communications is getting into, perhaps, dangerous territory. There is the part where it is a company resource, but when it comes close to being thought police, it is dangerous.
I think that modern society is still trying to find a place of 'normalcy' in the midst of new technology. I don't believe that there is an equivelant of IM prior to the advent of IM, other than private conversations. Recording private conversations is still not an okay thing to do. Comparing this to text based conversations that deaf/mute people have with text based phones, it all gets a bit confusing as to what is okay to record and what isn't.
Until it is clearly understood what is okay to snoop and record and what is not, people will make mistakes in what they allow to be recorded, and why, and how those recordings are used. No manner of encryption will fix the real issues. It seems that the only secure mannner to communicate is whispering so that no one can hear what is being said.... very low tech!
Support NYCountryLawyer RIAA vs People
If I can't look at the source.. it ain't secure.
..don't panic
Whether email or IM, writing anything controversial is a really bad idea. Say it face to face or on the phone instead.
Of course the question arises of what to do when you receive a verbal order to do something against company policy. You could comply, and take a small chance of later reprecussions, or else refuse or demand the order in writing, and face smaller but almost guaranteed reprecussions over time.
SEarch on freshmeat and you'll be overwhelmed, then look on google and find things like Akeni, imeem, Silc and secure jabber.
Does Jabber specify any encryption methods that could be implemented by clients? At the moment different clients are adding encryption but they all seem to be incompatible with the other clients.
Jumpstart the tartan drive.
Been Jabber, done that...
Seriously, why wouldn't a company want a secure flexible internal IM system, for free, instead of an expensive proprietary system?
Misleading titles? Inflammatory blurbs? Keep in mind that Slashdot is a tabloid.
Simp-Lite encrypts your traffic and is free if you only need to secure one type of messaging service at a time. If you want to secure several types the pro version is well worth it at only $30.
Bitwise is a rather nice IM network/client that's already available for Windows/Mac/Linux. It uses 128 bit Blowfish encrpytion for the free version, 256 for the Plus version and 448 bit encryption for it's enterprise solution (Bitwise Professional). Apparently the Professional version also provides the logging capabilities required for compliance regulations too. Closed source though :\
You should take a look at Wildfire. It has a GPL'd version and commercial version (extra features and support). At work I use the GPL'd Wildfire and it is excellent. It's also very easy to install, basically all you have to do is install the RPM and open a web brower to configure it.
"It ain't a war against drugs.it's a war against personal freedom" --Bill Hicks
Which I would have to wager, based on what we've come to expect from our friends at big business, means that the "secure" part of the client has built-in facilities for N third parties to snoop on your conversation.
ChatPatrol is a system level plugin that provides 256 bit AES encrypted communications for almost any client that can chat on AOL, Yahoo and MSN. Beta support for GoogleTalk has been added in the latest version.
Some here have mentioned Jabber encryption standards, which seem very interesting, but how old are they? Is there any mention of them in O'Reilly's Programming Jabber , or should I wait for a second edition?
This system has a backdoor built in which allows logging of the discussions by those not participating in them.
Secure = nobody has access to the conversation but the two people involved in it.
Secure Internet Live Conferencing :: It's a snap to install, has support in GAIM but also has a very decent client of it's own...not sure why this wheel needs to be re-invented.
Mind the gap...
So...it's Sarbanes-Oxley compliant *and* "secure"...
I don't think so...
Since Docomo has a bad habit of charging users for their connect time, this is going to have almost no take-off in the Japanese cell phone market. The Japanese are so used to just emailing and calling it good. The only time you might want to do a live chat by cell phone is if you're getting ready to meet somebody, and at that point, why not just call?
"Give a man fire, and he'll be warm for a day; set a man on fire, and he'll be warm for the rest of his life
I have been testing jabber servers at work. So far OS X Server's Collaboration Services, A.K.A iChat Server is my favorite. I simply started up the machine, added it to our AD domain, and named and started the service. Users were immediately able to authenticate against the domain and chat. Macintosh users immediately had audio, and with a Firewire camera, H.264 video chat capability. I am waiting for a USB camera so I can try video on Windows. The app comes with the hardware, our cost figures to be about $4,000-$4500 with spare parts, a service contract and three years of OS maintenance (still waiting on a final discount offer). Really, the only downside for me is the heterogeneous hardware. If it grows into an enterprise wide solution, I'll need to work around the low end hardware (probably HA clustering), but for my current departmental build it really fits the bill as is.
I do have to remember to check that the audio is jingle compliant though.
It is cowardly, and a betrayal of whatever it means to be a Jew, to act as a white man
-James Baldwin
Sametime was 5 years ahead of it's time about 7 years ago. It had been neglected somewhat in terms of development since then, and is 2 years behind the times so it needs to be brought up-to-date. Fortunately that is exactly what IBM has done. At Lotusphere in Orlando last month they showed Sametime 7.5 which will be out later this year, it is a complete rewrite of the client end (which needed it) it is now based on the Eclipse framework and is extensible and cross platform, it supports graphical emoticons etc and looks slick. Take a glance here: http://www.edbrill.com/ebrill/edbrill.nsf/dx/st75s hots.html also worth noting is that the meanwhile plugin for Gaim which supports Sametime servers will be part of the core Gaim distribution, so Gaim will work out of the box with Sametime servers including encryption. Encryption in Sametime is client-server, so basically connection encryption, but client-client encryption should be quite easy to implement as a third party extension if it isn't included in 7.5 (I don't know if it is), but then you would not get server-side logging, which depending on requirements could be good or bad.
In RSA-based systems, like PGP and most implementations of SSL, etc., Alice creates a secret session key, encrypts it with Bob's public key, Bob decrypts it with his private key, and then they can talk, but if Bob's private key is compromised in the future, an attacker can decrypt the encrypted session key.
In Diffie-Hellman, Alice and Bob each create a secret half-key, send a hash to the other side, and combine their secret half-key with the hashed half-key they received from the other side. Because the hash is exponentiation in a prime field with an appropriate generator, each side recovers the same combined session key, and they can delete the secret material once they've got the session key. (There aren't many functions that are reversable this way - elliptic curves have some similiar functions.) To prevent man-in-the-middle attacks, one standard approach is to use a digital signature public-key system to sign the hashed key-parts, but in many environments you can use other methods, such as comparing the session key (or a hash of it) to make sure you're both using the same session key with each other instead of using different session keys with the man in the middle. There are a variety of ways to make this more complex - it's not uncommon to have a publicly known modulus and generator that's used to set up an initial session, which is then used to negotiate crypto parameters, identities, etc. for a second DH session that carries the real traffic.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks