Earlier quoted context omitted.
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…
Telegram’s Cryptanalysis Contest
121–130 of 138 posts
Re: Telegram’s Cryptanalysis Contest
#122Earlier quoted context omitted.
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 wo…
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!
Re: Telegram’s Cryptanalysis Contest
#123Earlier quoted context omitted.
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…
Re: Telegram’s Cryptanalysis Contest
#124Earlier quoted context omitted.
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".
> 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)?
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.
Re: Telegram’s Cryptanalysis Contest
#125Earlier quoted context omitted.
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!
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
Re: Telegram’s Cryptanalysis Contest
#126Earlier quoted context omitted.
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!
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
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.
Re: Telegram’s Cryptanalysis Contest
#127Earlier quoted context omitted.
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…
[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?
Re: Telegram’s Cryptanalysis Contest
#128Earlier quoted context omitted.
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!
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
Re: Telegram’s Cryptanalysis Contest
#129Earlier quoted context omitted.
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…
Re: Telegram’s Cryptanalysis Contest
#130The 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 ch…
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.