New Secure IM Client from NTT Due this Year 61
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."
Gaim and OTR (Score:4, Informative)
Re:Gaim and OTR (Score:2)
Of course, this is entirely reasonable -- it's not that they're debuting a servi
Re:Gaim and OTR (Score:2, Informative)
It's a very nice client.
Re:Gaim and OTR (Score:1, Informative)
Re:Gaim and OTR (Score:3, Informative)
Jabber can use TLS, it can also use PGP encryption over TLS or an unencrypted TCP connection, it's an open protocol documented in IETF standards track RFCs 3920-3923 and Jabber servers can communicate with each other just like SMTP servers. I installed my Jabber server in an afternoon and I can talk from my server to any other Jabber user, including GoogleTalk users.
Re:Gaim and OTR (Score:5, Informative)
Um... OTR is not PGP for a reason. I'm no crypto expert, but with PGP, Alice and Bob know each others public keys. They encrypt messages to each other, and anyone with the secret key, hopefully only Alice or Bob, can decrypt or forge a message. If these messages are stored, any breach due to a trojan, subpoena, etc. will be able to recover the messages.
OTR uses PGP to create a "shared secret" which is used to generate temporary encryption keys for each conversation. During the conversation, the security is the same as in the PGP case. After the conversation, the temporary encryption keys are discarded, so that no one may now decrypt the conversation (at least, they should be discarded). I'm a bit confused on the final step, but I think the shared secret is then published which allows anyone to create new temporary encryption keys which may be used to generate messages that belong to the conversation. This fact may be used to deny the validity of any claimed transcript of the conversation (and this way you don't need to trust that Bob has really discarded the temporary keys).
Re:Gaim and OTR (Score:2)
Clearly.
If someone is able to record the conversation and replay it with a compromised PGP key, then they could capture the key exchange and use that with the compromised PGP key to come up with the "shared secret" (or "session key" as it's referred to in the crypto world). Either you're explaining it badly, or I don't see the benefit. If the keys are compromised, you're fuqued.
The only advantage I see would be added resistance to some sort of attack that leveraged a large quantity of
Re:Gaim and OTR (Score:2)
Going back to my previous post, i.e.
Re:Gaim and OTR (Score:2)
It's not that a compromised PGP key isn't a problem; it is. During the conversation, you've got the same security as PGP: if your keys are secure, the conversation is secure. The advantage comes *after* the conversation. With PGP, a compromised key will reveal past conversations. With OTR, a compromised PGP key will not reveal past OTR conversations because they were encrypted with a temporary key. A compromised temporary key (which is normally destroyed) will reveal the conversation, but there is no g
Diffie-Hellman Ephemeral Keys for Forward Secrecy (Score:2)
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 en
This is just one more attempt .... (Score:5, Insightful)
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!
Re:This is just one more attempt .... (Score:2)
*shrug*. Nothing in this system stops you from exchanging public keys with your friend and sending each other encrypted messages on top of this layer. It's a bit cumbersome, but privacy has a price.
Re:This is just one more attempt .... (Score:2)
As usual, there is a high tech solution for this, and it has been around for some time, but this solution is really only popular amongst secret agents. I like to keep secrets safe from prying ears, that is why i refuse to speak to anyone about anything important unless we are under a cone of silence [a9.com].
Source? (Score:4, Insightful)
Re:Source? (Score:2, Insightful)
Just because you can't see the source doesn't necessarily make it insecure. It just makes it harder for you to verify that it's secure.
You can't see the source code for the computer in your car. Does that make it unsafe to drive?
Re:Source? (Score:2)
Re:Source? (Score:1)
Why do we have to trust anything at all, especially computer-related stuff? This is the reason why open source makes perfect sense for the rest of us. The rest of the population (you included), can keep using closed source code connected to public networks... if that's fine with you that's fine with me. For as long as I [kernel.org]
Re:Source? (Score:2, Interesting)
You have to look at the compiler, the OS, the microcode and the hardware, too.
Re:Source? (Score:3, Insightful)
No
Encryption is pointless here (Score:3, Informative)
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.
Re:Encryption is pointless here (Score:1)
Re:Encryption is pointless here (Score:2)
Even a mediocre company PBX can record any call nowdays. And if it is VOIP recording all traffic is so trivial that it is not even funny. So on your expectation of privacy in a corporate phone call I can say only one thing. Bwahahahaha...
Jabber? (Score:2)
Re:Jabber? (Score:2)
- Connection based encryption, which I believe Jabber already provides.
- Content encryption, requiring users to provide a public and private key, which I don't believe has been standardised. GPG would be my favourite solution, but I don't see many clients using it, and when they do it seems inconsistent.
BTW Can someone tell me whether the connection between the two people chatting with Jabber is P2P or whether it is routed
Re:Jabber? (Score:4, Informative)
http://www.ietf.org/rfc/rfc3920.txt [ietf.org]
TLS can be used on client-sever connections and on sever-server connections.
JEP 27 describes the useage of OpenPGP for encryption:
http://www.jabber.org/jeps/jep-0027.html [jabber.org]
RFC 3923 describes S/MIME useage:
http://www.ietf.org/rfc/rfc3923.txt [ietf.org]
JEP 116 describes Encrypted Sessions, which seems to be somewhat reminiscent of SSH:
http://www.jabber.org/jeps/jep-0116.html [jabber.org]
I don't know that anyone implements this yet.
BTW Can someone tell me whether the connection between the two people chatting with Jabber is P2P or whether it is routed via the server?
Normal chatting at least is all client-server. File transfer can be p2p (normal case) or client-server, while Jingle Audio is p2p.
Re:Jabber? (Score:1)
Re:Jabber? (Score:1)
File transfer (http://www.jabber.org/jeps/jep-0096.html [jabber.org]) uses "SOCKS5 Bytestreams and In-Band Bytestreams, to be preferred in that order."
From JEP 65 - SOCKS5 Bytestreams (http://www.j [jabber.org]
Re:Jabber? (Score:1)
Re:Jabber? (Score:2)
Jabber (Score:2)
Seriously, why wouldn't a company want a secure flexible internal IM system, for free, instead of an expensive proprietary system?
Re:Jabber (Score:1)
Wildfire (Score:1)
Re:Jabber (Score:3, Interesting)
Our company uses something called Lotus Sametime. Ever heard of it? Me neither until I joined. I've heard of Lotus of course, but not Sametime. Basically it's an AIM-a-like for corporate environments. Now you ask why they use it... because (and this are the only reasons as far as I can see) it has some screensharing / whiteboarding capabilities, its authentication can be tied i
Re:Jabber (Score:1)
Re:Jabber (Score:2, Informative)
jabberd2 can use your LDAP for authentication, data storage and maybe as a directory. I don't know about a web-based UI.
Sametime (Score:2)
Re:Jabber (Score:1)
iChat (Score:2)
Bitwise IM (Score:1)
Re: (Score:2)
Re:Resources on Jabber encryption? (Score:1)
Publisher: O'Reilly Media, Inc.; 1st edition (January 1, 2002)
RFC 3923 (s/mime) is dated october 2004 (http://www.ietf.org/rfc/rfc3923.txt [ietf.org])
version 0.1 (current=0.9) of JEP 116 (Encrypted Sessions) is dated 2003-09-09 (http://www.jabber.org/jeps/jep-0116.html [jabber.org])
JEP 27 (current openPGP usage) version 0.1 is dated 2002-03-12 (http://www.jabber.org/jeps/jep-0027.html [jabber.org])
The basic XMPP RFC (3920) (inc. TLS) says the XMPP WG was founded in 2002. (http://www.ietf.org/rfc/rfc3920.txt [ietf.org])
So the book might
This is an INsecure system (Score:2)
Secure = nobody has access to the conversation but the two people involved in it.
What about SILC? (Score:2)
Re:What about SILC? (Score:2)
At work, we're currently developing the multi-user layer of our flagship program, and we're using SILC because it's an existing, tested, standards approved (they get a 1024 port) system.
Not (Score:1)
I don't think so...
iMode won't be worth it (Score:2)