Back in September, he issued a new public key of 4096 bits.
It seems to me that offering a bug bounty can significantly improve the security of a system, even when the prize-money is relatively small.
Telegram, on the other hand, is trying to prove that their algorithm is unbreakable. AES is pretty good too.
As is noted in other comments, it's generally the system, not the algorithm, that gets broken.
This Telegram contest may seem superficially similar to that fair contest, but it differs in some important ways. First, this contest isn't rewarding "best effort". Second, this contest doesn't meet those criteria, because their central server isn't being tested here. The goal of a product like Telegram is to defend against adversaries like governments, and hence governments will be able to probe their servers for weaknesses. You may say that we, too, can do the same, but if that's the case, a test server should be made available and the contest should explicitly try to get as many people as possible to break it.
This contest is interesting, but it's too artificial. As just one example of why that's the case: breaking real-world crypto often relies on side channel attacks, for instance timing attacks, and there's no opportunity of employing those attacks here due to the artificial nature of the contest.
Once again, if people here are interested in a secure alternative to Telegram that doesn't rely on public stunts for cryptanalysis, then check out TextSecure. It was designed by cryptographers, is open-source, and has been studied in detail for years. https://whispersystems.org/
EDIT: It appears Telegram is also vulnerable to MITM attacks. This is the NSA's preferred method of gathering info, so this is the most likely attack vector against Telegram. Due to the design of the protocol, there seems to be no defense. https://news.ycombinator.com/item?id=6931892
Telegram's response is "we protect against this because if you've initiated a secret chat previously, then you're protected." However, this isn't true. 1) a global adversary like the NSA can (and will, if they become interested in Telegram) simply MITM every secret chat session when they're first initiated; therefore if you use Telegram, you should assume the government has your data anyway, since this protocol offers no protection against mass snooping. 2) Secret chats aren't even the default type of chat in Telegram anyway, making it very unlikely that users will be protected by it. The defaults need to be secure.
https://news.ycombinator.com/item?id=6931961 (Telegram's response, which seems to verify that secret chats can be MITM'd on first initiation.)
https://news.ycombinator.com/item?id=6931903 (Demonstrates that Telegram seems to be misunderstanding why someone breaking into the central server can MITM your chats.)
From what I've seen, they use something called the "Axolotl Ratchet", developed by Trevor Perrin. A quick search of his name didn't yield any crypto papers / research by him.
Also, you write "and has been studied in detail for years"
There are no links/references to code/protocol reviews in the WhisperSystems website.
Again, I have the utmost respect for their research, it's just that from the side of a non-crypto-versed user/coder, Telegram and TextSecure look the same.
> Again, I have the utmost respect for their research, it's just that from the side of a non-crypto-versed user/coder, Telegram and TextSecure look the same.
Yep, it's frustrating to be the quixotically genuine seller in a market for lemons.
Here are some resources:
You might also try reading some of his more recent discussion comments on IETF working groups:
- (from 2002): http://mhonarc.domainunion.de/archive/html/ietf-openpgp/2002...
Just a few things that turned up when I Googled him.
2. wait until sender mistypes destination on one message.
3. claim prize.
> [...] the contest is fair because 1) the algorithm is completely specified, 2) there are no arbitrary definition of what winning means, and 3) the algorithm is public domain
Not satisfied at leaving it there, they then claimed that their crypto system doesn't need to be justified, because their customers aren't concerned about the specifics of their implementation of known broken algorithms.
Finally, they placed the burden of proof on the public, which doesn't work when it comes to cryptography.
They were given the opportunity to explain their design decisions in an environment of mutual respect, and they responded to this offer by stonewalling two of HN's resident security gurus.
(regardless of the product, they succeeded in a cheap way to get launched, very likely at a cost of $0)
1) They are giving you the source code, protocol, and a tcpdump of all traffic between the chatters. You can even send messages via the protocol to one of the participants. Its not just here is some encrypted data, decrypt it.
2) They are offering a significant amount of money.
2) there are no arbitrary definition of what winning means
The definition of winning in this contest creates a large class of potential vulnerabilities that would be paid $0.
If they just encrypted their communications with AES-128 in ECB mode with a fixed random secret key, the challenge could not be won. And that's not even semantically secure. So we will learn absolutely nothing about the security of their software from the results of this challenge. Whoever designed this challenge is either extremely dishonest or knows nothing about cryptography.
If they really want to improve their software, they should offer a $200,000 bounty for a proof of concept implementation of an attack within their threat model.
Edit: I originally started this post with "...probably designed to get press rather than to actually improve the software...", which I have removed, since I have no evidence to support the claim.
The point is, the above challenge is impossible without a MITM attack, and that MITM attack has to take place when I first save the server keys on my computer. The point is that there are numerous cryptographic protocols available which can not be broken using currently available technology.
This contest will prove one thing, and one thing only, the cryptographic algorithm they are using is secure. And it SHOULD be, considering that there are a lot of publicly available secure algorithms. This contest, however, will not prove that the Telegram service is secure.
It doesn't even prove that. It proves that no one has told you about any flaws yet. The algorithm may be secure, but their implementation of it might have bugs.
When they do enabled it for the first time, we can instantly MITM them using the attack against the "image verification" I mentioned lower down (https://news.ycombinator.com/item?id=6932053), and we can assume that the conversation is worth our while listening in on. The user will hopefully expose themselves in the belief that they are safe, and the game is over.
> the server can perform a MITM attack.
> you cannot detect MITM between you and your peers.
>> NOT true. You can compare key visualization in the clients.
The key is not shown in hex, so a MITM is quite simple.
This is still vulnerable to server-side _key_ MITM. It's the hushmail/iMessage/etc silent escrow key attack.
Blue in the top and bottom, white line through the middle. So little information that anybody could simply brute force the keys until they found one that matched the description well enough.
I'd happily write a little attack for that, but it's clearly not "breaking" the system enough for the bounty.
Don't you think that you are basically fighting a needless uphill battle here? I mean, people crave a good encrypted communication system and you have the intent and the infrastructure in place, but you are shooting yourselves in the foot with your cryptographic design indulgence. This animosity will continue, because Telegram crew comes across as cocky and arrogant know-it-alls, and not because people think you cannot design a crypto protocol. The contest doesn't help a bit, it only further enforces the impression of arrogance on your end. This is not what you would've done if you in fact allowed for the existence of flaws in your design. You would've released an RFC instead.
I have all the sympathy for you. I don't doubt your motives, but you are setting yourselves up against skilled technical crowd. It has already started off on the wrong foot and this unfortunate dynamic will continue.
Perhaps consider offering an alternative crypto suite based on standard protocols? In parallel with what you have. Just reuse an existing crypto framework and redo transport layer to your needs.
>> Perhaps consider offering an alternative crypto suite based on standard protocols? In parallel with what you have. Just reuse an existing crypto framework and redo transport layer to your needs.
Again, I am not cryptographer. But as a person who wants his data to be secure I don't see anything wrong with different teams trying different approaches. I 100% agree that people crave a good encrypted communication system, but I'm not sure it can be achieved in a world where everybody uses similar methods. What if some of the common "best practices" are intentionally promoted in the crypto-community as the best ones exactly because they contain flaws and backdoors?
Please allow me to give you an example of something that could be just that.
The Telegram team was criticized by some NH critics for their custom auth key exchange protocol. People asked – why take a random value from server and a random value from client and combine both with a creepy function? Why not, e.g., just generate a random value on the client and use RSA instead? Well, the answer is simple – the Telegram guys did not trust that the random value generated on the client-side was really random.
In August 2013 it turned out that their custom approach to protocol enabled Telegram to stay more secure when multiple other secure apps using more conventional solutions were hacked (http://android-developers.blogspot.ru/2013/08/some-secureran...). Many Bitcoin apps were cracked and people lost money, Open Whisper Systems (I noticed these guys are aggressively promoted here in the NH community as the epitome of best security) had to hasten to patch their RedPhone app to avoid that vulnerability.
So I'm kind of suspicious when I see strong pressure to enforce the use of common techniques and get rid of uncommon ones just because they are uncommon. I think the Telegram guys have the right to choose their own path, and I'm sure our society will only benefit from it.
Of course, building custom solutions is no easy task and requires a lot of effort. But I've seen some of the Telegram guys (yes, the "6 ACM champions") create things that I'd thought were impossible. Maybe I am wrong in putting my trust in their abilities, and I will be fined $200K+ for my naivete. However, I am willing to continue financing such contests, and I do hope that eventually we'll all get something much more valuable than $200K.
> People asked – why take a random value from server and a random value from client and combine both with a creepy function?
People well-versed in applied crypto would never ask this question, because all standard key exchange protocols most certainly use both sides as a source of randomness. Furthermore - "creepy"? That's all you got away from all those comments that said your KDF was unproven, not peer-reviewed and weak in comparison? You basically cherry-picked a dumb question (I assume you haven't made it up) and then proceeded to demonstrate how clever you are. Guess what? You just reiterated basic facts, but assigned them to yourself.
Let me repeat what I said. Your problem is not your crypto. Your problem is the attitude.
OK, now I can see your point. Thank you for taking the time to reply and share advice.
Just so we're clear, this rules out:
* Chosen plaintext attacks
* Chosen ciphertext attacks
* Adaptive chosen ciphertext attacks
* EDIT: Also any kind of side channel
The only thing that would fail to meet this definition of security is repeating key XOR. And RC4.
Which is where the weaknesses (as witnessed by bitcoin shenanigans) lie, anyhow.
If it proves resilient over 2.5 months of highly motivated attacks (motivated by both the money / "I-Told-You-So" factor), I think that's a fairly strong statement in their favor.
Logan's law: In any given discussion tangentially related to security, the thing presented as "secure" will be soon declared "definitely not secure"... because...NSA.
I just wanted to point out that there were times when money was not a very good motivator for someone who could break a given encryption system.
Bug bounties by big name companies that are actually after bugs rather than publicity haven't miraculously made all their software perfect. And they don't have an end date either.
1) A classical crypto-challenge where you are given a cipher text and the algorithm and told to crack it is somewhat useless Because that would just prove strength of the primitive algorithm, not the system. Here you are given a scenario and told to use whatever attack is at your disposal to hijack the conversation and somehow retrieve the plain text. So while it is similar to in someways, but not exactly the same case.
2) People are not amused because they seem to find the vulnerability that upon initiation of the secret chat, the first time, the server can perform a MITM attack. Because apparently they use a Deffie-Helman key exchange where the server connects them to each other. So the server is in the best position to do the MITM. And since this contest does not allow to make that attack (even if u had the server in your control, the secret chat has been initiated already).
And hence everyone is frustrated because they seem to KNOW the system is weak, but they cant prove it right now. And this will lead to Telegram boasting in March.
To make this a slightly fair challenge, we should at least be allowed to get the clear text of our choice also encrypted with the same key.
I'll take my $2k now.
In all seriousness, im interested to see if anyone can crack this.
I'm really excited to see if this is cracked!
Rolling your own encryption has always been proven to be the worst idea.
I personally think it's great that people are trying various solutions. Disclaimer: I know little about cryptography
> Q: What if I don‘t trust bitcoins and don’t want them as a prize?
>If the winner prefers conventional money over bitcoin, we will be happy to transfer them 200,000 regular USD instead of BTC.
how you are then going to make a money ?
And converting into bitcoin months preemptively is a speculative gamble, not a verification of anything.
How do I know they are being honest?
They should have signed that blog post with their BTC wallet.
I don't think money is going to be a problem here.
I don't personally have the depth of experience with elliptic curves to go about cracking this crypto, but others have cracked elliptic curve algorithms. Perhaps one of those people will find this tidbit useful in narrowing the field.
Also, I would expect that at least some of the plain text is Unicode, probably the plane from 0400-04FF.
The last point Schneider made of them winning but not telling you until they feel it's worth it is still valid.
<Magic Number (Nonce?)> . <Magic Number> <Number of bytes + 1> IN/OUT <Ip Address>
The cryptanalysis community, in particular, has a small group of experts that can credibly critique your ideas. They would probably love to pick apart a new system...seriously in the hopes that it advances the art, but critically in the case that it doesn't.
Claims of some kind of "tightly knit" cabal of closed minded people excluding you would be a warning sign. (It sounds like creationism. Not that this is what these guys did. I'm just saying.)
Maybe instead of a competition they could have just approached some of the cryptanalysis community for an early look? Those guys could kick the tires and pass it on to others that they know. That really seems to be how this area works.
Just because it appears here does not in any way shape or form indicate that they're trying to impress the HN community, nor that they're specifically targeting HN.