Yes, and you've just demonstrated the problem here. People believe RSA is secure if you just use 2048 bit keys, but the problem with RSA is the key themselves..

Yes, and you've just demonstrated the problem here. People believe RSA is secure if you just use 2048 bit keys, but the problem with RSA is the key themselves... And the padding scheme. For starters, let's look at the keys. You need to select a safe public exponent and safe private parameters. If you generate the key with openssl without mucking around with the parameters, you're likely to get a pretty strong key, but nobody guarantees the key is safely generated. To constant, in Ed25519 (or Curve25519) your key is just a random 256-bit string (32 bytes) with a a couple of bits being ignored. All keys are secure and you cannot generate or use an insecure key. Cryptosystem Rule #1: A good cryptosystem does not let yet generate insecure keys. Then you've got side-channel attacks. RSA is far more vulnerable to timing and cache side-channel attacks, due to its complex BigInteger math that usually relies on code that was designed for solving math problems, not for cryptographic operations. The Big Integer math also makes implementing RSA harder, and therefore RSA implementations are more likely to have bugs. Ed25519 is a good counterexample yet again. djb has famously implemented it in just a few 280-character tweets in TweetNacl[1]. The entire library contains Ed25519, Curve25519, Salsa20, Poly1305, SHA-512 and HMAC in 100 tweets or 800 lines of C code. Yes, there are many toy RSA implementations out there that are even shorter than that, but they either only use regular integers (limiting your RSA keys to puny 64 bits at best) or using third-party non-cryptographic Big Integer Math libraries, which brings us back to square one. Cryptosystem Rule #2: A good cryptosystem is designed to avoid cache and timing attacks. Cryptosystem Rule #3: A good cryptosystem is designed to be simple to implement The last issue is the padding. Almost all RSA implementations out there use PKCS#1 v1.5 padding, which has been known to be insecure for decades now. It is vulnerable to a padding oracle attack known as Bleichenbacher's Attack [2]. It's easier to exploit PKCS#1 v1.5 with RSA encryption than with RSA signatures, but it can also be exploited with signatures[3]. Ed25519 does not need any kind of padding. The signed data is always pre-hashed with the same hash which is defined by the algorithm (SHA-512). Cryptosystem Rule #4: If possible at all, do not require padding (e.g. use pre-hashed signaturesand stream cipher construction). If you don't trust me on this, you should still follow Latacora's Cryptographic Right Answers: Ed25519, the NaCl/libsodium default, is by far the most popular public key signature scheme outside of Bitcoin. It’s misuse-resistant and carefully designed in other ways as well. You shouldn’t freelance this either; get it from NaCl. Avoid: RSA-PKCS1v15, RSA, ECDSA, DSA; really, especially avoid conventional DSA and ECDSA. You can look at this blog for more information: https://blog.trailofbits.com/2019/07/08/fuck-rsa/ https://blog.trailofbits.com/2019/07/08/fuck-rsa/ --- [1] https://tweetnacl.cr.yp.to/ https://tweetnacl.cr.yp.to/ [2] https://en.wikipedia.org/wiki/Padding_oracle_attack#Asymmetric_cryptography https://en.wikipedia.org/wiki/Padding_oracle_attack#Asymmetr... [3] https://mailarchive.ietf.org/arch/msg/openpgp/5rnE9ZRN1AokBVj3VqblGlP63QE/ https://mailarchive.ietf.org/arch/msg/openpgp/5rnE9ZRN1AokBV...