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/
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.
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 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.
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.
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.
So those are bugs, though I'm not sure if documentation or code. Most importantly to me, there are very few comments in the code, and the few there are are incorrect. One might infer that this code has been written either in haste, or by someone who believes that comments are not needed in this sort of systems code.
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.
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.
> "For the moment we are focusing on open sourcing the things that allow developers to quickly build something using our API. We started with Android and Linux, since these platforms are the most open, recently we published the iOS app code as well. We will be releasing more code eventually." -- http://telegram.org/faq#q-why-not-open-source-everything
It looks like TextSecure encrypts your actual texts, for which you still pay, while Telegram also takes care of delivery, for free, and does it faster and better than SMS (which should be pretty darn easy, what with SMS doing such a very bad job indeed).
I don't care if it was written by Eric A. Young -- I think history has shown that crypto takes a long time and many iterations to get to a point where it's secure and trustworthy. No single person is going to come down from the mountaintop with a working, secure and correct protocol from scratch. That just doesn't seem to be how it works.
He is one of most legendary math/programming champions of all time.