Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Telegram - secure, free messaging

telegram.org

Post reply on HN
Print view View original

181–190 of 231 posts

Re: Telegram - secure, free messaging

#181

Post by sillysaurus2 »

TelegramApp wrote: post #178
tptacek wrote: post #173

Earlier quoted context omitted.

Regarding IGE: Gligor and Donescu, 1999; a summary on a mailing list of the attack: https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UG... Long story short: you get integrity protection from IGE by relying on the fact that a bit error anywhere in the stream will irrevocably corrupt the rest of the stream, so you create an authentication code by sticking an all-zeroes block or (like I think Telegram does) a m…

We use SHA1 (see 'message key' here: https://core.telegram.org/mtproto/description ). IGE is used instead of CBC.

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

Re: Telegram - secure, free messaging

#182

Post by tptacek »

sillysaurus2 wrote: post #181
TelegramApp wrote: post #178

Earlier quoted context omitted.

We use SHA1 (see 'message key' here: https://core.telegram.org/mtproto/description ). IGE is used instead of CBC.

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.

Re: Telegram - secure, free messaging

#183

Post by tptacek »

TelegramApp wrote: post #177
tptacek wrote: post #171

Earlier quoted context omitted.

What's the message format you're using for RSA? I see RSA in the "pq" code of your Java client library; I see you asking Java for an "unpadded" instance of the RSA encryptor; I see you using RSA in its encrypting operation (not signing). Great crypto software avoids RSA. Good crypto software uses OAEP when RSA is used to encrypt. Crappy crypto software (see: DNSSEC) uses PKCS1v1.5. What are you using? I didn't look c…

This version of the client is using manual padding with random bytes. This isn't too bad, considering the SHA1 presence. (See #4 here: https://core.telegram.org/mtproto/auth_key ) The server now supports OAEP, although this has yet to find its way into the docs and clients. We will update. Thank you!

This is a brand new application, right? Why is it built on '90s (or, worse, '70s) cryptography?

You need to publish the server-side source code for me to have any chance of making sense of this. I only see the client side of the connection in your source code, not the server response.

Re: Telegram - secure, free messaging

#184

Post by TelegramApp »

moxie wrote: post #164
TelegramApp wrote: post #160

Earlier quoted context omitted.

Two questions for you: 1. Kindly be more specific about our RSA implementation. Please note, that we only use RSA with public keys, not private. If you are aware of any possible attacks on this setup, please let us know. 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. Thank you fo…

> 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 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.

Re: Telegram - secure, free messaging

#185

Post by sillysaurus2 »

tptacek wrote: post #182
sillysaurus2 wrote: post #181

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.

Ah. In case anyone else was wondering why this works, it's because IGE has the property that if you corrupt the ciphertext, the plaintext is corrupted all the way from that point forwards. Therefore, appending the SHA1 of the message body is enough to check the integrity. (Appending a block of zeroes would be enough, too.)

Re: Telegram - secure, free messaging

#186

Post by tptacek »

sillysaurus2 wrote: post #185
tptacek wrote: post #182

Earlier quoted context omitted.

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

Ah. In case anyone else was wondering why this works, it's because IGE has the property that if you corrupt the ciphertext, the plaintext is corrupted all the way from that point forwards. Therefore, appending the SHA1 of the message body is enough to check the integrity. (Appending a block of zeroes would be enough, too.)

Except that IGE mode is broken.

How broken is it here? Who knows. Professional cryptographers would use an AEAD mode with a security proof, or the generic composition of a cipher (w/proof) with ciphertext encrypted by a MAC (w/proof). Instead, this system uses a '70s block mode (that nobody else uses) and a hash function from the '90s.

Re: Telegram - secure, free messaging

#187

Post by chrisballinger »

ge0rg wrote: post #100
Ihmahr wrote: post #89

Earlier quoted context omitted.

Yes, I have been using chatsecure and I know it is much more secure but it is almost unusable on ios because it can not run in background. As for the false sense of security, you're probably right.

but it is almost unusable on ios because it can not run in background Unfortunately, the only way around that is to integrate with Apple's Push Service, which means you need to run a server-side component which notifies Apple (and which in turn notifies your app). This is not specified for XMPP, so most "XMPP clients" for iOS instead store your credential on the app developer's infrastructure. However, this problem i…

I am working on a protocol-agnostic, federated push messaging layer for ChatSecure-iOS but it will be interesting to see if anything else pops up in the meantime.

Re: Telegram - secure, free messaging

#188

Post by sillysaurus2 »

TelegramApp wrote: post #184
moxie wrote: 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…

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.

What's this mean? You've created your own KDF, and the questions were: why is it secure, and why didn't you use an already-proven KDF? Unless I'm misreading something, it sounds like you've responded, "It's not that important, because our target market isn't people who care about their security." Is that correct?

EDIT: Judging by the upvotes, at least 5 other people are interested to hear your thoughts on this. Considering this submission is almost off the frontpage, that's a lot. As a security product, you should consider clarifying your position on this, because your statement currently sounds like, "We don't think security is a big deal since it's not a big deal to our target market."

Re: Telegram - secure, free messaging

#189

Post by e12e »

finnn wrote: post #157
e12e wrote: post #110

Earlier quoted context omitted.

Thank you for the plug for yaxim. I've been searching around for a "good enough" jabber client for android, and while yaxim isn't there yet (for me: no otr support, single server) it looks like it's headed in the right direction!

Have you looked at ChatSecure? It has OTR, multiple servers, all that good stuff. It's not wonderful but it ain't bad (curious to hear what others have to say, I haven't really used much else)

I have it installed, but not really looked at it. My last "burst" use of xmpp was via facebook -- as most of my contacts don't use "plain" jabber right now. Before that I used it a bit for work -- but then rarely on my phone.

Now that google is killing talk in favour of proprietary hangouts, I predict it'll be a while before I'm a serious xmpp user again.

Sadly it's very hard to push process changes when one are in the minority in a group... Thanks for the reminder though, it does look like it full-fills most of my needs (and fixes annoyances I've encountered with other android clients).

Post reply on HN