>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.
He is one of most legendary math/programming champions of all time.
Colin Percival is similarly decorated, along with being a cryptographer (he's the FreeBSD security officer): http://www.daemonology.net/papers/
... yet even his crypto app Tarsnap was broken for over a year before he noticed, due to a typo during an innocent-looking refactoring change. http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...
And the only reason the critical bug was found is because it was open source. This, as far as I can see, isn't.
So we have a perfect storm of problems here: An author who has rolled his own crypto, isn't a cryptographer, and whose product is closed source. Trust Telegram at your peril.
It's worth noting that there's an app which already does what Telegram claims to do. It's called TextSecure, and it was written by Moxie Marlinspoke and several other big-name cryptographers: https://whispersystems.org/
... and it's open source: https://github.com/WhisperSystems/TextSecure/
... and they don't try to roll their own crypto: https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2
These aren't coincidences. It's basic necessity.
EDIT: Telegram is open source, so I was wrong about that and it'd be unfair of me not to mention it. But the other observations still apply. Until Telegram is verified to be secure, I don't think it's a good idea to trust it, especially when secure alternatives like TextSecure exist.
TextSecure has been a work in progress for two years: https://github.com/WhisperSystems/TextSecure/commits/master?...
Telegram seems to have been in progress for two months: https://github.com/ex3ndr/telegram-mt/commits/master?page=2
Telegram also seems to be the work of a single author. While TextSecure was written mostly by Moxie, there were several other contributing members.
TcpContext.java[1] says:
MAX_PACKED_SIZE = 1024 * 1024 * 1024;//1 MB
READ_DIE_TIMEOUT = 5 * 1000; // 15 sec
There are also writeInt() and readInt() method which seems to be little-endian, which seems odd for a network program. No comments near them.
Finally, there's a "Package" class which is just a byte array and a flag. And there's a method which writes it after a cute encoding for the length divided by 4. But there is no code which checks that the length is evenly divisible by 4. This may lead to incomplete Packages being written, with what effect I am not sure.
In summary, I wouldn't trust this program, having reviewed one of its source files mostly at random.
Oh, and despite its README saying that it is designed for mobile, it uses TCP Keep-Alive, which seems like a bad idea for mobile specifically (due to keeping the radio alive and draining the battery). Again, no comments explaining why.
[1] https://github.com/ex3ndr/telegram-mt/blob/master/src/main/j...
* Uses unpadded RSA in its authentication protocol
* Uses a novelty mode (IGE) for its bulk transport
* Does not appear to authenticate messages (other than by using IGE)
* Or, at least, what authentication it is doing must be happening after it decrypts data, not before
I could be wrong about any of these things, because again, 4 minutes. But this design does not look sturdy.
EDIT: Oeps, sorry.
Looks like the programme is open source: http://telegram.org/source
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 misdirection talking about TextSecure (which looks great, by the way). They don't roll their own crypto algorithms, but they have definitely tweaked and modified the OTR protocol for their own purposes in order to make it more secure. I'm left wondering why TextSecure is held up in contrast to someone who uses their "own" secure messaging protocol.
Whether or not this Telegram app is trustworthy (the lack of full source is suspicious), I have no idea. I would personally pick TextSecure over it.
It is not in fact reasonable to compare Telegram's ad-hoc protocol to the "extensions" TextSecure has.
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.
An ad-hominem attack. This is Hacker News and their work is open, how about making a statement after researching the actual code instead?
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.
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 that can be clearly communicated to the user and to developers, and does not require a custom crypto protocol. You can achieve the same effects with using existing and tested libraries.
Edit: Disclaimer: I am the developer of the yaxim Android XMPP client and the operator of the public yax.im XMPP server (both available at http://yax.im).
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).
Knowing this, I hope you can appreciate why the burden of proof on your unproven team and approach is fairly high.
We use well audited crypto primitives with formal proofs because they're known safe, or at least orders of magnitude safer than whatever these fools cooked up.
tl;dr provide proof or gtfo. We're not here to audit you.
When you're rolling out a secure system + implementation you want to use algorithms that have been proven, tested and certified as correct. It's a delicate field that can't be approached like your standard software development field. Yes, being a "random" and developing your own encryption algorithm out of the box is bad. Never trust anything like that. Period.
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.
I've changed the part in the FAQ that seems to be one of major sources of this controversy, so that it no longer reads "built from scratch". This was poorly applied marketing language — we do use time-tested security algorithms. Even though Telegram doesn't uses MTProto instead of HTTPS due to mobile speed and trust issues.
AES in what mode? IGE? Why are you using an authenticated cipher mode from the 1970s that predates every modern AEAD construction?
DH with what group? How do you authenticate the exchange? How does forward secrecy work?
Saying "we didn't roll our own: we use RSA, AES, and DH" is extremely worrying; it suggests that you're not aware of where the complexity in a cryptosystem lives. Anybody on HN can write the trivial code to ask the JCE for an RSA or an AES. You have to do better.
It's just an advertisement like any other. I'm sure the people responsible for the content of the FAQ know their target audience, so they know the wording will work for those whose attention they care about.
It is good that we, technical people, understand how completely worthless those words are. It begs for the "citation needed" label.
The question for me is this: do ordinary people (non-programmers in this case) really believe in most of the things ads tell them?
That's a very bold and yet to be proven statement. Probably any crypto expert would know better than to say that.
This paragraph exactly pin points the problem with being a cryptographic nobody.
PS. I do like their icon designer.
https://news.ycombinator.com/item?id=6913705
For further reference:
You can now argue whether that's still "from scratch". (Is building something on top of TCP "from scratch"?)
Look at the description of their protocol, particularly the handshake, which negotiates number-theoretic parameters, and try to make a list of all the checks they'll need and the additional protocol that they'd need to specify just to make the handshake secure.
Not only that, but the crypto in Telegram is idiosyncratic; for instance, this is the only system I've ever seen that used IGE mode.
That said, it should probably be developed by a panel of experts. I would love to see something by Bruce Steiner et al, where 'et al' is a group that he selects. As you pointed out a group without heavy crypto experience can't realistically roll their own and have it actually be secure.