https://www.schneier.com/crypto-gram-9812.html
$300,000 isn't a whole lot more than it would cost to get n entire novel cryptosystem for a complex application built out of idiosyncratic components assessed professionally. They should just retain Riscure or Rambus to do that for them instead of the PR stunt.
Previous thread about Telegram on HN, featuring Moxie Marlinspike:
–$300 000, and good publicity among security experts.
What's the mathematical expectation of "Let's start a contest with $300K for dealing with our crypto on our terms (assuming 5% of success)"?
–$15 000, and much larger PR effect. ($300K-resistant crypto, yay!)
Seems to be an easy choice, unfortunately.
> They should just retain Riscure or Rambus to do that for them instead of the PR stunt.
I'd love to go back through either of the previous threads and count to see how many people were saying "well, if no one can successfully win the challenge, they can use the money for a security audit!" like they are right now.
Telegram is pretty clearly a bad player that should be avoided.
https://konklone.com/post/why-google-is-hurrying-the-web-to-...
From the contest: "This can happen if a security check is failed, or in the case that the first 128 bits of the SHA-1 of the newly created encryption key don‘t match on both parties’ clients when this stage is completed (this corresponds to Paul and Nick comparing the key visualizations for the Secret Chat in their Telegram apps)."
https://www.schneier.com/blog/archives/2012/10/when_will_we_... "211 * 28.4 = 219.4 ~ $700K by 2015"
The cost of brute forcing the answer is greater than the prize for the contest.
"This can happen if a security check is failed, or in the case that the first 128 bits of the SHA-1 of the newly created encryption key don‘t match on both parties’ clients when this stage is completed (this corresponds to Paul and Nick comparing the key visualizations for the Secret Chat in their Telegram apps)."
This contest basically admits its crackable for more than $300k as well. They even reduced the number of bits for a collision. :/
No? Doesn't this fit the definition of a contest? http://en.wikipedia.org/wiki/Advanced_Encryption_Standard_pr...
Yes, the fairness of the contest plays an important part, and a fair context where only the algorithm is analysed goes a long way.
"Just because no one wins a contest doesn't mean the target is secure...it just means that no one won."
Of course. But the fact that it passed revision by experts means it is (probably) safe today (and for what it is known, it might be trivially breakable "behind closed doors")
"Our Twofish cryptanalysis contest offers a $10K prize for the best negative comments on Twofish that aren't written by the authors. "
Ah ok, so contests suck, except for the ones we throw. Nice.
"There are no arbitrary definitions of what a winning analysis is." No? So what is "best negative comment"? It's still subjective. And the 2nd best gets nothing? Who determines that?
The Twofish bounty was a bounty that guaranteed payment to the best technical critique of a very specific, well-defined cryptographic primitive.
Fair enough. And the focus is exclusively on the algorithm (which is good).
> "The Twofish bounty was a bounty that guaranteed payment to the best technical critique of a very specific, well-defined cryptographic primitive"
"the best technical critique" is still subjective.
There's an undated article https://www.schneier.com/twofish-contest.html pointing to a dead link
All you are getting is the over-the-wire exchanges which makes it kinda a joke.
The part that is actually vulnerable to attack is the way the client functions and handles keys.
MitMing after a key exchange isn't helpful since its like getting the PGP text after its encrypted. You have to brute force the keys at that point.
That's not too dissimilar to suggesting hiring an ISO-certified shop to redo your beautiful hand-optimized assembly code in an industry-standard Java. It's a simplification, but I'm pretty sure a large chunk of HN can relate to how much of a killjoy letting others do the interesting parts is.
In the end all these not-so-subtle backstabs and innuendos that they are just a bunch of annoying f#cking amateurs is counter-productive. They won't be using SSL and $300K is not enough to run their custom crypto through an audit that will be good for all the "experts". Besides, the main issue with the Telegram is not their crypto, is not the contests, it's the fact that they got off the wrong foot with the public applied crypto community. In theory, they should be fixing that, but in reality they don't seem to give a flying f#ck about it, which to me actually looks more like a show of a backbone rather than of an ignorance.
Ultimately they want the same thing as this Moxie person. They want less surveillance. Now pray tell why they should have their head repeatedly dunk in a toilet bowl every time their project gets a mention?
Great! I like to scribble out sponge functions while eating lunch. I've made a few toy stream ciphers. Crypto is fun as all hell, and it's a great way to learn things!
But novelty isn't really a good thing when it comes to actually depending on crypto. You want something that's been well studied by lots of smart people. To paraphrase Schneier (I believe), anyone can design an encryption process that they can't break - the real challenge is keeping the people who are smarter than you from breaking it as well.
Novelty is an _extremely_ bad reason to design and deploy cryptography.
> They want less surveillance. Now pray tell why they should have their head repeatedly dunk in a toilet bowl every time their project gets a mention?
Because the applied crypto community points out issue after issue after issue with their product and is met with variations of "nuh uh, it's fine!"
Bad crypto is worse than no crypto because either way the NSA is watching you, but when you use no crypto you're at least forced to admit to yourself that your adversary has you in their crosshairs.
Well, no. That's the thing. That's a Hollywood version of it. He said she said it's all horrible piece of shit, because of something someone else said earlier on an unrelated subject. What makes rounds is the regurgitated abstract hate towards Telegram, whereby the factual matter has been long forgotten.
Let me put it this way - name a couple of open design issues with the current Telegram protocol.
Sorry, it doesn't work this way: 'When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.'
The GP said there were numerous issues identified with Telegram's design, all of which were brushed aside by Telegram devs. I asked to name a couple of them.
https://core.telegram.org/img/mtproto_encryption1.png
The use of encrypt and MAC is the one that should jump out at even a crypto neophyte.
There are some nice proofs around this[1] that I've read before. The important one is that encrypt then MAC guarantees INT-CTXT: it's computationally infeasible to produce a ciphertext not before sent by the sender. INT-CTXT implies INT-PTXT which is the weaker claim but typically the one people associate with the function of a MAC: that you can't forge a plaintext the sender never sent.
While E&M isn't immediately bad it has been used as an avenue for attack[2]. If Telegram's aes_ige_decrypt() function accidentally overflows a buffer... and because they're doing E&M it must call aes_ige_decrypt() on whatever message I decide to send it.
Now, Telegram can claim that those attacks don't apply because of their use of IGE, and they may very well be correct! But then we move into IGE: there are known attacks that show chosen error introductions can cause the stream to resynchronize without error[3]. What does that mean in practice? Who knows: we know IGE is broken, but we don't know how badly because no one actually studies IGE, or knows how it is implemented in this system!
The real failings here: Telegram uses a MAC with less security guarantees AND a cipher mode that would be charitably described as anonymous, instead of using a provably secure MAC along with well-studied modes.
Now, I'm a big security dummy (seriously) but if there's one thing people far smarter than me have banged in my head, it's this: you follow the well-beaten path precisely because it is well-beaten. When you start venturing off the trail into the woods of funky block cipher modes and known-problematic MAC modes, your margins get a lot thinner.
[1]: http://cseweb.ucsd.edu/~mihir/papers/oem.pdf
[2]: http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...
[3]: https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UG...
Sorry, I'm a bit confused by the question :)
So I can make any message look OK just by hashing the plaintext. Heh. Wonder what that KDF looks like...
Not that it proves anything very much if it's not claimed.
If I find a few small flaws that are problematic, but not enough to claim the prize, I'll definitely keep them to myself until the contest ends. Instead of incentivizing people to share vulnerabilities with them, they incentivize hoarding bugs.
We know for a fact that most people aim for better known than just better.
Not so many news stories about simple OTR.