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

141–150 of 231 posts

Re: Telegram - secure, free messaging

#141

Post by moxie »

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 secure (if aging) primitives, they've made some extremely unusual protocol choices that they need to publicly justify rather than simply describing in an API doc. Just at a glance, the use of modes like Infinite Garble Extension (a failed mode for Kerberos) is troubling, they made up their own KDF (with no proof), and they make what appear to be some amateur mistakes with how they use RSA.

I'm obviously biased, but if you want a mobile-oriented asynchronous messaging protocol, at this point I think the Axolotl ratchet should absolutely be its basis: https://www.whispersystems.org/blog/advanced-ratcheting/

If Telegram folks are on this thread, I'd encourage you to take a look at the TextSecure protocol. If you think it's interesting, you can federate into our network, get a provably secure asynchronous forward secrecy protocol, and also have access to an existing 10MM user base.

Re: Telegram - secure, free messaging

#143

Post by TelegramApp »

ge0rg wrote: post #101
TelegramApp wrote: post #92

Earlier quoted context omitted.

Still, there are sometimes valid reasons for not re-using existing solutions. In our case, we needed something that is both secure and competitive in comparison to mass market solutions in terms of speed, working on weak connections and usability. Disclaimer: I work for Telegram.

It is a really bad idea to compromise security for speed and connection stability. Processing power is a question of scaling the hardware, communication speed is hardly affected by a proper encryption scheme, neither is reliability of the application-layer protocol. Usability, however, is a different beast. You must compromise security to make a chat application appeal to "regular" users. Still, this is a trade-off t…

MTProto still uses RSA, AES + DH. So I would disagree that what we have here means 'compromising security for speed and stability'. It is rather optimizing for speed and stability, while staying secure.

Re: Telegram - secure, free messaging

#144

Post by DanBC »

userulluipeste wrote: post #66
na85 wrote: 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.

"Oh good, a bunch of randoms have rolled their own crypto. I stopped reading at this point." An ad-hominem attack. This is Hacker News and their work is open, how about making a statement after researching the actual code instead?

Why bother reviewing the code? It's almost certainly a waste of time to do so.

We know that writing crypto is hard and experienced crypto programmers make mistakes.

The possibility of a naive programmer creating a sturdy piece of crypto software with no previous experience is vanishingly small.

Re: Telegram - secure, free messaging

#146

Post by ToastyMallows »

rattray wrote: post #124
ToastyMallows wrote: post #121

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.

Ah, duh. I was analyzing too in-depth. Thanks.

Re: Telegram - secure, free messaging

#147

Post by xnyhps »

TelegramApp wrote: post #84
huhtenberg wrote: post #22

Looking at [1], it has several red flags. The replay protection is overly complicated and doesn't kick in after the message is decrypted. This makes it possible to DoS the server with forged messages. Key derivation uses a custom scheme. Typically there's no reason NOT to piggy-back on existing schemes and there's plenty to choose from - from TLS to IKE. Also, as already mentioned, there's again NO reason not to use…

The reason for designing something new was this: in order for really secure messaging to catch on among the masses today — it needs not only be secure. When you want to compete with the likes of WA, you also need be fast and reliable on weak mobile connections. TLS/HTTPS is slow and takes a lot of time to restore connection on fragile networks. MTProto was born as a result of an experiment: whether it would be possib…

Even WA doesn't roll their own key deriviation scheme, they use PBKDF2+SHA1.

Re: Telegram - secure, free messaging

#148

Post by nexttimer »

ge0rg wrote: 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…

Also, how can you claim to have a secure app when it runs on a closed-source operating system? (Even more, we know about Microsoft handing over security holes to the NSA - why would Apple or Google not do the same?).

It's like saying "this heat is really cold". In other words: a contradiction in itself.

Only open-source apps on open-source operating systems can start making claims about security and trustworthiness.

Re: Telegram - secure, free messaging

#149

Post by jgg »

tptacek wrote: post #131
jgg wrote: post #115

Earlier quoted context omitted.

I scratched my head after reading your comment, and waited to see if anyone else would say something. Colin's problem was that his (hand-written, from the looks of it) crypto primitives allowed him to use AES-CTR with a non-incrementing counter. I'm not sure if it's appropriate to say that in relation to a comment about "rolling your own protocol." I see that as a low-level problem. Further, you've pulled a misdirect…

The extension you're thinking about is Trevor Perrin's Axolotl ratchet, which is (a) the product of an actual cryptographer, (b) used in more than one system (it's also incorporated into Adam Langley's Pond), (c) has been reviewed by experts, and (d) is entirely specified, with a public domain spec. It is not in fact reasonable to compare Telegram's ad-hoc protocol to the "extensions" TextSecure has.

I knew someone was going to say that...

The only point I wanted to make is that someone using a protocol (variant or original) that someone hasn't seen before is not inherently damning in and of itself. Mine was a general point, and yours is a practical one, which I mostly agree with.

The parent comment seems to imply that there is a pre-written solution for all cryptographic problems that can be dropped into place, and I also felt they were conflating high-level protocol problems with low-level cryptographic primitive problems (i.e., "rolling your own crypto" being used in a general sense). I think it is reasonable to compare two "non-standard" systems in that context, especially given how modifying an already-trusted protocol can go haywire if something is done wrong.

Whether or not an extension or protocol is reviewed, has a public spec, comes from a cryptographer, started from a more trustworthy protocol or has other practical elements that make it appear trustworthy on the surface, is another matter entirely. It 100% matters in practice, but not for a more general point.

I understand that Telegram is doing everything from the ground up and that TextSecure started with OTR, and that the ratcheting extension wasn't pulled out of thin air. I am not claiming in practice that Telegram and TextSecure are comparable (I did not mean to take anything away from TextSecure or the ratcheting scheme), and I personally would not touch Telegram in light of further snooping about and comments posted in this HN thread.

Post reply on HN