Five years ago, today, the infosec community found itself wondering about Robert Edward Grant's Quasi-primes, and an ever expanding portfolio of grifts by his company, Crown Sterling. These included
* TIME AI, a completely bonkers, five-dimensional vaporware cipher with time-traveling keys,
* Black Hat 2019 crank presentation,
* Bogus RSA break claims, and later,
* Cryptographic protocol broken in just about all aspects,
* Cryptocurrency grifts, and as the newest addition,
* A browser-based messaging app.
This wiki-article documents and debunks pretty much all of it, in ridiculous detail and with more than 200 references.
Even if you were using a perfect implementation of RSA-OAEP, it would still be less secure than Diffie-Hellman over Curve25519 (called X25519) or Curve448 (called X448).
This is because RSA lacks forward secrecy: If the private RSA key is stolen, it can be used to retrospectively decrypt all past communication.
Also X448 provides the equivalent security of ~15000-bit RSA with a fraction of the key size, and key generation takes milliseconds instead of minutes.
tl;dr
For key exchange, use X25519 or X448.
For digital signatures, use Curve25519-based ed25519 signatures.
For authenticating communication, use authenticating encryption like ChaCha20-Poly1305 or Salsa20-Poly1305 or AES256-GCM.
For hash function, use Blake2 or SHA3-256 or SHA256.
There is no place to use RSA instead of Diffie-Hellman. DH provides forward secrecy, and the ECC variants are much faster and use shorter keys for equivalent security. They are harder to implement in a wrong way.
By using libsodium, you're not rolling your own crypto. Rolling your own crypto would mean
-trying to find new one way functions for public key crypto
-trying to implement RSA from textbook
-trying to implement RSA-OAEP from papers, RFCs, books etc.
Using a library is not anywhere near those. There are other ways to fail cryptography too, from not doing public key authentication, to storing private keys in insecure places.
Every time there's debate over Telegram's encryption the shill argument "it hasn't been broken in the wild now has it" pops up. This is fundamentally flawed thinking. The end-to-end-encryption is most likely reasonably safe (no glaring holes were pointed by experts except the IND-CCA problem). The real problem is Telegram uses their secret chats as a poor excuse for justifying the lack of E2EE for practically everything: "Just use secret chats if you need end-to-end encryption"
1. Telegram's E2EE is not on by default, therefore 99% of users don't use it.
2. Telegram's E2EE is not advertising authentication, therefore ~90% of the people using it don't check for MITM attacks, therefore majority of E2EE is useless against active attackers.
3. Telegram's E2EE does not work across devices, therefore majority people who use secret chats also use non-secret chats because desktop client don't support it.
4. 100% of Telegram's group conversations can be eavesdropped by the server, because Telegram doesn't have E2EE for group chats.
Complaining about possible cribs in how Telegram implemented the protocol from cryptographic primitives is an insignificant problem compared to the fact the entire protocol is fundamentally FUBAR, how it's so glaringly obvious you can't even fill out a CVE form.
If Signal had vulnerability where 100% of group conversations were not properly end-to-end encrypted, every newspaper in the world would publish something about it. However, with Telegram it has been spun as a "feature".
Another big problem is Telegram has been mentioned by hundreds of publications as "Secure apps like Signal, WhatsApp and Telegram".
To experts it's like hearing news spout "Great writers like Leo Tolstoy, Paulo Coelho, and Stephanie Meyer", or "Great bunker materials like reinforced concrete, steel, and MDF".
Repeatedly claimed, anyone would make mental associations between the three, but when you actually find out what they're about you can't believe your ears.
With DH both public keys have effect on the randomness of the shared secret. If the app on the client generates a random DH key-pair for every session, and it uses a public DH value of the server pinned to it, the encryption is authenticated and secure to use.
If there are no public keys pinned to clients (say secure messaging apps like Signal where each user generates their own keys), users need to check the public key fingerprints to make sure there's no MITM attack taking place.
I was able to install the software, but there is no documentation about how to create NTRU+X25519 keys and enable it. I checked manpages, mailing list and tried google. How is this done?
For example, cleanroom has classification that implies some amount of dust particles/impurities in the air. The technicians don't talk about the number of dust particles allowed, they just consider class 5 suitable for some applications whereas others might need class 4.
Class 4 cleanroom makes sense, as does "Ultra pure" as long as industry sees it as a standard.
Another example: UHD makes as little sense as FHD in terms of display resolution. I mean, Full must mean it's at maximum possible amount of high definition? Well we just know it stands for 1920x1080, and we know UHD or 4K is larger.
They're not. The message they convey is "we do what we please because even if we lose a case every now and then, we still win more in the long run. We own this business". Until the fines for such legal harassment are so severe losing actually damages the business, this will continue until our race is wiped by the climate change.
You can't possibly say one needs to compromise MIT's entire infrastructure when all it needs is MITM attacks against the browsing session. That doesn't require compromising either if you have a CA private key the client's browser trusts. Only if there is certificate pinning do you need the server's key, and even at that case you only need to compromise the private key of the university. You don't have to compromise every system to do that. Compromising only a single system among the small group of systems that hold the private key will do.
Your comparison is as thoughtless as the rest of your reply.
Until Tox defaults it's communication through Tor, it doesn't offer any notable differences. Sure, there is no central server, but intelligence agencies can see who you talk to without compromising server just by looking at the destination IP address of packets. Tox suffers from same MITM problems if the ToxID is changed e.g. on Twitter page of your contact, the same way the author of the article claims the "checksum" of Signal's APK can be changed by NSA, your employer or angry spouse.
People still need to communicate with their peers in insecure networks. Now you need to compare the nitty gritty details and choose the most secure one for your needs. If you need content protection to keep dick picks out of NSA office circulation, Signal is probably the best. For metadata-free chat, Ricochet and Briar are currently the top duo.
Remember that OTR, Cryptocat and PGP were secure enough when Snowden was agreeing about handing data to Greenwald and Poitras. So while Signal isn't secure if you're NSA's target, it might be secure enough to protect you from passive threat scanning.
It solves the problem of "how do I flaunt the fact I carry an iPhone to everyone around me"
It's a conversation piece and way to flaunt your wealth and status by uncovering a iPhone 17 Pro Max S+ Duo XTX from it when asked.