MTProto's author is Nikolai Durov: http://en.wikipedia.org/wiki/Nikolai_Durov
He is one of most legendary math/programming champions of all time.
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.