Live data from Hacker News

Telegram - secure, free messaging

telegram.org

191–200 of 231 posts

Re: Telegram - secure, free messaging

#191

Earlier quoted context omitted.

There are certain data (session, message ID, session message, server salt) that are contained in the initial part of the unencrypted message; the message key must be the same as the 128 lower-order bits of the SHA1 of the message body (including session, message ID, etc.) Not even HMAC-SHA1, just "SHA1"? So you leave yourself open to length extension attacks? http://en.wikipedia.org/wiki/Length_extension_attack

I believe they are using SHA1 with IGE mode, giving each message a trailer that is the SHA1 hash of the message.

Disclaimer: I am not a cryptographer, and have only gotten to #40 in Matasano's challenges.

They appear to be trying to use encrypt and mac, and not as far as I can tell relying on IGE mode to provide authentication. See the "Message Key" and "Important Tests" sections here: https://core.telegram.org/mtproto/description

There is also not, as far as I can tell from reading the protocol description above and the source code here: https://github.com/ex3ndr/telegram-mt/blob/master/src/main/j... (in particular the EncryptedMessage method, lines 447 to 460) any sort of key in the MAC, it's just SHA-1 of the plaintext. It's also not encrypted as far as I can tell, it's listed in the unencrypted "external header" in the protocol description.

I can't think of an attack from this, but the fact that an adversary can generate a valid MAC for _any message_ by simply SHA-1'ing it seems really scary.

Re: Telegram - secure, free messaging

#192

Earlier quoted context omitted.

Curious, why are those bugs?

5ms * 1000 != 15s. It's unclear whether the comment is outdated, and 5s is in fact intended, or whether 15s was intended and the 5 is a typo (therefore a bug, although unlikely a critical one). Either way, it's certainly sloppy programming, and the kind of thing that can lead to more serious problems.

Someone probably updated the constant and forgot to / was to lazy to update the comment

Re: Telegram - secure, free messaging

#193
post #107

I have not run the app, but from the Android source code it looks like this "secure" app is uploading your contacts including full names and all their phone numbers into the "cloud": MessagesController.readContacts() [0] is called on creation of the MessagesActivity. When invoked for the first time, it collects first names, last names and phone numbers from the Android Contacts interface, creates a table containing t…

That is correct, Telegram does upload names and numbers — naturally, after receiving permission to do so. (see also: http://telegram.org/privacy ) Apart from identifying Telegram users among the user's friends, this also enables us to use proper names in notifications on the iPhone, as well as facilitates moving between devices. But you have highlighted an important issue. Our android developer relied on the system p…

> That is correct, Telegram does upload names and numbers

Ugh, this is such douchebag behavior for something that purports to be a "secure" app. Stop it immediately, please.

Re: Telegram - secure, free messaging

#194
post #164

Earlier quoted context omitted.

> 2. And what problems with IGE are you aware of? Any known attack? As far as we know, it is the ubiquitous CBC that has had issues. And by the way, Kerberos had to abandon PCBC - not IGE. IGE was the first attempt at an "authenticating encryption mode," originally for Kerberos. It was a failed attempt (it does not provide integrity protection), and had to be removed. That was the beginning of a 20 year quest for an…

2. A passing look at the docs would reveal that we do not use IGE that way, and instead use SHA1 for integrity check (see 'message key' here: https://core.telegram.org/mtproto/description ). The problems you mentioned as endemic to IGE used for integrity verification, are therefore irrelevant in this case. As for KDF, going for slower provable algorithms used for each incoming\outgoing packet may be a preferred solut…

Why is a KDF slower? Using KDF2 with SHA-2 (SHA-256) is not slow at all!

Re: Telegram - secure, free messaging

#195
post #7

From their FAQ: > Q: How secure is Telegram? > Very secure. We are based on a new protocol, MTProto, built by our own specialists from scratch, with security in mind. At this moment, the biggest security threat to your Telegram messages is your mother reading over your shoulder. We took care of the rest. Oh good, a bunch of randoms have rolled their own crypto. I stopped reading at this point.

I think you need a new random function, the one you're currently using seems to be lacking some very basic features.

Re: Telegram - secure, free messaging

#197
post #164

Earlier quoted context omitted.

> 2. And what problems with IGE are you aware of? Any known attack? As far as we know, it is the ubiquitous CBC that has had issues. And by the way, Kerberos had to abandon PCBC - not IGE. IGE was the first attempt at an "authenticating encryption mode," originally for Kerberos. It was a failed attempt (it does not provide integrity protection), and had to be removed. That was the beginning of a 20 year quest for an…

2. A passing look at the docs would reveal that we do not use IGE that way, and instead use SHA1 for integrity check (see 'message key' here: https://core.telegram.org/mtproto/description ). The problems you mentioned as endemic to IGE used for integrity verification, are therefore irrelevant in this case. As for KDF, going for slower provable algorithms used for each incoming\outgoing packet may be a preferred solut…

> 2. A passing look at the docs would reveal that we do not use IGE that way, and instead use SHA1 for integrity check (see 'message key' here: https://core.telegram.org/mtproto/description). The problems you mentioned as endemic to IGE used for integrity verification, are therefore irrelevant in this case.

The consensus seems to be that you're doing encrypt-and-mac, where the mac is just a sha1? If that's true, then you're relying on broken properties of IGE (not provably UF-CMA), and your protocol does not provide provable integrity. That's an essential part of any secure protocol.

> As for KDF, going for slower provable algorithms used for each incoming\outgoing packet may be a preferred solution for projects aimed at the relatively small security crowd. But we don't really compete in this area, our competition is WhatsApp and other mass market messengers.

That's interesting, because the thing you've made up is actually slower than a provably secure KDF.

Re: Telegram - secure, free messaging

#198

So many dubious claims on just the front page: * 'delivers messages faster than any other application' - any application? Hmmm. They must be using magic. * 'messages are heavily encrypted and can self-destruct' - but like every system, the self-destruction is not assured since it's impossible to enforce. * 'keeps your messages safe from hacker attacks' - a bold claim. Maybe they do some stuff to protect messages, but…

Have you tried the app? I've moved my top-5 chats from WhatsApp just because of speed! The messages are sent really fast. But if you know any other messenger apps for iOS, which are just about so fast, I'll definitely give them a try. Anyway yep, these marketing stuff is a bit too dubious, but what should they write? * is rather fast, faster than some applications * can self-destruct, but sometimes can not (Ha!) * et…

Registered two hours ago and you're taking offense to criticism of their marketing. Coincidence?

Re: Telegram - secure, free messaging

#199
post #83

If this is closed source (and the source seems to be only implementing API calls to a closed system) then it's fair to assume that this application is probably insecure or has backdoors. Also if the private key is stored in the cloud then it's likely to be subject to requisitions.

Private keys for secret chats are only stored on the two participating devices. As for server code — open sourcing the server code wouldn't really do much to improve trust. You would still have to trust us that we are using THAT code, not something different.

"... open sourcing the server code wouldn't really do that much to improve trust."

It would allow people to run your code (if they like it) on their own servers. Then they wouldn't need to trust you.

Re: Telegram - secure, free messaging

#200
post #96

Earlier quoted context omitted.

Is anything wrong with it?

it's ridiculous, pseudo-mathematical, and a severe case of NIH syndrome :-) Peano numbers for data definition language? are you serious?

You can drop the first two. And the third can have different motivations: I think here we just have a mathematician with sufficient time on their hands who enjoyed coming up with this. I think the primary valid complaint is: overly complex for its task.
Post reply on HN