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.
As I said, I don't really know much about, but this is bullshit.
RSA lacks perfect forward secrecy is same as saying that ECDH lacks perfect forward secrecy. Both is true, and both can be used with ephemeral keys, which provide forward secrecy to both (and therefore must use other way to authenticate). Claiming that it's somehow RSA's problem while willfully pretending that it doesn't concern elliptic curve cryptography is very dishonest.
sybrenstuvel/python-rsa/ is PKCSv1.5 which like lvh said, is not secure.
RSA is fundamentally less secure than Diffie-Hellman as it lacks forward secrecy. So even a perfect implementation of RSA is still less secure than DH.
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.
> By using libsodium, you're not rolling your own crypto.
That's debatable. Libsodium does not have a proper authenticated key exchange. The key exchange does the job somewhat, but it has worse security properties than a properly crafted interactive protocol.
Problem is, designing your own key exchange protocol is more delicate than most construction. I know, I designed my own, and made several serious mistakes in the process (one of which voided an important security property).
Granted, rolling your own constructions is generally less error prone than rolling your own primitive. But it still shouldn't be done without at least having followed and fully understood an introductory course in cryptography (I recommend https://www.crypto101.io/). I mean, I did quite a bit more than that, and I still don't fully trust myself.
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.
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.