Slashdot Mirror
Cerulean Studios Releases Trillian IM Protocol Specifications
Runefox writes "Cerulean Studios, the company behind the long-lived Trillian instant messaging client, has released preliminary specifications to their proprietary "Astra" protocol, now named IMPP (Instant Messaging and Presence Protocol), which provides continuous client functionality as well as mandatory TLS encryption for clients. According to their blog, Cerulean Studios' motivation for the release is to promote interoperability among the throngs of IM services and clients available by allowing others to also use the protocol. Future concepts include federation with XMPP. While the documentation is in an early state and the protocol is claimed to still be in development, it is hoped that it will help decentralize the very heavily fragmented messaging ecosystem. It's implied that, in turn, greater options for privacy may become available in the wake of the PRISM scandal via privately-run federated servers, unaffiliated with major networks, yet still able to communicate with them."
Seriously, the last time I heard about someone using Trillian was years ago. They are a victim of their own business choices and no longer relevant, I've recommended Pidgin for those who want a all-in-one program instead of separate chat programs, but frankly most people seem to want to stick with whatever the separate companies provide. - HEX
Horror & SciFi Erotic Nudes
I'm concerned that if this encryption is unbreakable to the authorities, this could be problematic in thwarting terrorists and other evildoers.
I'm not sure its so good that communications is completely unbreakable, there should be some mechanism whereby the government and agencies trying to keep us safe can intercept and decode them.
There has been a lot of backlash on their blog about this: Why didn't they just go with XMPP? What their protocol have that XMPP doesn't, or couldn't be extended to support?
Personally - just a guess (also, btw, disclaimer: I'm a subscriber) - I think they're dying. Their client haven't been getting any significant development for the past year, current issues with some protocols have been going unaddressed, and new features like Lync protocol support (which there are working OSS implementations) have been going completely ignored despite many people clamoring for it.
So, they have been silent for a long time, and now this. It's fishy.
But those laws can't possibly work once the allow the end users to use standard public/private encryption schemes rather than foisting some proprietary solution that relies on the central node being able to decrypt every message.
Once more applications start using key pairs to encrypt payload the three letter agencies will have to brute force decrypt everything.
Routing data is still harder to deal with.
Sig Battery depleted. Reverting to safe mode.
On the one hand, yes, in a way it is dumb to "open it up" after all this time when XMPP is there. On the other hand, with Google having lost its Federation support and soon enough to lose XMPP support altogether; with MSN Messenger being eliminated in favor of the Outlook.com site or the Skype with a totally closed protocol, and who knows what else, it seemed that XMPP was the only choice. Well, still, for now at least it is probably the best choice--let's see how IMPP takes off--but at least it's no longer the only "open" choice. The promise of Federation with XMPP servers is also good. Overall, I think the extra choice prevails in importance over everyone just jumping blindly to XMPP (simply because it's all that there is left).
I mean nothing against XMPP--I will be using it unless IMPP proves itself and offers something superior, but I appreciate the choice and the opportunity for the two to compete on a level (open) playing field for the best features. This just means there will be more choice when using multi-protocol clients like Pidgin, and will likely spawn special IMPP "native" instant messaging clients, similarly to what Psy is to XMPP. In the end, I would say this is a welcome change, and with the recent turn of events the timing really isn't too late.
But those laws can't possibly work once the allow the end users to use standard public/private encryption schemes rather than foisting some proprietary solution that relies on the central node being able to decrypt every message.
Once more applications start using key pairs to encrypt payload the three letter agencies will have to brute force decrypt everything.
Routing data is still harder to deal with.
You can't have a turn-key encrypted communications program without trusting the implementation, and the key management system. You can do it all yourself... today. If you want wide acceptance, it's going to have to be the turn-key approach.
Most people don't care, you know. It's not that everyone has a "I'm not hiding something so I don't care" attitude, it's just not worth the effort to actively attempt to defeat every possible surveillance tool, it's not practical.
The problem is not so much the turn-key bit, as the fact that users have to effectively manage their own keys to provide any semblance of protection from eavesdropping from whichever three-letter agency. With your attacker in the middle of the communication channel, having the ability to modify/replace datagrams, there is no hope of securely exchanging keys over the internet....
Management of your private key is the only burden.
Keeping that backed up, yet available on every device upon which you need it is admittedly a minor hassle.
Once you get used to doing that, its pretty easy to deal with this for email.
The longer this NSA issue hangs in the press the more likely people will accept this task.
I can see some company coming along that offers Zero Knowledge storage, where they can't decrypt anything you send them, even at gunpoint, because they don't have your decryption key.
You could theoretically keep your private keys on their server, and simply fetch them as needed, and never store them on the device. One password to rule them all.
Sig Battery depleted. Reverting to safe mode.
SpiderOak does that right now, as a DropBox like service, and CrashPlan offers it as one of their security options for their backup service. I highly recommend both of them. It really isn't that hard to manage your private keys. I really wish people would start doing it for email as well, but I guess everybody just uses FaceBook these days anyway. Sigh.
Why don't we yet have a truly distributed and encrypted chatting protocol, sorta like email except with much lower latency? Have both feature to talk to individual persons, keep the list of it on your local machine (or synced to actual trusted servers, whatever works for you), and as well as joining a "chatroom" within the entire network (which is just a string or whatever), rather than having to rely on having specific servers.
I'm sure people can work out the smilies plugin and random misc things later on. Just get the basics done, something everyone and everything can use.
It's a small pet peeve of me, similar to the pain of moving files between two arbitrary computers (http://xkcd.com/949/)
We have XMPP+Jingle, SIP+SIMPLE, OMA IMPS, and now this IMPP joins the club. Guess why people stick to Live Messenger, Skype, Google Talk, Facebook and (gasp) ICQ? These have providers and a pre-existing audience, and people don't care about the inner workings. You can have the best-thought-out, most efficient, open and extensible gem of a protocol, but how many people are going to download a (likely clunky) client and nag their relatives, friends and coworkers into installing it too? Yes, there are a few and we all know one; just wait until said project goes belly-up.
This post contains no rudeness or derision of any kind. All arguments are friendly. Terms and exclusions may apply.
I'm a SpiderOak paying customer, and while they do have zero knowledge storage, but they don't have a way to just fetch them when they are needed, say, to drcrypt an email. You have to copy those keys to your local device. I'd prefer not to store private keys on a portable and easily lost device.
Sig Battery depleted. Reverting to safe mode.
I think its fairer to say Trillian did not fail because of their own efforts, but because the whole Instant Messaging scene was overtaken by mobile. Trillian is not the only IM service hurting today. Users have been quitting ICQ, AIM, MSN and other services for a while now.
Most people if they want to broadcast would send out a tweet. If they want to message a smaller circle of friends, mobile apps such as Whatsapp, LINE, Kakao etc. work nicely.
If Trillian could figure out a way to tap into the networks of Whatsapp, LINE, Kakao, Viber, Wechat and other mobile messaging apps, there might be a niche for their product.
Exchanging keys over the inernet?
Why would you do that?
Send me an encrypted email. My public key is easily found via my email address. You don't have to unconditionally trust my key, so don't give me the address and combination to your safe. But you can send me email and build a relationship
Sig Battery depleted. Reverting to safe mode.
The IMPP name has already been used by the IETF for its own standard IM protocol. Its really something that they would have accidentally chosen the same name of an already existing protocol.
I was a huge proponent of Trillian (and a paying customer) for quite some time. I used it to connect my AIM, ICQ, MSN, and Yahoo accounts.
At about the time I ditched ICQ, it seemed that Trillian was getting bigger and more bloated with features I didn't care about, and had frequent connection problems. And so I tried Digsby and loved it.
Then I believe I got a new computer, and for about a week I forgot to install Disgby. Turned out that nearly everyone I wanted to chat with was either on Facebook or SMS, and so I gave up on Digsby.
It's been well over a near now, and all I use are Facebook and SMS, and occasionally Skype. I can't think of a single person I've lost contact with because of that change.
-David
TLS is useless against PRISM which simply takes records from the server.
You need end-to-end encryption like OTR over XMPP. Afaik all the good XMPP clients like Adium and Jitsi include OTR be default. Of course OTR does nothing against traffic analysis. Worse, OTR is not a mandatory part of the protocol.
TorChat is resistant to traffic analysis, but nobody uses it. Also, it's badly designed so that, if many people did use it, then it'd be hard on the Tor network.
Pond is a new attempt traffic analysis resistant messaging and email over Tor, but Pond is in pretty early stages of development.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
Lets deal with protocol fragmentation by introducing another protocol.
SURELY NOT!!!!!
Many devices support encryption, and it seems to be becoming more common. It takes a lot of the worry out of it.
My advice-learn English, especially if you're claiming to live in America.
I rarely login to facebook, but I do have pidgin connected via XMPP and that works fine for chatting with non-technical friends on facebook. Facebook switching to a private protocol would be a shame, but I'm not sure I would bother installing a separate client.
Skype was never end to end encryption - and servers kept logs, in plain text. Skype was the epitome of a useless shell of security, as has now clearly been proven by MS's admissions. And no back door was needed. MS itself was scanning Skype messages and testing URLs. Skype and "secure" can only occur in the same sentence with "is not".
The cesspool just got a check and balance.
Easy for the NSA to get a false cert from the CA
Self signed certs are worthless too. Most people will accept any ould cert without wondering why a new one was issued
Do you have a single clue how Public Key encryption works do you?
Start here: http://computer.howstuffworks.com/encryption3.htm
Sig Battery depleted. Reverting to safe mode.
I didn't really understand it, but it looked like socialist millionaire's protocol used by OTR reveals man in the middle key fudging.
The Socialist Millionaire problem as applied to cryptography still requires a pre-shared key to be known by both parties. This is somewhat less onerous than verifying PGP key signatures in person, but still requires some form of secure key exchange and management. Supposing the man in the middle were able to acquire the shared secret, it would be possible for him to authenticate with both clients separately, then merely pipe un-encrypted data between the two encrypted channels.
If the protocol featuring this technique makes it appear as if a secure pre-shared key is not vital to the authentication process, then its users are victims of security theater.
It's implemented using a question and answer that should be known only to the two participants. I don't know if that counts as secure to you.
It's implemented using a question and answer that should be known only to the two participants.
From a cryptographic standpoint, this information forms the key, and is subject to all of the paranoia of any other secret key. From a practical/stenographic standpoint, this sort of information is much easier to conceal from surveillance than exactly four thousand ninety six uuencoded bits, and is probably much less likely to be intercepted auto-magically.
I don't know if that counts as secure to you.
When the secret knowledge is known by both parties, but not the NSA, it is a secure methodology. That sort of secret knowledge seems to be a precious commodity these days though.
The trouble here, which prevents this from being a universal solution to the wiretapping middleman elimination problem, is that you absolutely must have shared secret information with the other person at least once, and that would presumably have to be offline these days.