3 ms·

RSA is hard to secure? As far as I know, 2048 bit RSA has still not been cracked?

by RedShift1 2y ago

robertlagrant 2y ago
As in hard to get the implementation right.
- RedShift1 2y ago
  Why would you write your own implementation when RSA functions are baked into Java's standard library?
  - unscaled 2y ago
    Why would you trust that the RSA implementation baked into Java (or anything for that matter), is safe? Java is also implemented by human beings. The Java RSA implementation apparently had a timing side-channel attack vulnerability for many years that was only discovered this year[1]. I don't know if there were more serious issues with the Java RSA implementation, in the past, but the same cannot be said about their ECDSA implementation. It was completely broken for a while before it was discovered[2]. Bad implementation can happen with any algorithm, but if the algorithm is simpler and built to be more foolproof like Ed25519, that's just far less likely. Unfortunately most of these libraries are not written by a professional cryptographer who codes without bugs, and even Daniel J. Bernstein, a cryptography expert who IS famous for writing software without almost no bugs[3], criticized RSA and ECDSA[4] and designed Ed25519. To be honest, if even djb doesn't want to implement RSA and ECDSA then I honestly think nobody should. --- [1] https://www.rapid7.com/db/vulnerabilities/redhat_linux-cve-2024-20952/ https://www.rapid7.com/db/vulnerabilities/redhat_linux-cve-2... [2] https://www.cryptomathic.com/blog/explaining-the-java-ecdsa-critical-vulnerability https://www.cryptomathic.com/blog/explaining-the-java-ecdsa-... [3] http://www.aaronsw.com/weblog/djb http://www.aaronsw.com/weblog/djb [4] https://blog.cr.yp.to/20140323-ecdsa.html https://blog.cr.yp.to/20140323-ecdsa.html
unscaled 2y ago
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...

RSA is hard to secure? As far as I know, 2048 bit RSA has still not been cracked?

robertlagrant 2y ago

As in hard to get the implementation right.

RedShift1 2y ago
Why would you write your own implementation when RSA functions are baked into Java's standard library?
- unscaled 2y ago
  Why would you trust that the RSA implementation baked into Java (or anything for that matter), is safe? Java is also implemented by human beings. The Java RSA implementation apparently had a timing side-channel attack vulnerability for many years that was only discovered this year[1]. I don't know if there were more serious issues with the Java RSA implementation, in the past, but the same cannot be said about their ECDSA implementation. It was completely broken for a while before it was discovered[2]. Bad implementation can happen with any algorithm, but if the algorithm is simpler and built to be more foolproof like Ed25519, that's just far less likely. Unfortunately most of these libraries are not written by a professional cryptographer who codes without bugs, and even Daniel J. Bernstein, a cryptography expert who IS famous for writing software without almost no bugs[3], criticized RSA and ECDSA[4] and designed Ed25519. To be honest, if even djb doesn't want to implement RSA and ECDSA then I honestly think nobody should. --- [1] https://www.rapid7.com/db/vulnerabilities/redhat_linux-cve-2024-20952/ https://www.rapid7.com/db/vulnerabilities/redhat_linux-cve-2... [2] https://www.cryptomathic.com/blog/explaining-the-java-ecdsa-critical-vulnerability https://www.cryptomathic.com/blog/explaining-the-java-ecdsa-... [3] http://www.aaronsw.com/weblog/djb http://www.aaronsw.com/weblog/djb [4] https://blog.cr.yp.to/20140323-ecdsa.html https://blog.cr.yp.to/20140323-ecdsa.html

unscaled 2y ago

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...