Hacker News new | past | comments | ask | show | jobs | submit login

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.

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's done nothing in crypto, and he's rolled his own protocol. That's historically been recipe for disaster regardless of how many honors you hold.

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.

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.

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.

You are correct to be wary. However, the MTProto java impl is here: https://github.com/ex3ndr/telegram-mt

Great, let's take a quick look.

TcpContext.java[1] says:

    MAX_PACKED_SIZE = 1024 * 1024 * 1024;//1 MB
    READ_DIE_TIMEOUT = 5 * 1000; // 15 sec
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.

[1] https://github.com/ex3ndr/telegram-mt/blob/master/src/main/j...

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.

Someone probably updated the constant and forgot to / was to lazy to update the comment

I looked for 4 minutes.

* 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.

Interesting. Some observations:

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.

Textsecure != Telegram. Textsecure is a replacement for SMS/text messages and Telegram for Whatsapp type messages. Totally different things.

And the only reason the critical bug was found is because it was open source. This, as far as I can see, isn't.

Looks like the programme is open source: http://telegram.org/source

> "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).

(iirc) If you're communicating with another TextSecure user then the messages go via the internet rather than over SMS

If you're communicating with a CyanogenMod WhisperPush user.

To bad there's no iOS app.

It looks like they are working on it:


There is. Search in app store for "telegram". There is also the source available on their website.

EDIT: Oeps, sorry.

Searching for "telegram" doesn't find a TextSecure client for iphone.

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.

"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?

In this case, even if you remove the ad-hominem attack (a bunch of randoms), a valid point remains: implementing crypto is already notoriously difficult, let alone designing cryptographic protocols.

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 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).

Thank you for the plug for yaxim. I've been searching around for a "good enough" jabber client for android, and while yaxim isn't there yet (for me: no otr support, single server) it looks like it's headed in the right direction!

Have you looked at ChatSecure? It has OTR, multiple servers, all that good stuff. It's not wonderful but it ain't bad (curious to hear what others have to say, I haven't really used much else)

I have it installed, but not really looked at it. My last "burst" use of xmpp was via facebook -- as most of my contacts don't use "plain" jabber right now. Before that I used it a bit for work -- but then rarely on my phone.

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).

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.

Often in the crypto world, these are exactly the good intentions with which the road to hell(pwnage?) is paved.

Knowing this, I hope you can appreciate why the burden of proof on your unproven team and approach is fairly high.

Absolutely, just trying to point out that the original poster raised some valid points that didn't deserved to be dismissed as "ad hominem". I haven't had a chance to dissect your work (but appreciate that you have made that possible in the first place) and I believe extraordinary claims require extraordinary scrutiny :)

How do you improve on OTR?

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.

If there is one place where an appeal to authority argument can hold place and not be seen as a fallacy is security. (it's not ad hominem btw)

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.

You're assuming that the average HN is in a position to audit crypto code.

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.

We have not 'rolled our own crypto'. We still use RSA, AES and DH.

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.

RSA in what mode?

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.

>Q: How secure is Telegram? >Very secure. [...]

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?

"As a result, Telegram is the fastest and most secure messaging system in the world."

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.

These people are "random nobodies" in cryptographic protocol design.

Could you find a way to say that without sounding like the Simpsons' Comic Book Guy? Maybe like this:


For further reference:


Also, they store everything to their cloud. Very secure indeed!

They did not roll their own crypto, it's using AES with Diffie-Hellman key generation. [0]

You can now argue whether that's still "from scratch". (Is building something on top of TCP "from scratch"?)

[0] http://core.telegram.org/api/end-to-end

Designing new protocols and constructions using primitives like AES and DH is exactly what cryptographers are talking about when they refer to "rolling ones own crypto".

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.

I think you need a new random function, the one you're currently using seems to be lacking some very basic features.

With all the revelations of built in weaknesses and such with existing encryption schemes... I don't know. I think we need a new one.

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.

Which revelations would those be?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact