The DROWN Attack • Hacker News Board

Re: The DROWN Attack

#201

Post by Natanael_L » Wed, Mar 02, 2016, 2:22 PM UTC

Nimi wrote: post #199

Natanael_L wrote: post #198

Earlier quoted context omitted.

Then a bunch of big companies announce they'll use another browser to be able to keep using it

Another browser beside Chrome, Firefox and IE? OK, so Symantec announces that they will only use Opera. Even then, they have to deal with their customers, website operators who need a certificate trusted by the big 3 browsers, leaving. In fact, now that Let's Encrypt certificates are free, it seems like this is the Symantec CA's worst nightmare.

Not CA:s, but clients like banks

Re: The DROWN Attack

#202

Post by joeyh » Wed, Mar 02, 2016, 2:59 PM UTC

pmcao wrote: post #183

Is there anyone developing an exploit for this attack? You'll need a vulnerable openssl version to test. After major Linux distros releasing the path, it'll be difficult to obtain the vulnerable openssl. Timemachine (debian) is a tool that constructs a Docker image of a Debian base system. You can choose a Debian distribution and a date in the past. Then install any (vulnerable) package of your choice for experiment.…

Are you familiar with version control systems?

Re: The DROWN Attack

#203

Post by Quiark » Thu, Mar 03, 2016, 8:21 AM UTC

tptacek wrote: post #67

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…

To me, as a SW engineer, the mitigation against the padding oracle attack in SSLv2 (pretend its correct and generate random PMS) seems like a very bad hack. Is there some better, more modern way to protect against bad input that eliminates this entire class of problems, similarly as we use encrypt-then-HMAC or GCM for encryption?

Re: The DROWN Attack

#204

Post by eru » Fri, Mar 04, 2016, 7:35 AM UTC

CiPHPerCoder wrote: post #107

cperciva wrote: post #106

Earlier quoted context omitted.

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.

In my experience, this is how developers see crypto: 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.

> These are the same developers who ask on StackOverflow how to decrypt MD5, of course.

Rainbow tables. Duh!

Re: The DROWN Attack

#205

Post by CiPHPerCoder » Fri, Mar 04, 2016, 4:15 PM UTC

eru wrote: post #204

CiPHPerCoder wrote: post #107

Earlier quoted context omitted.

In my experience, this is how developers see crypto: 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.

> These are the same developers who ask on StackOverflow how to decrypt MD5, of course. Rainbow tables. Duh!

That's not decryption.

Re: The DROWN Attack

#206

Post by eru » Sat, Mar 05, 2016, 2:30 AM UTC

CiPHPerCoder wrote: post #205

eru wrote: post #204

Earlier quoted context omitted.

> These are the same developers who ask on StackOverflow how to decrypt MD5, of course. Rainbow tables. Duh!

That's not decryption.

Of course, not.

(Though I wonder if you can make a pedantic argument, that if the domain of your one-way function is suitably restricted (eg to passwords humans actually come up with) they do become bijective.)