Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryptography in the Browser

blog.opal.io

Post reply on HN
Print view View original

11–20 of 85 posts

Re: Cryptography in the Browser

#11

Post by rosser »

notwhyships wrote: post #6
moxie wrote: post #2

Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…

This is a deck by Ben Adida (formerly of Mozilla, where he led the Persona project and now at Square) explaining how that argument is reductionistic. https://docs.google.com/presentation/d/1bLBb0EIJ0cuoAhsmI1XL...

Can you please help me find even an argument in that deck, let alone any refutation? Did I get an incomplete deck, perhaps? The version I'm seeing stops at slide 22.

Re: Cryptography in the Browser

#12

Post by derefr »

DanBC wrote: post #10
derefr wrote: post #7

Earlier quoted context omitted.

> Basically, the JS crypto is reducible to the strength of the SSL connection. Anyone on the other end of the SSL connection, or anyone who can break the SSL connection, can get your plaintext. This makes the JS crypto nothing but overhead. It's just hand-waving at that point. This is true. However, you can say the same thing about, for example, retrieving an ISO of Ubuntu. A cryptosystem is as weak as its weakest li…

> You can build a webapp that is only ever downloaded once, and from then on loads its own code from the filesystem; and which verifies new "releases" of its own source using whatever crypto it likes before overwriting the client-side stored copies of itself. But if you don't trust Hushmail they could force a back-doored update onto you.

At that point you've got "well, that's not worse than anything else, then" security. The NSA, for example, could MITM your computer's connection to Ubuntu's update servers, FISA a sysadmin for a copy of their package signing key, and inject a "critical security update" only for you. Auto-update systems are suspicious as a whole, now, and should only be trusted in general as a compromise to convenience, and the statistical unlikelihood of you being attacked.

Re: Cryptography in the Browser

#13

Post by tinco »

Please stop upvoting this article, it's misleading at best. It links to the article everyone should read on browser cryptography, the article that says exactly why browser cryptography does not and basically never could work.

The article then picks the least important of all security problems, that there isn't (wasn't) a secure way of generating random numbers, acts as if that was an important point and then carries on as if browser cryptography has been solved.

In their about page they claim: "As a result, Opal is able to guarantee that the only people who are able to read a secret file are the sender and recipients."

This is plainly not true. The people who are able to read these secret files are always those who control the browser. They might claim that they're able to guarantee it because they control the code that is sent by the server, but recent history has shown us that if they were to be forced to break that guarantee, they would not be allowed to let anyone know.

So what is their guarantee worth to anyone? Jack shit.

Re: Cryptography in the Browser

#14

Post by notwhyships »

rosser wrote: post #11
notwhyships wrote: post #6

Earlier quoted context omitted.

This is a deck by Ben Adida (formerly of Mozilla, where he led the Persona project and now at Square) explaining how that argument is reductionistic. https://docs.google.com/presentation/d/1bLBb0EIJ0cuoAhsmI1XL...

Can you please help me find even an argument in that deck, let alone any refutation ? Did I get an incomplete deck, perhaps? The version I'm seeing stops at slide 22.

There are 22 slides.

It's admittedly terse (it was part of a presentation Ben Adida gave at the first Real World Cryptography workshop).

However, I'd suggest reading the deck again, and while you do asking yourself, does JS crypto provide any security beyond what SSL does? And, can JS crypto make sense as part of a defense in depth/layered security approach?

Re: Cryptography in the Browser

#15

Post by jxson »

rosser wrote: post #3

The Chicken-Egg problem is Problem 0 with Javascript crypto. Until you can solve that, everything else is just farting into the wind.

Progressive enhancement is a real thing and as the browsers start to implement native support for the rest of Web Cryptography API the situation will only improve. We have to start somewhere.

Re: Cryptography in the Browser

#16

Post by wmf »

jxson wrote: post #15
rosser wrote: post #3

The Chicken-Egg problem is Problem 0 with Javascript crypto. Until you can solve that, everything else is just farting into the wind.

Progressive enhancement is a real thing and as the browsers start to implement native support for the rest of Web Cryptography API the situation will only improve. We have to start somewhere.

Assuming that browsers have implemented Web Crypto, how do you know you're using it and not an evil polyfill?

Re: Cryptography in the Browser

#17

Post by taway2012 »

moxie wrote: post #2

Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…

Hi moxie! First off, I agree with what you said. But I had a question about your observation.

Don't the same problems apply to any autoupdating system (including smartphones, tablets and computers)?

I've posted once before asking that Chrome and Firefox implement certificate pinning APIs for extensions/addons so that MITM SSL attacks can be detected. Maybe they'll see it now. :)

Re: Cryptography in the Browser

#18

Post by foobarqux »

Compiling nacl to javascript is probably a very bad idea without some further analysis. There are almost certainly specialized code constructs that will be lost in the transformation, like branchless code paths, that are designed to prevent certain types of attacks.

In fact this is a pretty insidious mistake since you think you are doing the right thing by using a high-quality library.

Re: Cryptography in the Browser

#19

Post by ww520 »

moxie wrote: post #2

Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…

Client side Javascript cryptography is about equivalent to SSL; however, it doesn't mean it's not worthwhile to do crypto on the client side. At least the computation load is distributed to all the browsers involved, thus lessen the demand and load on the server.

Re: Cryptography in the Browser

#20

Post by bmm6o »

rosser wrote: post #11
notwhyships wrote: post #6

Earlier quoted context omitted.

This is a deck by Ben Adida (formerly of Mozilla, where he led the Persona project and now at Square) explaining how that argument is reductionistic. https://docs.google.com/presentation/d/1bLBb0EIJ0cuoAhsmI1XL...

Can you please help me find even an argument in that deck, let alone any refutation ? Did I get an incomplete deck, perhaps? The version I'm seeing stops at slide 22.

He's presumably referring to slides 17-20. It essentially boils down to "JS crypto in the browser is better than nothing".
Post reply on HN