Hacker News new | past | comments | ask | show | jobs | submit login

These latest news have convinced me that Telegram currently has the highest potential to be the right IM tool at my current workplace. I have one question that doesn't seem to be covered anywhere (FAQ, Google): What about Offline messages? I'd like to be able to send encrypted messages even when people are offline - on smartphones it could make use of push notifications, on the Desktop it would just wait until the client goes online again. Skype doesn't work reliably for this scenario, as in both clients (for the sender even the same client on the same device) need to be online for the message to be sent. The last implementation that worked reliably seemed to be MSN, which is dead now. How does Telegram behave?



Why? They just announced that one of the main advertised features of their IM software - the secret chat functionality - was so badly broken that it was worse than not having it at all. It provided absolutely no protection against them eavesdropping on their users, yet those users were chatting under the illusion that they were secure against such eavesdropping. Worse, it seems like the Telegram developers consider this to be a theoretical problem rather than an actual compromise because you can trust them not to spy on you.


That's interesting, I didn't interpret the news this way. I haven't seen secret chat functionality mentioned anywhere yet - I was assuming that secret chat shouldn't be affected by these nonce messages since the secret key shouldn't touch their servers according to their documentation. Do you have any source on this?


The linked blogpost actually says that the attack is against secure chat and explains what it does, it just underplays how serious it is.

Basically, when setting up a secret chat the two parties use something called a Diffie-Hellman key exchange to agree on a secret encryption key without eavesdroppers being able to tell what the key is. However, the parties can't tell whether they've securely agreed on a key with the right person - the Telegram server could do a man-in-the-middle attack by doing the other side of the DH key exchange with each party itself so that it knows all the keys, and then decrypt log, and re-encrypt all the messages between them. The fairly standard solution Telegram uses is to allow both parties to manually check that they agreed on the same keys - with normal Diffie-Hellman, this is enough to ensure no-one has MITMed the connection. Unfortunately, their protocol is modified from normal DH in a way that makes this check useless. The server can launch a MITM attack that causes both parties to agree on the same key, so they think they've securely agreed on a key that no-one else has when the server's got a copy too and is decrypting all their messages.


Seems like I had potatoes on my eyes. Your explanation made the whole thing quite a bit clearer to me than the original post, thanks for that. I think it's good that this weakness is now in the open - this will create some pressure on Telegram to solve it since, as I understand, it compromises one of the main features of their service. Their way of handling the fix will decide whether they should be taken seriously I think.


These latest news have convinced me that Telegram currently has the highest potential to be the right IM tool at my current workplace.

Why is that? This latest revelation should give less faith in Telegram, not more.


See my replies to makomk and ceejayoz.


Really? The fact that they addressed security concerns with "they're bullshit, here, we'll prove it - break out system!" and then had to pay out nearly immediately convinced you they're awesome?


Yes it does. Show me another non-profit Open Source (mostly) IM service that invests this heavily in seamless encryption and I'll change my opinion. The weakness that they found could have easily been brushed off as non-exploitable, yet they didn't, instead encouraging more security experts to become involved by paying out immediately.


To name just one alternative, the OTR developers have done far more to make seamless, open source encryption of IMs possible than Telegram - regardless of how much cash Telegram are willing to throw around. Even if the secret chat feature worked perfectly as intended, it'd still be both less usable and less secure than OTR. It requires users to manually validate key hashes in order to stay secure, a requirement the OTR developers dealt with years ago because they found users simply didn't do it. It also lacks forward secrecy which is especially important for mobile devices that can be stolen or lost.


OTR sounds great, I just wish I'd find an easy-to-setup-and-use, good looking Windows client, such that I could convince non technical decision makers to adopt it. Adium does that for me on OSX, but I don't think Pidgin is a good match, except if something big has changed since 2-3 years ago when I last gave it a try.


Investing heavily is meaningless if you're investing badly.

Building an encrypted IM service with bad crypto is like investing in blacksmiths in the early 1900s.


The question whether their Crypto is bad is still out IMO - these recent findings still don't seem to be that big of a deal to me - as with all other IM services I have to trust the service provider for their integrity - yet here I have an alternative provided by a non-profit organization with some scientific credentials that offer an open API - as opposed to Skype, WhatsApp, Facebook et al. We currently use Skype for business purposes, but Microsoft's investment away from P2P makes me think that for privacy reasons alone, it's a bad idea. I'm always open for suggestions, but so far I haven't found anything really viable (well designed clients, well integrated encryption, open APIs). That's why I'm excited for Telegram.


What's wrong with encrypted Jabber?


On OSX I'm happy with Adium, but last time I've used Pidgin it was a lot of work to configure it the way I want. That would still work for me, but to roll it out for an organization it would meet quite some resistance. So the problem with XMPP for me is the client situation.


> So the problem with XMPP for me is the client situation

... which is fixed by a better client. That requires skills, but different ones from designing a new crypto protocol.

Given the PR efforts of the telegram people, they might actually be better XMPP+OTR+TextSecure+... client implementers than crypto designers (and maybe even better client implementers than most of the people who build clients right now since the situation _is_ bad).


I agree with that. Why they didn't go with this route is something I'd like to know as well - Telegram's FAQ is quite vague on this issue. But still, I prefer a reasonably secure service with great clients on all platforms, over a perfectly secure service with ugly clients that I can never 'sell' to decision makers.


> provided by a non-profit organization

huh?


Are you trolling or for real? 1) Telegram is NOT open soure. 2) OTR has been around for years.


> Show me another non-profit Open Source (mostly) IM service that invests this heavily in seamless encryption and I'll change my opinion.

You can't measure how secure something is by looking at how much money has been invested in it.


Messages in secret chats are stored on server until downloaded by recipient. So there is no such problem like in Skype.

Push notifications also work fine there, except on iOS they don't contain any message data, just "You have a new message", probably because server doesn't know what's inside encrypted message. Although havent tried their android client.


Great info, thanks. I didn't expect the message to be visible in Push notifications, it's obvious to me that this couldn't work - especially with client side encryption. Whether 'Secret Chats' are truly client side encrypted is another question (see the discussion with one of your siblings).


> Whether 'Secret Chats' are truly client side encrypted is another question

I don't think anybody has suggested that they aren't client side encrypted, only that the way in which the encryption is used renders it ineffective.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: