>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.
An ad-hominem attack. This is Hacker News and their work is open, how about making a statement after researching the actual code instead?
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.
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 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.
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.
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.
1. Kindly be more specific about our RSA implementation. Please note, that we only use RSA with public keys, not private. If you are aware of any possible attacks on this setup, please let us know.
2. And what problems with IGE are you aware of? Any known attack? As far as we know, it is the ubiquitous CBC that has had issues. And by the way, Kerberos had to abandon PCBC - not IGE.
Thank you for the offer to join in the project you represent. However, we feel that what we are doing is going in a somewhat different direction and has its own potential.
The team behind Telegram, led by Nikolai Durov, consists of six ACM champions, half of them Ph.Ds in math. It took them about two years to roll out the current version of MTProto. Names and degrees may indeed not mean as much in some fields as they do in others, but this protocol is the result of thougtful and prolonged work of professionals.
The basic copy on telegram.org rightfully appears as simplistic to the Hacker News resident. It was written for the general public, since we want to bring secure messaging to the masses — not just to the security geek, who has it already (in oh so many forms).
But for the technically minded we provided rather detailed documentation for our protocol: http://core.telegram.org/mtproto and API: http://core.telegram.org/api
We would be glad to respond to criticism, but not on the level of "I looked at it for 4 minutes, maybe they didn't think about X" (as another guy in the comments below put it), or "why didn't you just use this?".
If anybody here can identify a specific point and prove that it is vulnerable and can be hacked a certain way, we are ready to respond and\or fix, if neccessary. Gentlemen?
IGE was the first attempt at an "authenticating encryption mode," originally for Kerberos. It was a failed attempt (it does not provide integrity protection), and had to be removed. That was the beginning of a 20 year quest for an authenticating encryption mode that works, which recently culminated in modes like OCB and GCM. I don't see any integrity protection documented anywhere in your protocol spec, so if you're relying on IGE, it's broken.
What's more, any "problems" with CBC (I assume you're referring to padding oracle attacks) are not specific to CBC, and are endemic to IGE as well.
> The team behind Telegram, led by Nikolai Durov, consists of six ACM champions, half of them Ph.Ds in math. It took them about two years to roll out the current version of MTProto. Names and degrees may indeed not mean as much in some fields as they do in others, but this protocol is the result of thougtful and prolonged work of professionals.
I don't think their academic credentials or the amount of time they spent on this are the important metrics. If you're trying to suggest that they're thoughtful, the best metric for demonstrating that would be something like a proof for the (honestly naive-looking) KDF they made up.
In essence, the protocol seems to reflect many choices that anyone familiar with the field can immediately identify as suggesting a lack of understanding. It could be that these are simply brilliant moves that we non-ACM champions are too primitive to understand, but if that's true, you need to justify them with proofs in order to support them. Otherwise we're going to interpret them for how they appear.
> Thank you for the offer to join in the project you represent. However, we feel that what we are doing is going in a somewhat different direction and has its own potential.
Could you describe how your projects objectives are inconsistent with a protocol ratchet like Axolotol or the full TextSecure protocol?
Great crypto software avoids RSA. Good crypto software uses OAEP when RSA is used to encrypt. Crappy crypto software (see: DNSSEC) uses PKCS1v1.5. What are you using?
I didn't look carefully; I have probably missed something. Please explain how you are using RSA in the handshake/authentication for your protocol. Like Moxie said: it's not the underlying algorithms you use; it's the constructions you use to to them together, and to the data you're protecting.
Incidentally, "I refuse to respond to comments from people who have only looked at my system for a couple minutes" is not a habit of highly effective cryptographers.
Pray tell, why replay protection is done after decryption.
Is vkontakte [1] (russian social site) being somehow involved? I got confused by the illustrative images strongly resembling the vkontakte images.
Not to dive into Russian folk, but those look too culturally localized.
[1]: http://vk.com
Sexist.
In what areas of mathematics did these PhDs specialize? I hold a PhD in mathematics, but I would not feel comfortable rolling my own cryptographic algorithms for use in production (I'm a commutative algebraist by training).
Yes, because we all know that there are no women who can write code or analyze cryptographic algorithms. [rolls eyes]
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 the data, and passes that to importContacts() [1], which performs an RPC call to "the cloud", passing the contact list upstream and obtaining a server-processed list as a reply.
For me this is a major trust breach, and makes all the fuzzy claims about the app's security absolutely worthless.
[0] https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...
[1] https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...
Apart from identifying Telegram users among the user's friends, this also enables us to use proper names in notifications on the iPhone, as well as facilitates moving between devices.
But you have highlighted an important issue. Our android developer relied on the system prompts when it comes to uploading contacts, which is definitely not enough for the issue at hand. We will add another prompt in the coming version. (As well as update the GitHub code to the current generation soon, it's been becoming a little stale.)
This is not quite true. I never gave anyone (especially not the users of WhatsApp or Telegram) permission to upload my personal information to any cloud services. You can not actually imply that permission from all contacts merely by asking the user.
this also enables us to use proper names in notifications on the iPhone
I do not know enough about the iOS internals, but my naive assumption would be that after receiving a push notification, you can run code locally (like get the contact name from a local database), not merely get the notification displayed by the OS.
We will add another prompt in the coming version.
This is an improvement, but unfortunately does not tackle the first issue I mentioned, with implying consent from the actual contacts.
Ugh, this is such douchebag behavior for something that purports to be a "secure" app. Stop it immediately, please.
Also, there are approaches to make number registration lookups more secure, e.g. bloom filters: http://en.wikipedia.org/wiki/Bloom_filter
I would expect such an approach from a "secure" app.
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.
...running on Open Source hardware.
Many modern smartphones employ a baseband processor and an application processor with shared memory. While the app processor might be running an open-source compiled Android, the baseband processor is usually on a closed, not externally verified (and very buggy) RTOS provided by the manufacturer (Qualcomm, MediaTek, TI, ...)[0].
Owning the baseband is sufficient to gain access to the raw RAM of the application processor, to read any IM messages and keys, to manipulate data, code and whatever else you like. And all this is completely undetectable by any "antivirus" software running on the app processor.
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 TLS in Anonymous DH mode with an app-level authentication of the session handshake.
Designing your own crypto protocols is a very interesting challenge, but for practical purposes you just have to recycle existing designs. There's really no other way about it. A custom crypto doesn't make any difference for those who doesn't know/care about it, but it certainly will not make you any friends between those who does. Unless, of course, you can explain and prove why your design is better than those that exist already, and these guys don't do this.
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 possible to create something that is both secure and fast.
Disclaimer: Unfortunately, I'm not Nikolay. But I do work for Telegram.
Sorry, you have to do better than "TLS/HTTPS is slow". Anything over TCP is slow on congested and lossy networks. That's given, but that's hardly a reason to reinvent the whole crypto stack.
How is your protocol superior / faster / better than DTLS with session resuming? Is it faster than IKE in Quick Mode or IKE v2, which are both datagram protocols designed to work over lossy networks? What are the inherent problems with adopting DTLS or IKE to your purposes? This is dead easy to do without touching original crypto design and it instantly removes all questions pertaining to the quality of your crypto design. So why not?
I'm not a professional cryptographer, but I know applied crypto well and I've seen my share of custom crypto designs. Virtually ALL of them are is a result of thinking that it's better and easier to invent something new than to diligently learn what exists and understand how it works. It's fine for some areas, but it is decidedly not a way to go in the cryptography domain.
I'd like to see some papers/surveys/case studies on the matter. Yes, it's an "experiment", doesn't mean it's a good idea to roll out your own implementation before performing (and publishing) extensive tests.
Not saying you're doing something wrong, just that security-oriented people (usually who'd be interested in your product) may want to know more than just "yes guys it's secure, trust us".
http://core.telegram.org/mtproto/TL-dependent
look like a great parody to me? can't tell if they are serious with these 'dependent types'
> TL Language (Type Language or Time Limit)
So it is a partially applied acronym with a branch in it!
There is something seriously messed up in this project.
The important thing to remember is that all Telegram messages
are always securely encrypted. The difference between messages
in Secret Chats and ordinary Telegram messages is in the
encryption type: client-client in case of Secret Chats,
client-server/server-client for ordinary chats.
The real issue is that they could just make a lever that would still store "secret chats," unless if they're being delievered p2p.
No, you don't. Use a self-signed certificate that is hardcoded in the app.
Also, I think App Store software delivery doesn't depend on only TLS, but also on Apple's signature. And you can visually verify that the source code downloaded from GitHub doesn't contain backdoors.
Regarding real security, have a look at ChatSecure, which is available for iOS and Android, uses standard encryption protocols (XMPP with TLS, OTR), is open source, and was developed by the Guardian Project (who have a track record of developing security software):
https://itunes.apple.com/de/app/id464200063
https://play.google.com/store/apps/details?id=info.guardianp...
As for the false sense of security, you're probably right.
If you actually cared about security then you wouldn't be using iOS.
I've been following this space for a while and telegram is the best app out there right now. The usability is great and they are trying to do the right things when it comes to security.
The apps are open source and can be audited. I fully expect there to be bugs, that is part of the process! You would be insane to trust your life to a crypto app thats been around a few months. So yes, there will be bugs. But that doesn't mean they should just give up. In a few years this could turn into a really nice , secure app.
I think their big competition will be: Textsecure, also a great app and better for security due to OTR. But the iphone app is still in development as is their data channel. Once those are complete, they could take the #1 spot.
Also, hemlis is one to look out for. But they take about the same security approach as telegram but seem to be less open so far.
And that would be a better time to market it as "very secure"
For a "security" app, hell yeah you should be skeptical. Right now I think the most interesting and most trustworthy secure messaging projects are TextSecure v2 and Dark Mail (granted, that one isn't even out yet, their ideas so far sounded quite good).
Firefox gives me "The certificate is only valid for the following names: *.stel.com , stel.com" for https://telegram.org/
Yes, Threema provides forward secrecy on the network connection. Client and server negotiate temporary random keys, which are only stored in RAM and replaced every time the app restarts (and at least once every 7 days). An attacker who has captured the network traffic will not be able to decrypt it even if he finds out the long-term secret key of the client or the server after the fact.
Also if the private key is stored in the cloud then it's likely to be subject to requisitions.
As for server code — open sourcing the server code wouldn't really do much to improve trust. You would still have to trust us that we are using THAT code, not something different.
It would allow people to run your code (if they like it) on their own servers. Then they wouldn't need to trust you.
Great. Then...
> Telegram servers are spread worldwide for security and speed.
So this is what they mean by decentralized....
> As a result, Telegram is the fastest and most secure messaging system in the world
And this has exist for how many years?
I can probably say everything except private message, google hangout or Facebook chat is already doing it. They have some of the top-notch security, network and distributed system developers and they have their own cable delivering more volume than your new service can combine together. and if I want true privateness? I'd one-time pad everything. in reality, I guess PGP is good enough.
... and they are based in US of NSA - no thanks.
* 'delivers messages faster than any other application' - any application? Hmmm. They must be using magic.
* 'messages are heavily encrypted and can self-destruct' - but like every system, the self-destruction is not assured since it's impossible to enforce.
* 'keeps your messages safe from hacker attacks' - a bold claim. Maybe they do some stuff to protect messages, but it's not the perfect safety that this statement implies.
Anyway yep, these marketing stuff is a bit too dubious, but what should they write?
* is rather fast, faster than some applications
* can self-destruct, but sometimes can not (Ha!)
* etc
That's not the thing that happens in real world nowadays.
How about some benchmarks to support this claim?
>Telegram is supported by Pavel and Nikolai Durov.
I would not trust social network owner with my messages.
>Durov holds libertarian economic and political views and says he is a vegetarian and identifies as a Taoist. He published anarcho-capitalist manifestos describing his ideas on improving Russia. On his 27th birthday, he donated a million dollars to the Wikimedia Foundation.
Well, I think I'd rather trust them than Google or Facebook, after all, you've got to trust somebody.
Better the devil you know?
If you don't trust the backend in some particular way, nothing can help you to trust cloud storage. You should better take a look at end-to-end encrypted chats [1]. In theory they don't allow server to get access to any user data, except the fact of sending messages.
And interesting why you think that it's not possible to read most of cryptography/cryptanalysis books and check common mistakes of implementation afterward? Do you really think that this is THAT hard?
Your scepsis would be understandable if they used OWN cryptoalgorithm. However their protocol is based on well known strong crypto.
BTW, IGE cipher mode isn't well known for being strong.
There are a great many ways you can all gaps which mean a hacker can circumvent your security arrangements, and we are sceptical because we've seen it done wrong so many times before that it is healthier to take the pessimistic view (assume it is wrong and be pleasantly surprised if it isn't, rather than unpleasantly surprised if/when it turns out not to be).
I don't see it as negativity. People are bringing attention to the details that marketers typically omit (perhaps intentionally). If anything, these are positive discussions as we're sharing our own views and experience to give others more information to allow them to make more informed decisions. (i.e, whether the claims of security can be trusted in this case.)
If you want comments that are always happy and positive about every claim made by marketers, there's plenty of other places on the web for that.
Most people who try to make a whatsapp killer suck in uix. But this app is really good and fast. I think its better than whatsapp in a multitude of terms.
Okay, there are improvements. But I can submit a pull request to the android app and improve it myself! How Awesome!
The brothers do have some money, I suppose, from their company. However, I'm not sure if they are using the data gathered from this service, thus resulting in revenue somehow (maybe in their social network).
Personally, my expertise is rather in application security, so I will review some of the source code over the holidays. At first glance the C client is not bad.
The real metric of this project's success will be how they react to criticism, harsh as it may be. I hope they learn from their inevitable mistakes and succeed in the long term.
That such a policy even exists should suggest that "secure" is the wrong way to describe this. Reading through this, it looks like yet another attempt at what Lavabit and Hushmail were trying to do. In other words, snake oil.
Yeah, ok. Decided not to use it right there.
technical description here : http://core.telegram.org/mtproto/description
These suggestions, if implemented/fixed will surely get you some really dedicated early adopters!
Are they using something standard or do they want to lock-down users to their own proprietary servers ?
Messages stored on cloud! Big privacy problem.
Just tall marketing claims.