Yes, it DOES stop showing you as online. If you are not sharing your last seeen/online status with somebody, he will NOT see you online, regardless of the app they are using.
There is one exception to this: people will see you online for a brief period of time right after you send THEM a message (otherwise it would feel like talking to a wall).
One of the Telegram apps for Android did use Google Maps in http-mode. The issue was fixed within an hour, and the update is on its way to Play Market, containing several other security-related improvements.
At this moment we are working together with security experts on code review for our client applications. We awarded the person who discovered the bug and are designing a bug bounty program, which will be rolled out soon.
Good on you for being so quick to implement these bug fixes.
Others on HN have commented that the iteration process is probably not the best way to approach crypto, due to the high risk for the end user.
It seems obvious to me that nothing in this world is ever bug-free, and there is no such thing as foolproof where time is involved. You might as well accept this, and actually embrace it. It seems to me Telegram are embracing it very well.
Telegram is not robust at any point in time, but it is antifragile, since it benefits from shocks to become stronger over time. Like Hydra's heads, you can cut them off, but they will grow back twice as numerous. This is actually much better than robustness, it just doesn't look like it, because heads being cut off is more memorable and mediatic than heads growing back.
Of course, there is the argument that such high claims should not have been made on buggy software. But it is because such high claims were made, and because crypto people got annoyed about them, that everyone has been trying to break it, thus rendering it more foolproof.
It's annoying, but it's clearly working: at this rate of improvement, I'd be surprised if the product weren't pretty damn good in just a few months' time. If anyone has doubts over the current version, well, just don't use it in life-threatening situations until you're reasonably confident about it being fit for your purposes, which is an assessment that will also depend on the person or institution you're trying to avoid, and the quality of resources they have at their disposal.
Would you be happy with bridges, or elevators, using an iterative process for safety design?
How about training doctors? Don't build up through school (frogs and a sheep's lung) through universities (pigs, human corpses) and medical school (more corpses, watching surgery, assisting surgery) - just let them learn with open heart surgery?
> If anyone has doubts over the current version, well, just don't use it in life-threatening situations
That's good advice. How is Telegram advertising itself?
On the homepage:
> Telegram messages are heavily encrypted and can self-destruct.
> Telegram keeps your messages safe from hacker attacks.
In their FAQ:
> Telegram is the fastest and most secure messaging system in the world.
> Secret chats are meant for people who really want secure messaging.
etc.
This is nice wording, and I appreciate them saying this:
> Telegram is more secure than mass market messengers like WhatsApp and Line. We are based on the MTProto protocol (see description and advanced FAQ), built by our specialists, employing time-tested algorithms, to make security compatible with high speed delivery and reliability. We are continuously working with the community to improve the security of our protocol and clients.
It contains worrying bits ("built by our specialists"), but is mostly okay.
Your point about bridges and elevators actually illustrates my own point very well. Bridges and elevators may be quite safe today, but they weren't when people first started making them. Some bridges collapsed under various forms of pressure, and better bridges were designed as a result. They all necessarily made the claim to be safe until they were shown not to be.
So, yes, even bridges were built using the iterative process. It's just that the iterative process started long before you were born, and you found the world as it is without seeing the iterations that occurred before.
The same is true for doctors. There used to be all kinds of theories about how to cure the plague, or tuberculosis, or diseases we now know how to cure with a pill. Some of them worked, others didn't. Iteration at work, just over a longer timeline than your own lifetime.
This would make sense if cryptography was a young field, but this iteration and improvement has been going on for thousands of years (and modern digital cryptography has been developing for the better half of a century). It is known how to implement cryptography securely. Just as you would expect bridges built today to stay up, and doctors working today to be properly trained, you should expect cryptography implementations to be sensible and secure, or at least not try to carve a new, experimental path when people's lives are potentially at stake.
On the other hand, think about the benefits we get from seeing a bug in the software, and then seeing that Telegram have fixed it within the hour. Until a bug is shown and fixed, you don't even know whether it exists or not. So, you have doubt. But once it's exposed, and fixed, your attention is brought to an aspect of the software that you now know is good. The doubt is reduced. Which is a good thing.
That assumes that there are people with enough expertise and time to point out these flaws and the company actually listens to them. Something like an http/https grep is easy enough to do and doesn't require a lot of deep technical knowledge about how crypto works and should be designed, but someone doing an analysis of their entire algorithm and architecture for free and point it out to them? Forget about it. Especially since their "bounty" program has very specific parameters for what is acceptable to get any prize money.
So far, Telegram have been listening a lot to people pointing out errors, and fixed their errors promptly.
>for free and point it out to them? Forget about it.
It doesn't appear to be for free: aside from their bounty program, Telegram have been rewarding various troubleshooters with pretty decent ex gratia payments in bitcoin. In the article linked to this title, the first comment was from Telegram, asking the author to contact them for a reward.
They haven't been transparent about the amounts nor about the parameters of the initial bounty, which does not mean that the algorithm is safe, but rather that it wouldn't be worth the reward in effort to expose a vulnerability in the exact specified way by the authors.
That can apply to other apps and products, but much less so to crypto tools. It's basically one of the reasons why new crypto algorithms only start being used after 5 years of being in the wild, and many more in pre-release research.
You allow HTTP outgoing in your "secure" app? Of location information, that can lead to someone's safety or life to be put in danger if they really buy all your marketing? Why allow outside requests at all in the first place from your app? What if DNS is compromised and someone is tapping into google.com from a local tower/wifi DNS override and sending all Google Maps traffic to their server instead? Shouldn't you be using a proxied call to these outside services through your internal domain as API calls, with a way to verify that someone didn't hijack that connection and imitating it as well? This is all very much security 101 stuff and would have expected much better from an app labeling it as a simple, secure crypto solution.
How the F* is it possible that your app's reason of existence depends on proper security and you miss usage of HTTP where only HTTPS should be used? A vulnerability like that could be found with a proper grep on the source code. But even that seems to be too much effort.
It may be worth pointing that the Telegram FAQ claims there are two Android apps and they were both developed through a contest (I assume by third party developers).
The contest, as proposed by Pavel, while limited for the moment, does cover an important issue as far as our users are concerned. And the scope will naturally expand with time, should Telegram be invulnerable under the current conditions (see contest FAQ: http://core.telegram.org/contestfaq).
Quoting a post by Pavel here on HN: "Telegram will always be interested in creating incentives for the crypto-community to check its security and provide feedback. So if you are waiting for tools to try, e.g., a MITM on Telegram and get your $200К, please stay tuned. It's @telegram on Twitter."
(https://news.ycombinator.com/item?id=6938987)
As for general critique of the protocol, please allow us to add a few vital corrections regarding the article (unfortunately, the author chose a platform that would not permit a direct comment).
> They use the broken SHA1 hash function.
SHA-1 isn't exactly broken. There is a theoretical paper from 2005 that describes a way to narrow down collision search from 2^80 to approx. 2^69 operations (http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersio...) with subsquent improvement to 2^63, but collisions won't help in the case at hand. In order to break the implementation in MTProto you would require generating a text with chosen SHA-1 (to our knowledge, this problem was not yet solved) — and even that wouldn't get one far, because of the server salt, session id and time.
> Some really weird stuff about factoring 64-bit integers as part of the protocol.
This weird stuff can be pretty effective as part of our DoS-protection scheme.
Meanwhile, we've expanded our Tech FAQ with responses to most common questions concerning MTProto's robustness against certain types of active attacks:
I'm worried that to people unfamiliar with modern crypto, the diagram of your protocol and the "technical FAQ" might sound credible or even convincing. But it is not.
The message integrity protection this system describes is not up to modern standards. The system seems to use SHA1, which is a fault for a new system (no new system should use SHA1), but that's not the biggest problem; the biggest problem is that the SHA1 digest of a message is not an authenticator of that message, because an attacker can generate the same digest given only the contents of the message. Your FAQ makes a claim that is simply false when it says that the SHA1 of a message is a MAC. It simply is not. Moreover, the process of using a secure hash to generate a MAC isn't simple. HMAC-SHA1 and SHA1 are not comparable functions; HMAC-SHA1 goes through a series of elaborate steps to remediate vulnerabilities that come from trying to use SHA1 directly.
AES-IGE is an anachronism. Candidly: most of the Internet crypto practitioners who looked at this system learned about IGE for the first time because you decided to use it. IGE is a block cipher mode that was designed in 1977 and forgotten about in 1978. It's so archaic that academic cryptographers joke about how many times it has been reinvented and then rebroken. The last time your cryptosystem was discussed on HN, I provided a link to a thread in which Jutla laid out a simple, devastating attack on the mode in ASCII text in a mailing list post. You didn't respond.
Your use of RSA seems naive and ineffective. Your system "resists" MITM attacks by "allowing" clients to trust servers you operate. No other modern secure messaging protocol has this characteristic. Every OTR user in the world runs software that was designed not to trust central servers. Not only that, but the technical attributes of your RSA usage appear incompetent. RSA padding is not optional; Nate Lawson has argued for years that RSA "padding" should be renamed "armoring" for exactly this reason: because developers like those on your team assume that it is a minor detail. It is not. 80% of the RSA implementations on the Internet are insecure because they use the default padding (PCKS1v1.5) which was carefully designed (in the 90s) to resist attacks, but missed some. You use ad-hoc padding.
I don't understand why any professional in the world would spend any time on your contest. Moxie Marlinspike's response to that contest was devastating: he laid out a comically broken messaging protocol, one no professional would ever knowingly use, and showed that your contest rules would make that broken system survivable. Your contest appears to be a cynical attempt to prey on the misconceptions of uninformed users.
You have deliberately chosen the NSA as your adversary in your promotional content. You have deliberately chosen to give yourself no margin of error in designing this system. You've deliberately chosen a problem domain that requires profound trust in your team. You are not living up to the constraints you've set for yourself. I fear that the damage you've done to your project may be unrecoverable.
Okay, here's an authority I can get behind on this debate, not being familiar enough myself to parse most of the criticisms for their veracity. I don't always agree with your political or economic take on a subject, but I've never seen anything but excellence in your technical breakdowns of a subject, especially cryptography (go figure ;).
80% of the RSA implementations on the Internet are insecure because they use the default padding
So, now that I've hopefully buttered you up enough, I'm hoping you have a reference to share, because if that's true, it's pretty damn scary.
I hope Durov brothers are taking notes. Making a half-baked Facebook clone is not the same as making a fully-secured messaging system.
PS: These guys are still copying Facebook. Facebook released a messaging app, so these guys did the same. But, hey, Telegram is different because it uses MITM and it's "secure".
Glad you asked. I used to use Vkontakte (and Odnoklassniki btw) in the past. Vkontakte has always been in the catchup position with "missing" or "out-of-blue broken" features on a surprisingly consistent basis.
Now, I won't discuss these missing/broken features here. You can look them up on their app's comments section. But I will leave you with one very important thing about privacy:
VK shows when you were online the last time. VK also shows you online if you login without an ability to turn it off! Great for stalkers and unfortunate for those who wouldn't want to receive unwanted conversations.
So I am very reluctant to trust someone, who really doesn't get privacy to build a messaging system with security and privacy in mind. Because we clearly view privacy differently.
By that logic one could state that, for instance, Chrysler cars are "Ford clones" because Ford was the first manufacturer to become very popular and commercially successful.
> the biggest problem is that the SHA1 digest of a message is not an authenticator of that message, because an attacker can generate the same digest given only the contents of the message.
Curious, if the secret token comes after the message & there is proper delimiters to separate the message from the secret, where is the vulnerability?
> 1. The biggest problem is that the SHA1 digest of a message is not an authenticator of that message, because an attacker can generate the same digest given only the contents of the message.
Please note that a message to be encrypted would not only contain the actual text sent, but also at least the server salt, session id, message sequence number, message length and precise time.
This complete data set could be theoretically obtainable only from either server or client memory, therefore the fact that an attacker has this kind of data implies that a successful attack had already taken place. Hence the question — why didn't that attacker take the auth_key right away?
On top of that, the present setup doesn't present any identifiable threats, because even if you could get a message with a given SHA1, you would still not know which message was really transmitted out of the possible matching set (or rather out of the 2^(L-160) messages for a message with the length of L bits).
Regardless of this fact, we do agree that strengthening this point would be logical in view of possible future developments in code-breaking. Thank you.
> 2. The last time your cryptosystem was discussed on HN, I provided a link to a thread in which Jutla laid out a simple, devastating attack on the mode in ASCII text in a mailing list post. You didn't respond.
I'm afraid, this is not true. You must mean this comment [0], and we did respond, days ago.
Today I can only repeat that we do not use IGE as MAC. The attack described there [1] is irrelevant for our setup. A question for you, by the way: is your position that using CBC instead of IGE in our case would make the protocol more secure or less secure?
> 3. Technical attributes of your RSA usage appear incompetent. RSA padding is not optional; 80% of the RSA implementations on the Internet are insecure because they use the default padding (PCKS1v1.5) which was carefully designed (in the 90s) to resist attacks, but missed some. You use ad-hoc padding.
We thanked you for feedback on padding two days ago [2] and noted that we were in the process of strengthening this point by moving to OAEP.
Still, the random padding already in use in MTProto is rather robust. The reason for this is that the RSA in DH is only used one way and ONLY with the public key. An attack on the private key would not be possible in this case, since it is not being used for transmission. So the sole possible attack would be MITM, which would imply deciphering RSA in real-time. If you are aware of other attacks that could harm this design, please tell us.
For the moment getting the RSA key with a microphone in traditional setups that store private RSA keys on client devices looks like a more real threat than what is described above. In our case private RSA keys are neither stored, nor used on the client.
You can't simply use CBC without a MAC either. The generic composition of CBC with HMAC and randomized explicit IVs is strong assuming you've dealt with side channels.
But a modern cryptosystem wouldn't use CBC either; it would use a AEAD mode, like AES-GCM or AES-OCB. A very, very modern system would use a native stream cipher like Salsa20 and a polynomial MAC like UMAC or GMAC or Poly1305. No cryptosystem in the world would use IGE mode plus SHA1.
There is no way around the fact that SHA1 with a bunch of semisecrets is not a real MAC. I have absolutely no idea why you would argue this point, but the fact that you do argue it is extraordinarily damning. I have never seen a project anywhere make so many mistakes and then confront such simple, straightforward, observations as "SHA1 is by itself not a MAC" with fierce arguments. The normal way of wiggling out of this problem is to fix your protocol. But your team clings tenaciously to a broken design. Why? Why? Why would you do that? How would anybody ever trust a cryptosystem designed by a team that would do that?
But your team clings tenaciously to a broken design. Why?
Maybe we're seeing the beginning of the "I'm going to do exactly the opposite of whatever the NSA tells me to do" era. The NSA says to use a MAC, so I'm not going to use a MAC!
Hey, but now he knows that you are planning to do the opposite of what he says, presumably he will start giving you good advice, just to trick you.
The reason that people are so cynical about your custom solution is that being completely and utterly cynical about custom solutions, unless the architects can defend the solution rigorously, is the only sane approach in cryptography.
That, your fierce battle against everything unconventional and the fact that you get emotional instead of actually proving your point makes me think some "best practices" are indeed intentionally promoted in the crypto-community (https://news.ycombinator.com/item?id=6938622)
Disclaimer. I'm not an employee or shareholder in Telegram. I support them like I support some other non-profits like Wikimedia Foundation. As a reader here I would prefer to see an actual mathematical proof of how a certain system could be hacked instead of rhetoric like "No cryptosystem in the world would use...", "the fact that you do argue it is extraordinarily damning" or "Why? Why? Why would you do that?".
Because, with cryptography, the onus is on you to prove that your system is secure, not on other people to prove that it is broken. Everyone tells you there are many hints that your system is not secure, and you just go "well you can't prove it isn't, so there".
Do you truly need to ad-hominem attack tptacek? You sound pretty much like pseudoscientists when they blame mainstream science being too rigid and not accepting their groundbreaking theories.
Scientific approach is exactly what I'm calling for here. When a cryptographer resorts to arguments like "this algorithm won't work because it is not common/modern/accepted" without providing an exact way to break it, it doesn't sound like scientific approach to me. It's more like the religious mindset of someone who rigidly worships some limited list of tools (e.g. "NSA Suite B Cryptography") and punishes anyone who is independent enough to deviate from it.
In cryptography, the burden of proof is on the one proposing the system. It's up to the system designer to prove it secure. The reason why we stick to things like encrypt-then-HMAC, rather than rolling our own protocol, is that they HAVE been PROVEN secure. There are rigorous proofs [1,2] that HMAC and encrypt-then-HMAC are secure, assuming the underlying primitive is secure. There are no such proofs for Telegram's protocol, and there are many "smells" indicating attacks are possible, and I'm sure you'll see some actual examples soon.
Cryptography is HARD. It's so hard that it's hard to understand how hard it is. A large part of becoming a cryptographer is just learning how hard it is, and that you NEED security proofs, because it's just too easy to screw up.
I understand you're frustrated, but there's no need for the ad hominem attacks. tptacek is giving you good advice. We all want to see good crypto getting used. So why don't we work together to fix it instead of wasting our time defending a broken system? Honestly, replacing your protocol with encrypt-then-HMAC or the protocol from TextSecure isn't that big of a change, and it would make Telegram a lot better. So why not do it?
Pavel, folks here are being hard on you guys because historically, 9 out of 10 times "independent thinkers" who roll out their own crypto stacks get something wrong. That's why if you want to market your app to this crowd, you'll have a hard time selling something that is not what is a currently recommended crypto stack. Emphasizing that it is the NSA who recommends it is just a pasive-aggressive conspiracy theorizing. It may very well be the case that the NSA have ways of cracking their "Suite B", but we have no evidence of that, and if they do, do you really think that your ad-hoc solution would do much better against them?
So as I understand, you do agree that moxie's mock protocol ( http://thoughtcrime.org/blog/telegram-crypto-challenge/ ), which he designed to be as awful as possible, is as secure as Telegram's mtproto? There's no exact way to break it either, it's just as new, it doesn't use 'limited set of tools' too, both don't have any mathematical proofs. By your logic, I can't see how is it different to mtproto then? How do we know you don't have a protocol just like his?
I like this. "I'm calling for a scientific approach". Meaning, we throw out the last 20 years of scientific work on cryptography and start over from first principles, because the weight of the literature is inconvenient for your argument. It's an interesting tactic you've invented, and I'm surprised I haven't seen it in client change denial posts.
Well, when some of this "research" you promote ends up being backdoors planted by NSA (http://reut.rs/192XWwG), one has to be cautious.
Personally, I am more comfortable with 70s algorithms like Diffie-Hellman that have known and well-researched weaknesses. The "modern" algorithms actively promoted by US security firms after 9/11 are not time-tested, to say the least.
A large number of people who know what they are talking about have stated to you in the clearest terms possible that when it comes to cryptography and security systems, it is appropriate to place the burden of proof on the creators. It isn't an opinion, its a fact agreed on by every competent security practitioner on the planet. If you are going to continue to ignore this, no one is going to take anything you say about cryptography seriously.
Its not about dogma, its about safety. The fact that you fail to understand that is a testament to your inability to contribute to a meaningful conversation about security.
Right, but you still include the sha-1 of the plaintext in your outgoing message, which is (IIRC) generally considered bad practice because it leaks information about the plaintext.
No, that's incorrect. A hash function should have these properties:
* Given a hash h it should be hard to find a message m such that hash(m) = h
* Given a mesage m1 it should be hard to find m2 such that hash(m1) = hash(m2)
* It should be hard to find any two messages m1 and m2 such that hash(m1) = hash(m2)
If you have some secure hash function h, the function h'(m) that appends the low byte of m to h(m) is still secure under all three properties, but it obviously leaks information.
Although I am not a cryptographer, I understand the criticism you have received. Some feedback based on my very limited experience:
First, SHA-1 should be used with the HMAC construction. HMAC is very easy to implement, see RFC 2104. Your developers can do it in a day. You can also use Keccak instead, it does not require HMAC, and there is a version with 224-bit output.
Second, I don't see a problem with IGE. Despite others calling it "ancient," it was proposed at about the same time as CBC. There is a proof of security against adaptive chosen plaintext attacks. Nonetheless, you could use a more studied mode like CTR, but most importantly use the encrypt-then-MAC composition, i.e. AES-CTR + HMAC. (An authenticated mode would be best, but GCM is not easy to implement.)
Finally, the DHKE really must be authenticated. Everything else depends on it, since the key (auth_key) is not ephemeral. The least complicated way to authenticate is the Station-to-Station protocol.
"Secret Chats do not use mandatory authentication via a third-party or pre-shared information. We may later add an option to forbid Secret Chat initialization, unless the user has confirmed the key (using a QR code, NFC, etc.) for advanced users."
"Forward Secrecy is available for Secret Chats, but requires user action at the moment — it can be achieved by deleting secret chats and creating new ones, or logging out periodically (since logging out kills all secret chats)."
Unless I'm missing something, their recommended way of getting forward secrecy opens users up to man in the middle attacks, since if users are setting up new secret chats often enough to protect against an attacker obtaining their keys and decrypting past messages they're not going to be able to confirm the keys match every time.
I noticed some things that concern me, and while I neither have an active attack, or the time* to formalize one, I'll leave these concerns here for discussion, and take part when time permits.
First, the KDF really bugs me. Essentially, 128 bits of the data that's used to generate the AES key is derived from msg_key, which is the SHA-1 of plaintext+some_other_jazz. Also, only some of the auth_key's bits are used, along with the plaintext-dependent msg_key, as food for the KDF. What this could mean is that you're really diluting your effective keyspace. (Partially) deriving a key from the hash of public data doesn't smell like good crypto-hygiene, and intuition tells me there's the potential for leaking key bits if I query it enough, or collect a lot of ciphertext traffic.
Second, there's no integrity checking going on with the ciphertext, so I could easily ask the server to decrypt anything; don't give me that freedom, because maybe I can fool you into doing something worse. Also, if you were doing Encrypt-then-MAC, like any good boy should, you'd save yourself from wasting decryptions on bogus ciphertext. This is one reason I can't buy the performance-driven reasoning for using Methuselah's hand-me-down modes; modern modes are safer and likely faster. It's akin to paying more for used, squeaky parts, when you can pay less for new, more efficient parts.
To a cryptographer, the one thing we learn early in our careers is that it doesn't pay to be different when it comes to choosing primitives and protocols. When we find things that work, and have earned their bones, we recycle them in new designs and continue building upon the confidence we have in them by carrying on with cryptanalysis, building and breaking proofs, and so forth. There are no bonus points for those who deviate, because, really, the battle we're losing isn't that of the cryptography itself; rather, it's the way we implement it and the way we interface it. Implementation is the friend of no one; do not make it harder for yourself.
I've been a little candid, I know, but mostly because to many of us, what we're looking at is a Goldbergian gauntlet of decision-making that leaves us asking ourselves, "Okay, they took the long way home, but did they get there?" If there's a gain, I'm not seeing it, and the defense isn't leaving me optimistic that we will.
With all sincerity, and admiration for your desire to help others reap the benefits of cryptography, if enough of us tell you that there's a better, safer, and quicker way to getting this right, would you lend us an ear?
- Justin
P.S. I'm okay with being wrong, but I'm more concerned with helping you get things right.
Maybe because it appears to be an official response so is relevant, regardless of whether people think it's entirely correct. That can be a good reason to upvote, IMO.
IMO, because its either intentionally misleading or painfully uninformed, the fact that its info that came directly from the horse's mouth isn't a very good reason to up-vote.
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]
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.
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.
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 :)
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.
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.
There is one exception to this: people will see you online for a brief period of time right after you send THEM a message (otherwise it would feel like talking to a wall).
See: https://telegram.org/faq#q-can-i-hide-my-last-seen-time And: https://telegram.org/faq#q-who-can-see-me-online