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

211–220 of 231 posts

Re: Telegram - secure, free messaging

#211

Post by floatboth »

Tepix wrote: post #159
andor wrote: post #16

Like Threema, they use the PGP model, instead of OTR...

What do you mean exactly? According to the FAQ, Threema offers perfect forward secrecy: Yes, Threema provides forward secrecy on the network connection. Client and server negotiate temporary random keys, which are only stored in RAM and replaced every time the app restarts (and at least once every 7 days). An attacker who has captured the network traffic will not be able to decrypt it even if he finds out the long-te…

on the network connection

They do use forward secrecy on SSL, but not on the messages themselves.

Re: Telegram - secure, free messaging

#212

Post by kpierre »

Confusion wrote: post #200
kpierre wrote: post #96

Earlier quoted context omitted.

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.

it's not just overly complex, the use of 'dependent types' for this indicates that the author doesn't understand how they are really useful. neither he seems to know what serialization is, he apparently wants to serialize linked lists.

Re: Telegram - secure, free messaging

#213

Post by ash »

niketas wrote: post #207

To whom it may concern: Pavel Durov, one of the authors of Telegram, announced he will pay $200K (or 200 BTC) to decrypt his traffic http://tjournal.ru/paper/durov-decifer-telegram

Yes, but not yet. He plans to announce the reward in a week. No encrypted traffic published yet.

Re: Telegram - secure, free messaging

#214

Post by TelegramApp »

tptacek wrote: post #186
sillysaurus2 wrote: post #185

Earlier quoted context omitted.

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.

In order to clarify a few points in our setup, we've added this scheme to the protocol description page [0],[1].

We are indeed using well-known older algorithms, created in the days when bandwidth and processing power were both a much rarer commodity. This has valuable side-effects for modern-day mobile development, provided one takes care of the known drawbacks.

The weakspots of the said algorithms are also well-known, and have been exploited for decades. We used these algorithms in such a combination that, to our best knowledge, prevents any known attack from possibly succeeding. Although we’d be grateful to see any evidence of the contrary (so far absent from this thread) and update our system accordingly.

While other ways of achieving the same cryptographic goals, undoubtedly, exist, we feel that the present solution is both robust and also sucсeeds at our secondary task of beating unencrypted messengers in terms of delivery time and stability.

[0] ­­– https://core.telegram.org/img/mtproto_encryption.png [1] - http://core.telegram.org/mtproto/description

Re: Telegram - secure, free messaging

#215

Post by TelegramApp »

moxie wrote: post #197
TelegramApp wrote: post #184

Earlier quoted context omitted.

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, the…

> The consensus seems to be that you're doing..

Now, again, could I somehow direct your attention away from speculations and to what we are ACTUALLY doing (as, again, documented here [0], and now here as well [1]).

1. We are not doing plain encrypt-and-mac.

2. The SHA1 in question is for raw unencrypted data.

3. The message key is SHA1-dependent.

4. Note that the AES key and iv depends on that SHA1.

This can be described as a generic composition of cipher with ciphertext, encrypted by a MAC. The resulting data-dependant variable key denies all common attacks.

As for KDF, what particular solution do you have in mind? And even then — certainly, alternative solutions exist, but we do not see how changing this point would affect our system as whole. [1] As stated before, we'd welcome any information on attacks that could in reality threaten the actual setup.

[0] - http://core.telegram.org/mtproto/description [1] - https://core.telegram.org/img/mtproto_encryption.png

Re: Telegram - secure, free messaging

#217

Post by TelegramApp »

sillysaurus2 wrote: post #188
TelegramApp wrote: post #184

Earlier quoted context omitted.

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…

No. What we mean is, as I've just noted in the reply to tptacek, that so far no attack was named that could harm the setup as described in our docs. And since this setup also delivers the performance that we require in terms of speed, we do not see why it would be necessary to change our approach to KDF.

Re: Telegram - secure, free messaging

#218

Post by ash »

TelegramApp wrote: post #217
sillysaurus2 wrote: post #188

Earlier quoted context omitted.

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…

No. What we mean is, as I've just noted in the reply to tptacek, that so far no attack was named that could harm the setup as described in our docs. And since this setup also delivers the performance that we require in terms of speed, we do not see why it would be necessary to change our approach to KDF.

> so far no attack was named that could harm the setup as described in our docs

Even as a complete newbie in cryptography I can see a problem in your reasoning. "Guilty until proven innocent" is the default when judging on a system. "No attack was named" because Telegram uses algorithms combination that was not proven with time. Nobody used them like this before. Why would anyone try to break it if it wasn't used?

As a potential user of Telegram I don't trust it enough to use it. It's more likely that someone with resources (e.g. government) could eventually break your system than it could break another - time-proven - system.

Re: Telegram - secure, free messaging

#219

Post by alandarev »

TelegramApp wrote: post #160
moxie wrote: post #141

The reason that cryptographers laugh at people who advertise "military grade cryptography" or "we use AES256" is because the choice of crypto primitives is often less important than how they're composed. Those phrases tend to reflect a critical misunderstanding of that, and often mean that a project is using secure primitives in a way that completely undermines their security. At a glance, while this project is using…

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…

Speaking of masses...

Is vkontakte [1] (russian social site) being somehow involved? I got confused by the illustrative images strongly resembling the vkontakte images.

Not to dive into Russian folk, but those look too culturally localized.

[1]: http://vk.com

Re: Telegram - secure, free messaging

#220

Post by n1kh1lp »

techquery wrote: post #57
joosters wrote: post #21

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…

> Anyway yep, these marketing stuff is a bit too dubious, but what should they write?

How about some benchmarks to support this claim?

Post reply on HN