The reason that cryptographers laugh at people who advertise "military grade cryptography" or "we use AES256" is because the choice of crypto primitives is often less important than how they're composed. Those phrases tend to reflect a critical misunderstanding of that, and often mean that a project is using secure primitives in a way that completely undermines their security.
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.
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).
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?
> 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.
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?
Long story short: you get integrity protection from IGE by relying on the fact that a bit error anywhere in the stream will irrevocably corrupt the rest of the stream, so you create an authentication code by sticking an all-zeroes block or (like I think Telegram does) a message digest to the end of the stream.
But it's possible with carefully chosen errors to first corrupt an IGE stream and then recover it, so that the remainder of the message after the corruption (including the "MAC" tag) will remain intact.
IGE is an extremely weird, and, at this point I'll venture: bad choice for a 2013-2014 cryptosystem.
There are certain data (session, message ID, session message, server salt) that are contained in the initial part of the unencrypted message; the message key must be the same as the 128 lower-order bits of the SHA1 of the message body (including session, message ID, etc.)
Disclaimer: I am not a cryptographer, and have only gotten to #40 in Matasano's challenges.
They appear to be trying to use encrypt and mac, and not as far as I can tell relying on IGE mode to provide authentication. See the "Message Key" and "Important Tests" sections here: https://core.telegram.org/mtproto/description
There is also not, as far as I can tell from reading the protocol description above and the source code here: https://github.com/ex3ndr/telegram-mt/blob/master/src/main/j... (in particular the EncryptedMessage method, lines 447 to 460) any sort of key in the MAC, it's just SHA-1 of the plaintext. It's also not encrypted as far as I can tell, it's listed in the unencrypted "external header" in the protocol description.
I can't think of an attack from this, but the fact that an adversary can generate a valid MAC for _any message_ by simply SHA-1'ing it seems really scary.
Kindly take at look at this technical FAQ that we've assebmled based on the conversations on Hacker News and elsewhere:
http://core.telegram.org/techfaq
Ah. In case anyone else was wondering why this works, it's because IGE has the property that if you corrupt the ciphertext, the plaintext is corrupted all the way from that point forwards. Therefore, appending the SHA1 of the message body is enough to check the integrity. (Appending a block of zeroes would be enough, too.)
How broken is it here? Who knows. Professional cryptographers would use an AEAD mode with a security proof, or the generic composition of a cipher (w/proof) with ciphertext encrypted by a MAC (w/proof). Instead, this system uses a '70s block mode (that nobody else uses) and a hash function from the '90s.
In order to clarify a few points in our setup, we've added this scheme to the protocol description page [0],[1].
We are indeed using well-known older algorithms, created in the days when bandwidth and processing power were both a much rarer commodity. This has valuable side-effects for modern-day mobile development, provided one takes care of the known drawbacks.
The weakspots of the said algorithms are also well-known, and have been exploited for decades. We used these algorithms in such a combination that, to our best knowledge, prevents any known attack from possibly succeeding. Although we’d be grateful to see any evidence of the contrary (so far absent from this thread) and update our system accordingly.
While other ways of achieving the same cryptographic goals, undoubtedly, exist, we feel that the present solution is both robust and also sucсeeds at our secondary task of beating unencrypted messengers in terms of delivery time and stability.
2. A passing look at the docs would reveal that we do not use IGE that way, and instead use SHA1 for integrity check (see 'message key' here: https://core.telegram.org/mtproto/description). The problems you mentioned as endemic to IGE used for integrity verification, are therefore irrelevant in this case.
As for KDF, going for slower provable algorithms used for each incoming\outgoing packet may be a preferred solution for projects aimed at the relatively small security crowd. But we don't really compete in this area, our competition is WhatsApp and other mass market messengers.
> 2. A passing look at the docs would reveal that we do not use IGE that way, and instead use SHA1 for integrity check (see 'message key' here: https://core.telegram.org/mtproto/description). The problems you mentioned as endemic to IGE used for integrity verification, are therefore irrelevant in this case.
The consensus seems to be that you're doing encrypt-and-mac, where the mac is just a sha1? If that's true, then you're relying on broken properties of IGE (not provably UF-CMA), and your protocol does not provide provable integrity. That's an essential part of any secure protocol.
> As for KDF, going for slower provable algorithms used for each incoming\outgoing packet may be a preferred solution for projects aimed at the relatively small security crowd. But we don't really compete in this area, our competition is WhatsApp and other mass market messengers.
That's interesting, because the thing you've made up is actually slower than a provably secure KDF.
Now, again, could I somehow direct your attention away from speculations and to what we are ACTUALLY doing (as, again, documented here [0], and now here as well [1]).
1. We are not doing plain encrypt-and-mac.
2. The SHA1 in question is for raw unencrypted data.
3. The message key is SHA1-dependent.
4. Note that the AES key and iv depends on that SHA1.
This can be described as a generic composition of cipher with ciphertext, encrypted by a MAC. The resulting data-dependant variable key denies all common attacks.
As for KDF, what particular solution do you have in mind? And even then — certainly, alternative solutions exist, but we do not see how changing this point would affect our system as whole. [1]
As stated before, we'd welcome any information on attacks that could in reality threaten the actual setup.
As for KDF, going for slower provable algorithms used for each incoming\outgoing packet may be a preferred solution for projects aimed at the relatively small security crowd. But we don't really compete in this area, our competition is WhatsApp and other mass market messengers.
What's this mean? You've created your own KDF, and the questions were: why is it secure, and why didn't you use an already-proven KDF? Unless I'm misreading something, it sounds like you've responded, "It's not that important, because our target market isn't people who care about their security." Is that correct?
EDIT: Judging by the upvotes, at least 5 other people are interested to hear your thoughts on this. Considering this submission is almost off the frontpage, that's a lot. As a security product, you should consider clarifying your position on this, because your statement currently sounds like, "We don't think security is a big deal since it's not a big deal to our target market."
No. What we mean is, as I've just noted in the reply to tptacek, that so far no attack was named that could harm the setup as described in our docs. And since this setup also delivers the performance that we require in terms of speed, we do not see why it would be necessary to change our approach to KDF.
> so far no attack was named that could harm the setup as described in our docs
Even as a complete newbie in cryptography I can see a problem in your reasoning. "Guilty until proven innocent" is the default when judging on a system. "No attack was named" because Telegram uses algorithms combination that was not proven with time. Nobody used them like this before. Why would anyone try to break it if it wasn't used?
As a potential user of Telegram I don't trust it enough to use it. It's more likely that someone with resources (e.g. government) could eventually break your system than it could break another - time-proven - system.
What's the message format you're using for RSA? I see RSA in the "pq" code of your Java client library; I see you asking Java for an "unpadded" instance of the RSA encryptor; I see you using RSA in its encrypting operation (not signing).
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.
This version of the client is using manual padding with random bytes. This isn't too bad, considering the SHA1 presence.
(See #4 here: https://core.telegram.org/mtproto/auth_key)
The server now supports OAEP, although this has yet to find its way into the docs and clients. We will update. Thank you!
This is a brand new application, right? Why is it built on '90s (or, worse, '70s) cryptography?
You need to publish the server-side source code for me to have any chance of making sense of this. I only see the client side of the connection in your source code, not the server response.
In terms of DoS possibilities, one doesn't need to replay old messages, they could just as easily send new ones or random garbage.
We could employ additional filtering techniques, but that increases processing time. And since modern hardware allows for very fast AES decryption, there is no particular gain in building additional layers of protection.
All that, naturally, implies that other anti-DoS measures are also being used.
Ah, that makes more sense then them not knowing what a replay is. Their writing is good enough that I didn't notice they weren't from an English speaking country.
"The team behind Telegram, led by Nikolai Durov, consists of six ACM champions, half of them Ph.Ds in math."
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).
"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?"
Yes, because we all know that there are no women who can write code or analyze cryptographic algorithms. [rolls eyes]
I have not run the app, but from the Android source code it looks like this "secure" app is uploading your contacts including full names and all their phone numbers into the "cloud":
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.
That is correct, Telegram does upload names and numbers — naturally, after receiving permission to do so. (see also: http://telegram.org/privacy)
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.
> 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.
Thank you, that was exactly my first thought.
In general, since we all are represented in other peoples' contact lists, it's worth considering what those other people are going to do with our data.
And it's not just the people you correspond with directly. I have a lot of people in my Thunderbird and email provider lists who I have no idea who they are, because someone in a chain of someones sent out a broadcast email with their address and my address.
Which means that if I were the sort of person to "upload my contacts!" I would have exposed people two or more hops away from me to whatever "service" I'd just submitted to.
Uploading your contacts may become the net equivalent of farting in public; it's rude.
They're actually correct about the notification use case - the server has to generate the message text that is displayed, and no application code can be run unless the user taps the notification and launches your app.
"I never gave anyone (especially not the users of WhatsApp or Telegram) permission to upload my personal information to any cloud services."
On Android you do by granting rights to access your contacts and give full network permissions. So you never know what a program will do with your contacts and a network connection.
But in the real world,your contacts never told you "feel free to upload my name and all my phone numbers wherever you want, so we can be linked by some cloud service to improve their click-through rates". An app that uploads your contacts is violating the privacy of your friends, even if it asks you about it.
I am not quite sure how the dimensioning of the bloom filter affects the false positive probability. Of course it is easy to iterate through many phone numbers, but at least you can not know for sure if a probed number is actually in the filter or just a false positive, giving means of plausible deniability.
I did not want to imply that there is a perfect zero-knowledge synchronization mechanism for your contact book.
Also, how can you claim to have a secure app when it runs on a closed-source operating system? (Even more, we know about Microsoft handing over security holes to the NSA - why would Apple or Google not do the same?).
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.
Only open-source apps on open-source operating systems [..]
...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.
>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.
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.
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.
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.
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 :)
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.
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?
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.
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.
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.
The reason for designing something new was this: in order for really secure messaging to catch on among the masses today — it needs not only be secure. When you want to compete with the likes of WA, you also need be fast and reliable on weak mobile connections.
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.
This is all great, but it reads like a marketing speak. There was this imperfect world full of idiots, slow, ugly and dim lit and then we came along and lifted the gloom.
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.
>MTProto was born as a result of an experiment: whether it would be possible to create something that is both secure and fast.
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".
You can drop the first two. And the third can have different motivations: I think here we just have a mathematician with sufficient time on their hands who enjoyed coming up with this. I think the primary valid complaint is: overly complex for its task.
it's not just overly complex, the use of 'dependent types' for this indicates that the author doesn't understand how they are really useful. neither he seems to know what serialization is, he apparently wants to serialize linked lists.
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.
Where "securely encrypted" means that the Telegram server has full access to message contents for ordinary chats. All chats should be "Secret Chats", not the other way around.
Came here to say this. I also don't understand why "secret chats" can't be kept in the cloud. Why can't they store encrypted messages and give them to me to decrypt when I want to?
I guess, that the problem is in encryption key exchange. Cloud chats are easy to synchronize between devices. Secret chats require unique encryption key for each chat.
> 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.
> 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
As an American I fear the NSA but at the same time to be fair, NSA is not the only intelligence doing this sort of work. Let's be fair, every other governments are doing similar things anyway, so maybe we should say no thanks to every other website.
* '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.
Have you tried the app? I've moved my top-5 chats from WhatsApp just because of speed! The messages are sent really fast. But if you know any other messenger apps for iOS, which are just about so fast, I'll definitely give them a try.
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.
People here are complaining a lot about this app, and rightfully so.
However, this is definitely the best encrypted communications app there is for ios and therefore also the only app that is cross platform and able to reach a wide audience.
I know they didn't do it completely right, but it definitely seems to be the best option that is currently available.
An "encrypted communications app" that is not using secure encryption is worse than an unencrypted one - the users get a fake feeling of security, and might reveal sensitive information to whoever is listening.
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):
but it is almost unusable on ios because it can not run in background
Unfortunately, the only way around that is to integrate with Apple's Push Service, which means you need to run a server-side component which notifies Apple (and which in turn notifies your app). This is not specified for XMPP, so most "XMPP clients" for iOS instead store your credential on the app developer's infrastructure. However, this problem is being worked on:
I am working on a protocol-agnostic, federated push messaging layer for ChatSecure-iOS but it will be interesting to see if anything else pops up in the meantime.
I've been using Threema for a while, it's available for both iOS and Android and while it isn't open source, you can verify the encryption used (they are using NaCl).
Is HTTPS not secure channel for communication between client-server? What is the reason behind using an entirely different protocol for client-server communication[0] over HTTP?
The main reason is speed. MTProto is designed to work fast on weak mobile connections.
Another reason is security, with HTTPs you need to trust more parties.
I also don't get this. If we stopped trusting HTTPS, how are we supposed to make sure that we get an unmodified app from the play store, or the original source code from GitHub in the first place? Am I missing something?
The fact that we have to trust TLS to deliver software doesn't automatically mean that we should trust it for secure messaging.
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.
My knowledge on cryptography is next to nothing. Would you mind explaining to me what makes the case for secure messaging different than any other transfer through a secured HTTP connection? I also read a bit on OTR Messaging and the "Socialist Millionaires' Protocol" but just got even more confused.
It's not that messaging can't use TLS, of course, it can. I'm objecting to the absolute (if we don't trust TLS for messaging, we shouldn't trust it one-time download), e.g. see https://en.wikipedia.org/wiki/Threat_model
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.
They are making a lot of bogus claims using marketing speak, and they are very low on details, while saying the app will be opensourced "eventually".
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).
>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.
The authors' education credentials are impressive, and I admire their initiative. However, they do not seem to have employed a cryptographer to review their design and protocols, so I expect that serious security problems will be discovered.
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.
Because intelligent, educated folk don't blindly accept the claims of others without scrutinizing them?
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.
Everybody is so negative here. Ok rolling your own security protocol might not be the best move. However, they want to be competetive with whatsapp.
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!
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.
What do you mean exactly? According to the FAQ, Threema offers perfect forward secrecy:
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.
If this is closed source (and the source seems to be only implementing API calls to a closed system) then it's fair to assume that this application is probably insecure or has backdoors.
Also if the private key is stored in the cloud then it's likely to be subject to requisitions.
Private keys for secret chats are only stored on the two participating devices.
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.
Depending on your definition of "decentralised", open sourcing the code would enable other people to set up servers that they can trust is running that code.
Looks like they kept the interface exactly the same as What's App to attract users. The smiley selection has the entire list of What's App smileys in exactly the same order. What's App is going to be upset, but it might help users.
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).
If this get popular and the people behind it can be trusted, this could replace sms and e-mail. The iOS, Android and CLI clients are open source, but I they need to open source the backend too. I also like the idea of giving the noun "telegram" a new meaning.
Replacing SMS I can see, since whatsApp/GroupMe/iMessages/whatsoever is already doing so, but replacing e-mail? Why would it replace e-mail in your opinion? I think IM/chats have a completely different purpose compared to e-mail, which unfortunately is often times used wrongly imho.
What is the point for server side open source? You can never trust that this code is launched on the instance which answers to your client' requests.
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.
Wow, there are so many cryptography experts with world names in this thread!
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.
There is a lot more to secure protocol design than just stringing together commonly accepted standards, unfortunately.
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).
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.