CryptoFails collects and explains examples of badly designed or broken cryptography in real software.
Commenters cite it for examples of bad implementations, like the 46ESAB password hashing post, and list it among crypto blogs.
The sad truth is that even libsodium can be misused (and the article explicitly mentions that twice). Even pretty high-level constructions like libsodium's crypto_secretbox can be misused, and most of the constructs that libsodium exposes are quite low-level: crypto_sign_detached, crypto_kdf_hkdf, crypto_kx, crypto_generichash.
I think we should understand and teach "do not roll your own crypto" in the context of what constructs are used for what purposes.
AES is proven to be secure and "military-grade" if you need to encrypt a block of data which is EXACTLY 128 bit (16 bytes) in size. If you want to encrypt more (or less) data with the same key, or make sure that the data is not tampered with or even just trust encrypted data that passes through an insecure channel, then all bets are off. AES is not designed to help you with that, it's just a box that does a one-off encryption of 128 bits. If you want do anything beyond that, you go into the complex realm of chaining (or streaming) modes, padding, MACs, nonces HKDFs and other complex things. The moment you need to combine more than two things (like AES, CBC, PKCS#7 padding and HMAC-SHA256) in order to achieve a single purpose (encrypting a message which cannot be tampered), you've rolled your own crypto.
Libsodium's crypto secretbox is safe for encrypting small or medium size messages that will be decrypted by a trusted party that you share a securely-generated and securely-managed key with. It's far more useful than…
There is a lot of hype over encrypted chat programs.
Telegram's encryption is not end-to-end unless you opt into "Secret Chats"[1] and many claim their crypto is not secure[2,3] as they rolled their own[4].
The latest Google chat app Allo also backed away from defaulting to end-to-end encryption for all messages as it lessens the quality of their auto-assistant[5].
The Axolotl protocol (developed by Moxie and Trevor[6]) is available in Signal and was later adopted by WhatsApp. Signal has far fewer features than other chat applications, and people aren't clamoring much about it; I would guess because many people place features > crypto.
Wire (wire.com) uses this protocol as well[7].
WhatsApp being part of Facebook has already called into question their handling of privacy[8], the feature they were originally advertising as their main strength.
[1] https://telegram.org/faq#secret-chats
[2] http://security.stackexchange.com/questions/49782/is-telegram-secure#49802
[3] http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest
[4] https://news.ycombinator.com/item?id=6916860
[5] https://news.ycombinator.com/item?id=12547130
[6] https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm
[7] https://wire.com/resource/Wire%20Security%20Whitepaper/download/
[8] http://www.nytimes.com/2016/08/26/technology/relaxing-privacy-vow-whatsapp-to-share-some-data-with-facebook.html
WhatsApp is almost certainly safer and more privacy respecting than Telegram.
Telegram uses highly nonstandard cryptography (the founder hired a bunch of math competition winners and told them to design encryption from first principles), doesn't have E2E by default (unlike Whatsapp), and is owned by a quite sketchy Russian oligarch who started spending on democracy-related causes after a falling out with Putin.
Telegram uses dubious encryption and lies about their business (for ex calling themselves a nonprofit when they aren't), and they retroactively retracted and then narrowed their bug bounty program.
WhatsApp hired the company behind Signal to help them implement Signal's encryption protocol.[1] While it's not as good as Signal because it's not open source and thus can't be independently verified, if Facebook deliberately lied about the security of a product used by governments around the world they would face serious consequences.[2]
See for example previous discussion [3].
For a detailed analysis of the flaws in their protocol, see [4]
1: https://techcrunch.com/2014/11/18/end-to-end-for-everyone/
2: https://www.nytimes.com/2019/10/26/world/asia/afghanistan-whatsapp-taliban.html
3: https://news.ycombinator.com/item?id=15281788
4: https://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest
Eh, thanks for the info on MTProto2. They made poor decisions initially, and doubled down on them, and thus I didn't (and still don't) think it worth my time to follow their changelog.
The contests are not remotely sufficient. Here's a good article:
https://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest
"I’ll repeat it again: 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."
Secure protocols take a lot of expert analysis to build consensus that they're worthwhile. That requires engaging with the community of researchers on their own terms and using established best practices.
Finally, Telegram's server code is still closed source and thus can't be reasonably audited. Could an attacker (or state actor) with server access decrypt stored messages? Maybe! That's why default e2e encryption with well-audited, open-source code is the gold standard...
Basically, the problem is that they invented a lot of their own crypto from scratch. When asked about this, they said "it's fine, we're smart" and then claimed to prove their security with a red herring contest.
Here are some publications about security problems with the platform:
- A class project at MIT found several problems (May 2017) [0]
- They were featured on Crypto Fails (Dec 2013) [1]
- Jakob Jakobsen @ Aarhus University published a vulnerability discovery (May 2015) [2] and then did his Masters thesis on additional problems (Sep 2015) [3]
-Tomas Susanka @ Czech Technical University in Prague published additional vulnerabilities (2016) [4]
Plenty more out there.
[0] https://courses.csail.mit.edu/6.857/2017/project/19.pdf
[1] http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest
[2] https://eprint.iacr.org/2015/1177.pdf
[3] http://cs.au.dk/~jakjak/master-thesis.pdf
[4] https://www.susanka.eu/files/telegram-article.pdf
The blog post in question (which I wrote) literally opens with a link to https://www.cryptofails.com/post/75204435608/write-crypto-code-dont-publish-it that encourages people to learn about it! Yes, even if that type of learning means (privately) writing crypto code.
Why would you expect the comments about it to argue in favor of "still learning" when the blog post never advocated against learning? They aren't making this point because I didn't make the contrary one, so there's nothing to argue with.
That you're only seeing negativity and discouragement is a cognitive distortion. I'm not qualified to help people with those, but I hope pointing that out might help you see that the world isn't against you.
That software developers presently and generally are bad at understanding cryptography doesn't mean it's impossible to learn, or that you should be discouraged from learning.