The vulnerability here is tricky to exploit but actually simple to describe. There's a padding oracle in the form of RSA used by both TLS and SSLv2; by repeatedly sending permuted versions of a ciphertext to an SSLv2 server, you can gradually discover the plaintext†. Both SSLv2 and TLS have countermeasures for this attack. But SSLv2's countermeasures are sabotaged by the crappy ciphers it also supports. In both TLS a…
The DROWN Attack
101–110 of 206 posts
Re: The DROWN Attack
#102Re: The DROWN Attack
#103Earlier quoted context omitted.
RSA isn't obsolete. PKCS1v1.5 padding is obsolete.
I'm with you on this one. This 'RSA is evil' conclusion is like taking a look at [1]---or the gazillion Schnorr-style signature scheme nonce leaks published over the years---and concluding that elliptic curves are evil. [1] http://web-in-security.blogspot.com/2015/09/practical-invali...
Re: The DROWN Attack
#104The vulnerability here is tricky to exploit but actually simple to describe. There's a padding oracle in the form of RSA used by both TLS and SSLv2; by repeatedly sending permuted versions of a ciphertext to an SSLv2 server, you can gradually discover the plaintext†. Both SSLv2 and TLS have countermeasures for this attack. But SSLv2's countermeasures are sabotaged by the crappy ciphers it also supports. In both TLS a…
The problem is that RSA is also used for most certificates, including signing certificates. This attack also implicates digital signatures. While we've made good progress shifting towards DH/ECDH ciphersuites -- and TLS v1.3 will eliminate RSA entirely -- we have essentially no deployment of DSA/ECDSA certificates. It's all RSA. So "getting rid of RSA" sounds good, but won't happen in TLS/SSL anytime soon. Moreover,…
Re: The DROWN Attack
#105Re: The DROWN Attack
#106Earlier quoted context omitted.
I'm with you on this one. This 'RSA is evil' conclusion is like taking a look at [1]---or the gazillion Schnorr-style signature scheme nonce leaks published over the years---and concluding that elliptic curves are evil. [1] http://web-in-security.blogspot.com/2015/09/practical-invali...
I concede that "RSA is obsolete" is somewhat hyperbolic, given OAEP and PSS, but RSA is dangerous, more dangerous than modern curve crypto. Developers overestimate their ability to mitigate dangers.
Re: The DROWN Attack
#107Earlier quoted context omitted.
I concede that "RSA is obsolete" is somewhat hyperbolic, given OAEP and PSS, but RSA is dangerous, more dangerous than modern curve crypto. Developers overestimate their ability to mitigate dangers.
I think developers of elliptic curve crypto overestimate their ability too. Avoiding side channels in RSA is easier than avoiding them in ECC - fewer moving parts.
RSA: "I learned that as an undergrad. It's just multiplication, I'll use GMP!"
ECC: "Whoa what the hell is this? I better use a library."
These are the same developers who ask on StackOverflow how to decrypt MD5, of course.Re: The DROWN Attack
#108Earlier quoted context omitted.
Go to datacenter. Open cage. Plug in keyboard. Oldschool.
Are you shielding the keyboard from EM leakage? I don't open a cage, I get in one and do my work in there... No more EM eavesdropping.
Re: The DROWN Attack
#109Earlier quoted context omitted.
You have two choices then: - Use RSA until 25519/448 land in TLS - Switch to ECDSA in the interim Personally, I would switch even though ECDSA isn't great. The concerns over P-256 and P-384 are more academic than anything: They're hard to implement safely and without side-channels. Read: hard, not impossible. You shouldn't be writing your own ECDSA implementation, however. That'd be foolhardy. EDIT: I use secp384r1 f…
The NIST curves also have constants which may or may not be manipulated. Bruce Schneier recommends against using them.
Regardless, I'm not suggesting new cryptosystems should use the NIST P-curves. They shouldn't; those curves are just as tricky to use as RSA.
Re: The DROWN Attack
#110Is that because people don't pay attention when there's just a CVE number?