Telegram’s Cryptanalysis Contest(cryptofails.com)
cryptofails.com
Telegram’s Cryptanalysis Contest
http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest
137 comments
Unique Selling Point
Well create metadata resistant protocol that communicates on set intervals of time with set length of random data when there is no real payload. This could be done on TLS with little or no effort. The math behind the crypto is strong enough. No need to harden it further.
Every client sends and receives 16KB blob every 30 seconds - this way you could prevent analysis that you are communicating with someone. You could learn a lot just from the size and frequency of packets in a normal chat program.
Every client sends and receives 16KB blob every 30 seconds - this way you could prevent analysis that you are communicating with someone. You could learn a lot just from the size and frequency of packets in a normal chat program.
It seems like there is a 'No-Free-Lunch' tradeoff between bandwidth efficiency and traffic analysis resistance.
I prefer the later to the former in a heartbeat.
LOL.
We really need to make the world at large aware that a USP in the crypto area is a big red flag.
"We use up to date, standard protocols and crypto techniques" really ought to be the top of the marketing blurb. "Ours is better because we invented it" is really terrible.
We really need to make the world at large aware that a USP in the crypto area is a big red flag.
"We use up to date, standard protocols and crypto techniques" really ought to be the top of the marketing blurb. "Ours is better because we invented it" is really terrible.
WhatsApp already does everything that messenger should do - send text, images, video, files, location, group chats. The only thing that's not yet there is super-fast speed and security - and those are Telegram's priorities. They will get feedback from crypto community and update their protocols, they definitely have a potential to do it.
TextSecure is also using a protocol of its own design. I think the difference is largely the motivation at the other end. Moxie is genuinely engaged and interested in crypto and, much much more importantly, improving the trust models associated with it (see Convergence as another example). The Telegram guys seem more interested in being a 'hip' app with the latest secure IM solution. This doesn't even necessarily mean someone with far far less crypto knowledge than Moxie can't make a secure solution, it just means Telegram are suffering from a little arrogance and over-eagerness.
It's far too easy for people outside crypto circles to see cryptography as a panacea. Inside crypto circles however, it's my impression that everyone lives with a slight unease that much of the math they rely on has unproven lower bound complexity, the majority of implementations in existence are horrific, and the key management and trust models we all depend on are terrible and obscured from the users view and understanding. If you pay attention, all the rock star cryptographers spend most of their time talking about trust, not algorithms and protocols.
Designing a simple and secure crypto protocol isn't actually that hard. There are mathematical pitfalls us mortals can't hope to understand, but if you trust and understand the primitives as black boxes, and have the right mindset when analysing protocols, you can still build very secure systems. I'm a casual crypto hobbiest, and still spotted the issues raised in the Telegram protocol as soon as I looked at the diagram presented in the article. None of these weaknesses are outside of a good programmers comprehension.
So why is a custom protocol a bad idea? The same reason it's a bad idea to go and reimplement any other protocol... that problem has been solved, why are you remaking it without a strong incentive?
There are examples of crypto being used by amateurs with success though. Bitcoin has multiple extensions, like deterministic hierarchical wallets, which are easy to understand and reason about but I know for a fact weren't designed by world class crypto-experts. In that case, there was a strong incentive. Asynchronous key splitting to ensure safe generation of vanity addresses by 3rd parties is another example. Nobody should say these solutions aren't innovative and useful.
It's far too easy for people outside crypto circles to see cryptography as a panacea. Inside crypto circles however, it's my impression that everyone lives with a slight unease that much of the math they rely on has unproven lower bound complexity, the majority of implementations in existence are horrific, and the key management and trust models we all depend on are terrible and obscured from the users view and understanding. If you pay attention, all the rock star cryptographers spend most of their time talking about trust, not algorithms and protocols.
Designing a simple and secure crypto protocol isn't actually that hard. There are mathematical pitfalls us mortals can't hope to understand, but if you trust and understand the primitives as black boxes, and have the right mindset when analysing protocols, you can still build very secure systems. I'm a casual crypto hobbiest, and still spotted the issues raised in the Telegram protocol as soon as I looked at the diagram presented in the article. None of these weaknesses are outside of a good programmers comprehension.
So why is a custom protocol a bad idea? The same reason it's a bad idea to go and reimplement any other protocol... that problem has been solved, why are you remaking it without a strong incentive?
There are examples of crypto being used by amateurs with success though. Bitcoin has multiple extensions, like deterministic hierarchical wallets, which are easy to understand and reason about but I know for a fact weren't designed by world class crypto-experts. In that case, there was a strong incentive. Asynchronous key splitting to ensure safe generation of vanity addresses by 3rd parties is another example. Nobody should say these solutions aren't innovative and useful.
which are easy to understand and reason about but I know for a fact weren't designed by world class crypto-experts
I though Satoshi was anonymous? Do you know something the rest of us don't, or are you making assumptions on the code (and if so, how can you make those assumptions when you also state it was a success)?
I though Satoshi was anonymous? Do you know something the rest of us don't, or are you making assumptions on the code (and if so, how can you make those assumptions when you also state it was a success)?
>Bitcoin has multiple extensions, like deterministic hierarchical wallets, which are easy to understand and reason about but I know for a fact weren't designed by world class crypto-experts.
He clearly isn't talking about Satoshi when you look at the entire sentance
He clearly isn't talking about Satoshi when you look at the entire sentance
> Designing a protocol so that is does not leak is very hard.
In some of the security classes in school some of my teachers said it was better to use an open and trusted protocol than reinvent the wheel.
They cautioned against using a closed source or proprietary protocol because there was not way to "vet" the code. I trust industry vetted solutions over "hip" new solutions that arent open. I am not sure if Telegram is open or not.
In some of the security classes in school some of my teachers said it was better to use an open and trusted protocol than reinvent the wheel.
They cautioned against using a closed source or proprietary protocol because there was not way to "vet" the code. I trust industry vetted solutions over "hip" new solutions that arent open. I am not sure if Telegram is open or not.
With all the publicity TextSecure is getting from all this Telegram Debacle, I am beginning to suspect telegram isn't even a real company, and just a very elaborate publicity stunt by Moxie and the rest of the TextSecure team!! :P
By the comments it seems that most of the active haters of Telegram are TextSecure team. Yes, they want publicity and funding - and who doesn't?
"Haters" is a very emotive term. There is no real hate I can detect form the TextSecure team. They have just pointed out flaws and why they feel that the solution is flawed.
You wouldn't be associated with Telegram, by any chance?
You wouldn't be associated with Telegram, by any chance?
Alright, haters is probaby a too strong term. TextSecure team pointed out flaws in the first topic about Telegram on HN and these flaws were answered by Telegram team: they updated FAQ, they commented in twitter and here on HN. Every post with Telegram's flaws explicitly mentions TextSecure as an alternative, and that is suspicious - they seem to find it a great way to get publicity.
So are you associated with telegram, just to be clear?
Sorry I didn't respond to that. No, I'm not associated with Telegram in any way. And I'm not crypto professional :)
I totally understand what Telegram critics are saying, but in every article there's always a note "Please use TextSecure, don't use Telegram". By how it looks, it seems to be a way to market TextSecure and not to discover Telegram's security flaws. And critics rarely respond to Telegram team's comments where they say that the claims are wrong.
I totally understand what Telegram critics are saying, but in every article there's always a note "Please use TextSecure, don't use Telegram". By how it looks, it seems to be a way to market TextSecure and not to discover Telegram's security flaws. And critics rarely respond to Telegram team's comments where they say that the claims are wrong.
> but in every article there's always a note "Please use TextSecure, don't use Telegram".
This is very common in the security field.
Good crypto/security software is often not very straight-forward for the public to find. They're usually run by competent developers doing the work for free and don't tend to have big PR budgets or do a lot of advertising. The product is findable, but they can be overshadowed by snake-oil products that focus on the business aspects.
Whenever a security project or service is attacked as insecure, the natural question is "what do you use instead?", particularly if the functionality was niche or unique. It's just a part of the community that an alternative good one is recommended. We try to avoid saying "don't use X" and instead say "don't use X, but do use Y".
Yes, it helps Y piggie-back a bit off the popularity of X, but that's Y's fault being being bad enough to be disparaged. It isn't just the TextSecure team doing this, it's everyone who cares about this type of service.
This is very common in the security field.
Good crypto/security software is often not very straight-forward for the public to find. They're usually run by competent developers doing the work for free and don't tend to have big PR budgets or do a lot of advertising. The product is findable, but they can be overshadowed by snake-oil products that focus on the business aspects.
Whenever a security project or service is attacked as insecure, the natural question is "what do you use instead?", particularly if the functionality was niche or unique. It's just a part of the community that an alternative good one is recommended. We try to avoid saying "don't use X" and instead say "don't use X, but do use Y".
Yes, it helps Y piggie-back a bit off the popularity of X, but that's Y's fault being being bad enough to be disparaged. It isn't just the TextSecure team doing this, it's everyone who cares about this type of service.
>Yes, it helps Y piggie-back a bit off the popularity of X, but that's Y's fault being being bad enough to be disparaged.
Correction: Yes, it helps Y piggie-back a bit off the popularity (or notoriety) of X, but that's X's fault being being bad enough to be disparaged.
Correction: Yes, it helps Y piggie-back a bit off the popularity (or notoriety) of X, but that's X's fault being being bad enough to be disparaged.
TextSecure is in my (and that of crypto professionals who opinions I respect immensely) opinion the best secure messaging app on the market today -- and what they've achieved is a very difficult thing to do, as Telegram sort of shows. It's not about "hating" one or the other, this is maths and trust. TextSecure has proven maths and has spent a lot of time and effort (and open sourced their code) to build that trust and address all the issues these types of apps face.
When you're dealing with a market that can have literal life or death consequences, you go with something proven. That's why everyone touts it instead.
When you're dealing with a market that can have literal life or death consequences, you go with something proven. That's why everyone touts it instead.
#teamtelegram #teamtextsecure
Come on guys we can make this a thing...like the Twilight series.
Come on guys we can make this a thing...like the Twilight series.
I wish there was an article that succinctly conveys to potential users why Telegram is snakeoil and why TextSecure is the real deal.
Yep. So far it was more like "Please please don't use Telegram. Please please use TextSecure.".
So you didn't understand the article here then? There's no shame on that, crypto is complex and requires study.
But please don't dismiss well written and well thought-out critiques like this one just because you didn't understand the arguments.
But please don't dismiss well written and well thought-out critiques like this one just because you didn't understand the arguments.
Talking down to people helps nobody. If I were a random potential user and read what you wrote, my reaction would not be polite, and I would probably feel polarized against your recommendation out of spite.
The problem isn't that potential users are lacking anything. It's that nobody on our side of the table has communicated clearly and succinctly. https://news.ycombinator.com/item?id=6941007
The problem isn't that potential users are lacking anything. It's that nobody on our side of the table has communicated clearly and succinctly. https://news.ycombinator.com/item?id=6941007
I'm not talking down, it's clear that the commenter hadn't understood the article. And there really is no shame in that.
Further, your linked comment seems to be exactly what they're complaining about - Textmate good, Telegram bad. It doesn't explain why and why turns out to be quite hard to explain succinctly.
Further, your linked comment seems to be exactly what they're complaining about - Textmate good, Telegram bad. It doesn't explain why and why turns out to be quite hard to explain succinctly.
With all respect, crypto (and broken crypto) is wrt difficult to explain in a user friendly way to a lay person without just ignoring the technical details. Once you do that, it really is just "fuck telegram use snapchat", which doesn't help anyone... I am going to give it a bash tomorrow to try and write the article you are after. Good technical writing practice :)
What makes the Article here not sufficient from your perspective?
What makes the Article here not sufficient from your perspective?
Oh, wow, and people complain about Telegram team's attitude. Don't be so vulnerable, please. Take the critics easy.
As for the article, it's well written, but most of the points had been answered in Telegram FAQ or comments on HN. And yet they come up again and again. Not all, most.
As for the article, it's well written, but most of the points had been answered in Telegram FAQ or comments on HN. And yet they come up again and again. Not all, most.
>> Oh, wow, and people complain about Telegram team's attitude. Don't be so vulnerable, please. Take the critics easy.
I'm not sure what you mean by this as I'm not the author, so you haven't criticised anything I've said.
>> As for the article, it's well written, but most of the points had been answered in Telegram FAQ or comments on HN. And yet they come up again and again. Not all, most.
Not adequately, hence the well written deconstruction by the post author.
I'm going to echo what I've seen in another post - you appear to be a Telegram cheerleader with a brand new account, are you associated with them at all?
I'm not sure what you mean by this as I'm not the author, so you haven't criticised anything I've said.
>> As for the article, it's well written, but most of the points had been answered in Telegram FAQ or comments on HN. And yet they come up again and again. Not all, most.
Not adequately, hence the well written deconstruction by the post author.
I'm going to echo what I've seen in another post - you appear to be a Telegram cheerleader with a brand new account, are you associated with them at all?
> I'm going to echo what I've seen in another post - you appear to be a Telegram cheerleader with a brand new account, are you associated with them at all?
Discussions on HN about Telegram were mentioned on several Russian sites (e.g. [1]). No wonder that some persons decided to pitch in.
[1] http://www.siliconrus.com/2013/12/telegram-vs-hacker-news/ Approximate translation: "How experts on Hacker News laughed at Telegram."
Discussions on HN about Telegram were mentioned on several Russian sites (e.g. [1]). No wonder that some persons decided to pitch in.
[1] http://www.siliconrus.com/2013/12/telegram-vs-hacker-news/ Approximate translation: "How experts on Hacker News laughed at Telegram."
I think Telegram "cheerleaders" are here because Telegram backer Pavel Durov (paveldurov on HN) is very well known in Russia. He is the founder of one of most popular social networks in Russia, vk.com. He is a (local?) celebrity and he has fans. Imagine Mark Zuckerberg backing Telegram.
[deleted]
Yesterday's article A Crypto Challenge For The Telegram Developers was a good analysis on why Telegram's challenge fails to prove anything.
Sadly, it was probably too technical for most potential users to be swayed much by it.
We need focused talking points, e.g. the fact that the NSA and other governments vacuum up all your data, and that TextSecure represents the first step toward a future in which it's very difficult for governments to do that. Whereas with Telegram, it's just as easy for them to access your conversations as it is for them to bypass SSL. Governments can and will do so. That's what users are concerned about; that's what they care about. Telegram has no defense against that argument due to their protocol's inherent vulnerability to this form of attack. Therefore it's the single most important point for to stress to any potential user.
Yet it's getting lost in the noise. Actually, I haven't seen it mentioned very much at all. Someone should do a writeup calling attention to it.
We need focused talking points, e.g. the fact that the NSA and other governments vacuum up all your data, and that TextSecure represents the first step toward a future in which it's very difficult for governments to do that. Whereas with Telegram, it's just as easy for them to access your conversations as it is for them to bypass SSL. Governments can and will do so. That's what users are concerned about; that's what they care about. Telegram has no defense against that argument due to their protocol's inherent vulnerability to this form of attack. Therefore it's the single most important point for to stress to any potential user.
Yet it's getting lost in the noise. Actually, I haven't seen it mentioned very much at all. Someone should do a writeup calling attention to it.
Simpler explanation:
I am selling fire-proof safes. These are designed to protect your documents and valuables from thieves and from fire and other events.
The normal way people set up tests is to put some documents and valuables in a box and actually try to break it (MythBusters style, bringing out cool machinery and trying different ways). For fire resistance, there is a rating system (https://en.wikipedia.org/wiki/Fire-resistance_rating) and a standard way to test.
The Telegram proposition is: we are going to place the safe in Fort Knox. If you can't break the safe that is in Fort Knox, then clearly our safe is secure.
The Article rebuttal: to break the safe, you have to break into Fort Knox. And for all intents and purposes that's not going to happen. You could have put a cardboard box and no one could tell the difference because of how you structured the test.
I am selling fire-proof safes. These are designed to protect your documents and valuables from thieves and from fire and other events.
The normal way people set up tests is to put some documents and valuables in a box and actually try to break it (MythBusters style, bringing out cool machinery and trying different ways). For fire resistance, there is a rating system (https://en.wikipedia.org/wiki/Fire-resistance_rating) and a standard way to test.
The Telegram proposition is: we are going to place the safe in Fort Knox. If you can't break the safe that is in Fort Knox, then clearly our safe is secure.
The Article rebuttal: to break the safe, you have to break into Fort Knox. And for all intents and purposes that's not going to happen. You could have put a cardboard box and no one could tell the difference because of how you structured the test.
We need focused talking points
No we don't. At least not for your goal of:
an article that succinctly conveys to potential users why Telegram is snakeoil and why TextSecure is the real deal
There is no way to convey this with better rhetoric because the proof is in the technical detail, the party that is wrong can just ramp theirs rhetoric up too. If you don't dig into that detail, it just becomes a he said/she said argument that no observers can judge on merit. Those discussion relies on the participants to be knowledgeable, and politely acknowledge when they're out of their depth technically or just plain wrong. But there is nothing to enforce that, see any Hacker News discussion about something that isn't web development or devops.
No we don't. At least not for your goal of:
an article that succinctly conveys to potential users why Telegram is snakeoil and why TextSecure is the real deal
There is no way to convey this with better rhetoric because the proof is in the technical detail, the party that is wrong can just ramp theirs rhetoric up too. If you don't dig into that detail, it just becomes a he said/she said argument that no observers can judge on merit. Those discussion relies on the participants to be knowledgeable, and politely acknowledge when they're out of their depth technically or just plain wrong. But there is nothing to enforce that, see any Hacker News discussion about something that isn't web development or devops.
Here, this is even simpler:
[email protected]
I used a simple substitution cipher. Please indicate, without guessing every combination, which one is correct. For convenience, the letters z,c,o,m are not substituted.
[email protected]
I used a simple substitution cipher. Please indicate, without guessing every combination, which one is correct. For convenience, the letters z,c,o,m are not substituted.
[deleted]
[deleted]
That would be nice. But, for what it's worth: don't use Telegram. It's a mess. TextSecure was built much, much more carefully.
Is TextSecure only for SMS messages, or does it use the internet? I'm asking because of the need to send text messages abroad (at a reasonable price). Also, is there a desktop client for TextSecure? I would love something like WhatsApp -- but secure and with a desktop client.
XMPP + OTR will do what you want. I asked moxie the same question re the internet vs text, but he hasn't replied yet. As far as I'm aware it uses text for insecure stuff, and I think for initial key exchange to start the ratchet then uses the internet for secure messaging. Its quite user friendly. No desktop client, and the messages are of ephemeral so keep that in mind and see whether that's okay for your use case (it is for mine).
Depending on how much you're willing to pay, Silent Circle might fit the bill: https://silentcircle.com/
Disclaimer: I work for them.
Disclaimer: I work for them.
Forgetting the discussion of the merits or otherwise of Telegram - I just wanted to say that that is a very written article. A clear argument built on clear explanations of the various models.
I think it's a brilliant move from the people behind Telegram: all cryptographers will now keep the vulnerabilities they find to themselves until March 1st. This saves them from a lot of bad press now, and probably doesn't cost them anything.
If they were serious about using their $200k for their security they should have either: a) Hired an actual independent cryptographer to do an audit. b) Set up a bug bounty program that rewards any weakness found, not just this "all-or-nothing" contest they have now.
If they were serious about using their $200k for their security they should have either: a) Hired an actual independent cryptographer to do an audit. b) Set up a bug bounty program that rewards any weakness found, not just this "all-or-nothing" contest they have now.
Best quote: "Telegram’s design seems to disregard all of the important crypto research from the past two decades."
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.
More on our SHA-1 implementation here: http://core.telegram.org/techfaq#q-are-you-doing-encrypt-the...
and here: http://core.telegram.org/techfaq#q-why-do-you-use-sha-1-in-t...
> they are trying to do “Mac and Encrypt” which is not secure.
We are not doing this. We are doing this: http://core.telegram.org/techfaq#q-are-you-doing-encrypt-the...
> They rely on an obscure cipher mode called “Infinite Garble Extension.”
Yes, we do. The setup goes like this: http://core.telegram.org/techfaq#q-do-you-use-ige-ige-is-bro...
> 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:
http://core.telegram.org/techfaq#protection-against-known-at...
Thank you for your comments,
Telegram Team
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.
More on our SHA-1 implementation here: http://core.telegram.org/techfaq#q-are-you-doing-encrypt-the...
and here: http://core.telegram.org/techfaq#q-why-do-you-use-sha-1-in-t...
> they are trying to do “Mac and Encrypt” which is not secure.
We are not doing this. We are doing this: http://core.telegram.org/techfaq#q-are-you-doing-encrypt-the...
> They rely on an obscure cipher mode called “Infinite Garble Extension.”
Yes, we do. The setup goes like this: http://core.telegram.org/techfaq#q-do-you-use-ige-ige-is-bro...
> 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:
http://core.telegram.org/techfaq#protection-against-known-at...
Thank you for your comments,
Telegram Team
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.
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.
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".
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".
"200% secure".
> half-baked Facebook clone
It is better than Facebook in every possible way.
Have you actually ever used VK (both the site and the mobile apps)?
It is better than Facebook in every possible way.
Have you actually ever used VK (both the site and the mobile apps)?
> It is better than Facebook in every possible way.
Even if it were true, your statement still doesn't contradict GP's assertion.
Even if it were true, your statement still doesn't contradict GP's assertion.
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.
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.
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.
> 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?
Take a look at this link: https://blog.jcoglan.com/2012/06/09/why-you-should-never-use...
Am I correct to think that the example cited is bad? It appears that it would be a strong MAC because of the reasons that I cited.
Curious, if the secret token comes after the message & there is proper delimiters to separate the message from the secret, where is the vulnerability?
Take a look at this link: https://blog.jcoglan.com/2012/06/09/why-you-should-never-use...
Am I correct to think that the example cited is bad? It appears that it would be a strong MAC because of the reasons that I cited.
> 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?
[0] https://news.ycombinator.com/item?id=6918015
[1] https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UG...
> 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.
[2] https://news.ycombinator.com/item?id=6918634
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?
[0] https://news.ycombinator.com/item?id=6918015
[1] https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UG...
> 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.
[2] https://news.ycombinator.com/item?id=6918634
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 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!
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!
If the advice comes from tptacek, you should probably do the opposite. He insisted this was NOT a backdoor:
https://news.ycombinator.com/item?id=6944118
https://news.ycombinator.com/item?id=6944118
No, that's not at all what I said, but I despair of explaining the distinctions to someone who thinks AES-IGE+SHA1 and unpadded RSA is a sound design.
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.
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.
Pavel, showing that he was wrong once in the past doesn't invalidate his multiple points he made now (or in the past).
> But a modern cryptosystem ... would use a AEAD mode, like AES-GCM
But really, it is funny how rigidly you stick to NSA Suite B Cryptography http://en.wikipedia.org/wiki/NSA_Suite_B_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?".
But really, it is funny how rigidly you stick to NSA Suite B Cryptography http://en.wikipedia.org/wiki/NSA_Suite_B_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.
[1] https://eprint.iacr.org/2006/043.pdf [2] http://cseweb.ucsd.edu/~mihir/papers/oem.pdf
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?
[1] https://eprint.iacr.org/2006/043.pdf [2] http://cseweb.ucsd.edu/~mihir/papers/oem.pdf
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.
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.
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.
I'm sorry but I have to ask:
Can you prove that you indeed are Pavel Durov of VK?
Can you prove that you indeed are Pavel Durov of VK?
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.
*I have a toddler.
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.
*I have a toddler.
>> > they are trying to do “Mac and Encrypt” which is not secure.
>> We are not doing this. We are doing this: http://core.telegram.org/techfaq#q-are-you-doing-encrypt-the....
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.
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.
The idea of cryptographic hashes is that they don't leak information about the plaintext, though.
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.
* 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.
Hmm, I unfortunately can't remember the hash attack models right now, but you may be right. I think there are models under which this fails, though.
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.
Best of luck.
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.
Best of luck.
>> HMAC is very easy to implement, see RFC 2104. Your developers can do it in a day.
I can vouch for this, having just written an (embedded) HMAC implementation in half a day :)
I can vouch for this, having just written an (embedded) HMAC implementation in half a day :)
Lets assume, just for the sake of argument, that your encryption system and trust model are fine. Good. Great even.
So, you have a great system and cryptographers are giving you free advice on how to make it even better, why aren't you taking it? Are they wrong?
So, you have a great system and cryptographers are giving you free advice on how to make it even better, why aren't you taking it? Are they wrong?
[deleted]
That FAQ is hilarious:
"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.
"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.
Thanks for responding re: the crypto. But one question begs to be asked -
Why isn't end-to-end encryption enabled by default? Why is not having end-to-end encryption an option at all?
Why isn't end-to-end encryption enabled by default? Why is not having end-to-end encryption an option at all?
Also, What did he mean by public keys are not authenticated?
did he pay to be the top voted comment, or are the HN readers really that stupid and voted him up?
(Did he really just argue that sha1 isn't broken? ohmy)
(Did he really just argue that sha1 isn't broken? ohmy)
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.
Don't high voted answers push up a post?
> They use the broken SHA1 hash function
They answer this point on the website: "Q: Why do you use SHA-1 in the place of a MAC? [...] since this means still requiring at least 2^128 operations (instead of 2^256 with, say, SHA-2) to even begin trying to break this scheme, the trade-off seems fair."
Why not break the crypto (and take the money) if it's so amateurish?
They answer this point on the website: "Q: Why do you use SHA-1 in the place of a MAC? [...] since this means still requiring at least 2^128 operations (instead of 2^256 with, say, SHA-2) to even begin trying to break this scheme, the trade-off seems fair."
Why not break the crypto (and take the money) if it's so amateurish?
The easiest to understand response to this question that I've seen so far is from this comment [0]:
The contest limitations rule out most of the likely attack vectors for breaking the protocol in the real world. It's like saying "Our bank vans are 100% secure. Just try stealing money from them without puncturing our tires or bribing one of our employees."
[0] - https://news.ycombinator.com/item?id=6936949
The contest limitations rule out most of the likely attack vectors for breaking the protocol in the real world. It's like saying "Our bank vans are 100% secure. Just try stealing money from them without puncturing our tires or bribing one of our employees."
[0] - https://news.ycombinator.com/item?id=6936949
In particular none of the attacks described in TFA (Known Plaintext, Chosen Plaintext and Chosen Ciphertext) are possible within the frame of their contest (since Telegram controls all inputs).
Yesterday someone blogged an example of a completely broken cryptosystem that would still pass Telegram's challenge with the same limitations: http://www.thoughtcrime.org/blog/telegram-crypto-challenge/
Yesterday someone blogged an example of a completely broken cryptosystem that would still pass Telegram's challenge with the same limitations: http://www.thoughtcrime.org/blog/telegram-crypto-challenge/
It may even be possible to factor the RSA Key
More to the point, KPA,CPA, etc are very important, and systems should be definitely tested against them, but in real attacks, they may not be available
More to the point, KPA,CPA, etc are very important, and systems should be definitely tested against them, but in real attacks, they may not be available
[deleted]
If the crypto is broken, then break the crypto and collect the 200k.
Or if its vulnerable to a MITM, then explain how.
Or if its vulnerable to chosen plaintext/ciphertext or known plaintest, explain how.
There has been so much piling on of telegram, but nobody has actually proven any problems with their code or protocol. Meanwhile telegram is trying to do the right thing by being open source and taking the time to respond here and elsewhere to misconceptions and criticisms about them.
I really don't get the hostility towards them so far.
Or if its vulnerable to a MITM, then explain how.
Or if its vulnerable to chosen plaintext/ciphertext or known plaintest, explain how.
There has been so much piling on of telegram, but nobody has actually proven any problems with their code or protocol. Meanwhile telegram is trying to do the right thing by being open source and taking the time to respond here and elsewhere to misconceptions and criticisms about them.
I really don't get the hostility towards them so far.
Well, the severe issues highlighted by better cryptographers than me (although I do understand why and how they are issues) show that the protocol can't be trusted. These issues have caused other protocols to be broken, so aeeinf similar issues again from the get go, coupled with heir marketing spiel means that it shouldn't be trusted.
Which is what it's about: cryptography is mostly about trust with a bit of math thrown in. If you can't trust that it won't be broken (see: all the issues 'moxie and 'tptaeck bring up for an example) then it shouldn't be used.
Which is what it's about: cryptography is mostly about trust with a bit of math thrown in. If you can't trust that it won't be broken (see: all the issues 'moxie and 'tptaeck bring up for an example) then it shouldn't be used.
People have pointed out their weaknesses. Telegram provides non-responses.
The crypto has problems, but they aren't exploitable under the very limited conditions set by their contest.
The crypto has problems, but they aren't exploitable under the very limited conditions set by their contest.
The contest is framed in such a way that the protocol's weaknesses aren't exposed to attack in the way that they would be in the wild.
Not necessarily on topic, but...
"... will give $200,000 in BTC to the first person ..."
Is that $200,000 in BTC at the time the contest was announced, or at the time the winner is announced? Or at some other point?
(This comment brought to you by the Committee For Pointing Out That A Currency That Wildly Fluctuates In Value Is Not Particularly Useful (CFPOTACTWFIVINPU).)
"... will give $200,000 in BTC to the first person ..."
Is that $200,000 in BTC at the time the contest was announced, or at the time the winner is announced? Or at some other point?
(This comment brought to you by the Committee For Pointing Out That A Currency That Wildly Fluctuates In Value Is Not Particularly Useful (CFPOTACTWFIVINPU).)
Ugh. There are a lot of reasons not to participate in this contest, but that's not one of them. The FAQ explicitly says that they'll just give you USD if you'd like, so it doesn't really matter when they pin the USD/Bitcoin exchange rate.
Has anyone else noticed that their protocol sounds a lot like "empty proto"... http://core.telegram.org/mtproto
[thinks of null key encryption]
[thinks of null key encryption]
Good idea, lets keep attacking the marketing team. It's a PR stunt, can we stop acting like it's anything else?
So everyone is mad cause they used their own approach to security. Now no one managed to break their crypto so far. Don't say it is bad unless you can break it. Don't go around write a full paper about how bad it is while you still can't break it.
I still don't get why there is all this hostility toward telegram.
I still don't get why there is all this hostility toward telegram.
>So everyone is mad cause they used their own approach to security
No, that's not why people are upset at all.
People are upset because whether or not someone has been able to break their system under the constraints of the contest means almost nothing.
Did you even read the article?
No, that's not why people are upset at all.
People are upset because whether or not someone has been able to break their system under the constraints of the contest means almost nothing.
Did you even read the article?
Wow...this thing just keeps on giving. It's Christmas in crypto-fail land!
I think people should keep quiet if they cant break their system. What good is a cryptographer, if its only good for pointing fingers?
I don't understand why this is such a massive problem (front page news for days now, really?). Mind you, I am not a crypto expert, but enough with the bitching already.
Crypto experts, just crack it then.. who cares about the special conditions in the contest which make it so difficult. Just do it, prove your point and carry on.
$200k is PR, everyone knows that already.
Crypto experts, just crack it then.. who cares about the special conditions in the contest which make it so difficult. Just do it, prove your point and carry on.
$200k is PR, everyone knows that already.
[deleted]
It may well be impossible to crack within the terms of the contest.
This does not make it secure in the slightest, as the terms are set up specifically to exclude most of the attacks that are used in crypto validation these days. See - http://www.thoughtcrime.org/blog/telegram-crypto-challenge/
This does not make it secure in the slightest, as the terms are set up specifically to exclude most of the attacks that are used in crypto validation these days. See - http://www.thoughtcrime.org/blog/telegram-crypto-challenge/
Some strong claims in there for not really proving that the protocol is indeed "terrible".
An expert on trees:
This oak is probably diseased. It has discolorations on
some of the leaves and the bark is much looser than
normal. I think it should be thoroughly investigated or
perhaps just cut it down to be safe.
And you obviously know that i know nothing of on the subject?
From your comment everyone can immediately surmise that you lack the practical knowledge of using cryptography for real world applications that people like tptacek and moxie have.
They are known experts and have been quite clear on the questionable nature of Telegram's choice of cryptographic primitives and their composition. Their objection is not 'this is obviously broken'. Their objection is 'this does not obviously work and there are some red flags'. This blog post merely mirrors that objection.
The crucial point is that the past has shown that no proof of brokenness is required. In cryptography, if it doesn't obviously work, it is probably broken, because it is incredibly hard to get right and because an incredible amount of money and effort is available to find the tiniest crack. You are dealing with criminals and governments who have deep pockets. Either you prove it works or you assume it doesn't work. The proof is missing.
They are known experts and have been quite clear on the questionable nature of Telegram's choice of cryptographic primitives and their composition. Their objection is not 'this is obviously broken'. Their objection is 'this does not obviously work and there are some red flags'. This blog post merely mirrors that objection.
The crucial point is that the past has shown that no proof of brokenness is required. In cryptography, if it doesn't obviously work, it is probably broken, because it is incredibly hard to get right and because an incredible amount of money and effort is available to find the tiniest crack. You are dealing with criminals and governments who have deep pockets. Either you prove it works or you assume it doesn't work. The proof is missing.
With respect, at first glance it seems that way. The burden of proof lies with the claim to security, not the claim of insecurity.
The contest actually puts the burden of proof on the "claim of insecurity" side.
The contest is a stunt that appears to a casual observer to shift the burden of proof because they wrote a long winded "PROVE ME WRONG BRO."
I think that most people realized this upon reading your other comment.
You are either entirely unfamiliar with cryptography or you misunderstand a great deal of what you think you do know.
You are either entirely unfamiliar with cryptography or you misunderstand a great deal of what you think you do know.
Funny how they say "oh but the attack possibilities are limited" then proceed to mention all the weaknesses in the algorithm.
Well, if the algorithm is so broken then it should be trivial to break it even with their limitations.
Isn't that what they say? "Oh SHA-1 is broken", great, show it.
Of course, the capability to do that may be worth more than getting the $200k from the contest
Well, if the algorithm is so broken then it should be trivial to break it even with their limitations.
Isn't that what they say? "Oh SHA-1 is broken", great, show it.
Of course, the capability to do that may be worth more than getting the $200k from the contest
Well, if the algorithm is so broken then it should be
trivial to break it even with their limitations.
[1] Limitations include: not being allowed within 200m of the house.
I disagree
You are allowed access to the encrypted data.
In a real attack you may, depending on the circumstances, only have access to that (at first, at least).
Probably more like "you aren't allowed to destroy any locks or doors to enter the house". Hard, but much different than staying 200m from the house.
You are allowed access to the encrypted data.
In a real attack you may, depending on the circumstances, only have access to that (at first, at least).
Probably more like "you aren't allowed to destroy any locks or doors to enter the house". Hard, but much different than staying 200m from the house.
> In a real attack you may, depending on the circumstances, only have access to that (at first, at least).
You misunderstand the whole deal.
When imagining different potential attacks on your house you can't go laying down rules that the burglars have to follow. What if there are special circumstances (that you weren't aware of) that allows the burglars to bypass your restrictions under certain conditions? You plan for the worst case scenario, always!
Take password hashing+salting for instance. You could say that it's actually safe to store plaintext passwords because outsiders don't have credentials to access the database.
You could even run a contest where to say that you will give a million dollars to anybody who can get access and steal the passwords, and then insist that since nobody has claimed that million dollars yet, plaintext passwords are clearly safe.
But we all see how foolish that would be. You plan for the worst case scenario and hash+salt your passwords. You don't plan for the "average case scenario" where "normally attackers don't have access to the database".
You misunderstand the whole deal.
When imagining different potential attacks on your house you can't go laying down rules that the burglars have to follow. What if there are special circumstances (that you weren't aware of) that allows the burglars to bypass your restrictions under certain conditions? You plan for the worst case scenario, always!
Take password hashing+salting for instance. You could say that it's actually safe to store plaintext passwords because outsiders don't have credentials to access the database.
You could even run a contest where to say that you will give a million dollars to anybody who can get access and steal the passwords, and then insist that since nobody has claimed that million dollars yet, plaintext passwords are clearly safe.
But we all see how foolish that would be. You plan for the worst case scenario and hash+salt your passwords. You don't plan for the "average case scenario" where "normally attackers don't have access to the database".
"When imagining different potential attacks on your house you can't go laying down rules that the burglars have to follow"
Of course. But everything is limited and for each scenario there's a specific chance that will happen. Some RSA key sizes are breakable if you can put a lot of computing power behind.
For example, a house may not be built to withstand tanks, so there's your limitation.
On the other hand, there's a huge likelihood someone will walk past your house and see the door ajar, or try to open it.
So, again, everybody is right to secure against KPA, CPA, etc, BUT don't forget that there may be something easier, and yes, if it resists the deeper attacks it's probably safe against capture of cyphertext.
"But we all see how foolish that would be. You plan for the worst case scenario and hash+salt your passwords"
Sure. But in practice the plaintext + strong DB security may be safer "overall" than a hash + salt on a MySQL with the credentials forgotten in some config.php somewhere.
(It's not an excuse to not hash the passwords, though)
Of course. But everything is limited and for each scenario there's a specific chance that will happen. Some RSA key sizes are breakable if you can put a lot of computing power behind.
For example, a house may not be built to withstand tanks, so there's your limitation.
On the other hand, there's a huge likelihood someone will walk past your house and see the door ajar, or try to open it.
So, again, everybody is right to secure against KPA, CPA, etc, BUT don't forget that there may be something easier, and yes, if it resists the deeper attacks it's probably safe against capture of cyphertext.
"But we all see how foolish that would be. You plan for the worst case scenario and hash+salt your passwords"
Sure. But in practice the plaintext + strong DB security may be safer "overall" than a hash + salt on a MySQL with the credentials forgotten in some config.php somewhere.
(It's not an excuse to not hash the passwords, though)
> Of course. But everything is limited and for each scenario there's a specific chance that will happen. Some RSA key sizes are breakable if you can put a lot of computing power behind.
I can agree with you that bruteforce attacks should not be within the scope of such a bug bounty prize or competition (unless somebody has exposed a flaw that allows for very easy brute forcing).
But that's not what's happening here. What's happening here is that the people running the show are handing out a few pieces of encrypted information and saying that since nobody can crack their stuff using that handed out information, their system is secure. It's easy to be confident in a controlled sterilized environment.
The blogger is pointing out that an attacker could very well have access to a lot more information and functionality than what they are handing out. They are only demonstrating that their system is safe in a "good case scenario" when everything goes as planned. They have not demonstrated that their system is secure if everything doesn't go as planned, if suddenly the attacker found a way to spoof the email messages and send his own prodding cypher, or something to that flavor, which isn't part of the neat little package they have arranged as part of competition.
Saying that "that's most likely not the case, the hackers wouldn't have anymore information or access" just is not a rebuttal to that. It's not a rebuttal to anything, it's just a brain fart.
I can agree with you that bruteforce attacks should not be within the scope of such a bug bounty prize or competition (unless somebody has exposed a flaw that allows for very easy brute forcing).
But that's not what's happening here. What's happening here is that the people running the show are handing out a few pieces of encrypted information and saying that since nobody can crack their stuff using that handed out information, their system is secure. It's easy to be confident in a controlled sterilized environment.
The blogger is pointing out that an attacker could very well have access to a lot more information and functionality than what they are handing out. They are only demonstrating that their system is safe in a "good case scenario" when everything goes as planned. They have not demonstrated that their system is secure if everything doesn't go as planned, if suddenly the attacker found a way to spoof the email messages and send his own prodding cypher, or something to that flavor, which isn't part of the neat little package they have arranged as part of competition.
Saying that "that's most likely not the case, the hackers wouldn't have anymore information or access" just is not a rebuttal to that. It's not a rebuttal to anything, it's just a brain fart.
Yeah, it's like saying "oh but the attack possibilities are so limited" to then proceed to mention how all the components can't bear the load of the bridge.
Well, if that piece of steel can so obviously not hold those 10000 tons of concrete given the corrosion over the next 30 years, it should be trivial to break it even with their limitations.
It has been shown that SHA1 is broken - it's just that experts in the field tend to be able to know such things before the bridge has collapsed, but that does not mean that they can demonstrate it to anyone who doesn't want to study the theories behind their assessment without building the bridge and waiting 30 years.
Well, if that piece of steel can so obviously not hold those 10000 tons of concrete given the corrosion over the next 30 years, it should be trivial to break it even with their limitations.
It has been shown that SHA1 is broken - it's just that experts in the field tend to be able to know such things before the bridge has collapsed, but that does not mean that they can demonstrate it to anyone who doesn't want to study the theories behind their assessment without building the bridge and waiting 30 years.
It looks to me the SHA1 part is the least of their worries.
Yes, the pillar may corrode in 30 years, but the load is actually on a smaller and frailer pillar
Yes, the pillar may corrode in 30 years, but the load is actually on a smaller and frailer pillar
And yet, the fact that a bridge design contains a pillar that any expert expects to collapse after 30 years might tell you something about the designer's competence and thus about the viability of the whole design.
This is not so much about showing how to break their system, but about showing how their design methodology is likely to produce an unreliable system - because that (a) is much easier to do than actually breaking a system and (b) precisely because of that is how cryptographers usually work and (c) it is actually known to be possible to build systems that are more likely to be and to stay secure, so there is no point in compromising reliability for implementability.
This is not so much about showing how to break their system, but about showing how their design methodology is likely to produce an unreliable system - because that (a) is much easier to do than actually breaking a system and (b) precisely because of that is how cryptographers usually work and (c) it is actually known to be possible to build systems that are more likely to be and to stay secure, so there is no point in compromising reliability for implementability.
>> Well, if the algorithm is so broken then it should be trivial to break it even with their limitations.
This is the critical sentence from the article - "If you want to show that a system is secure, give the adversary as much power as possible, and if they still can’t break it, the security is good."
This is at the root of modern crypto systems, and without it a system is considered broken.
It may be that within the rules of the contest, breaking one message is non-trivial. That doesn't mean that I couldn't (for instance) collect and analyse multiple individual's traffic over time, or find a way to alter data in-flight, both of which are specifically ruled out of the contest.
This is the critical sentence from the article - "If you want to show that a system is secure, give the adversary as much power as possible, and if they still can’t break it, the security is good."
This is at the root of modern crypto systems, and without it a system is considered broken.
It may be that within the rules of the contest, breaking one message is non-trivial. That doesn't mean that I couldn't (for instance) collect and analyse multiple individual's traffic over time, or find a way to alter data in-flight, both of which are specifically ruled out of the contest.
Designing a protocol so that is does not leak is very hard.