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

51–60 of 85 posts

Re: Cryptography in the Browser

#51

Post by DanBC »

derefr wrote: post #12
DanBC wrote: post #10

Earlier quoted context omitted.

> 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 statis…

But this is why risk assessment is part of choosing and using crypto.

If you think the NSA is after you then all bets are off and whatever you're doing is probably not working because most people don't have an armoured bunker with armed guards. We need to be careful to differentiate between active NSA snooping (in which case anything we do is probably weak) and passive snooping (where we just want to make it expensive enough for them to not bother with our communications).

But if you think the FBI is after you then you'll want to avoid something that can be done by a court order - such as your encrypted email provider being forced to serve you a malformed client that allows law enforcement to view all your communications. This is a real risk, and is what happened to Hushmail.

Re: Cryptography in the Browser

#52

Post by ww520 »

tptacek wrote: post #22
ww520 wrote: post #19

Earlier quoted context omitted.

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.

You can't securely load crypto into a browser without SSL, so the server is bearing that load anyways. All you're doing is adding additional load on the clients.

Given a client side crypto implementation with SSL as the delivery mechanism, the only load on the server is the content delivery and the SSL computation itself. Any of the application-specific crypto load can be done on the browser instead on the server.

Let's say the app is encrypting 1meg Excel file and 100K people are using it. I would rather letting the browsers do the work than beef up the servers to do the encryption on server side.

Re: Cryptography in the Browser

#53

Post by DanBC »

azakai wrote: post #50
tptacek wrote: post #45

Earlier quoted context omitted.

This is like saying a sign that says "attackers keep out" provides real security, as long as you keep in mind that it only works if attackers obey the sign. After all, Dropbox doesn't have an "attackers keep out" sign!

No, it's more like an imperfect lock is still more security than no lock at all on your door.

No, it's more like people thinking they have a high grade lock on their door, when in fact they have a broken lock. They can't see it's broken, but anyone who knows about locks knows it's broken, and how to bypass it with a bobby pin.

Re: Cryptography in the Browser

#54

Post by Spooky23 »

tptacek wrote: post #45
nlacasse wrote: post #35

Earlier quoted context omitted.

I disagree. Javascript cryptography can provide real security, it's just important to keep in mind what is being secured, and where the vulnerabilities are. Currently, js crypto is vulnerable in that its difficult to verify that the js a browser is running is the intented code. Every day, millions of people are sending sensitive data over very insecure channels like email and DropBox because secure tools like PGP are…

This is like saying a sign that says "attackers keep out" provides real security, as long as you keep in mind that it only works if attackers obey the sign. After all, Dropbox doesn't have an "attackers keep out" sign!

It is a little better than that. What about an enterprise application where you have control/trust of the server, but want to securely cache data in offline browser storage.

That covers common scenarios, like people who provide web based access to Microsoft Exchange.

Re: Cryptography in the Browser

#55

Post by eliteraspberrie »

Moreover, the LLVM compiler can perform many optimizations during compilation, so the resulting JavaScript is highly optimized.

Optimization may actually be an argument against C-to-Javascript translated cryptography.

NaCl was written in C, according to the constraints and degrees of freedom of a standard C compiler -- which are not the same as those of an interpreted or JiT compiled language.

I am not a cryptographer, but source-to-source translation of cryptography is looking for trouble.

Re: Cryptography in the Browser

#56

Post by derefr »

lmm wrote: post #36
derefr wrote: post #12

Earlier quoted context omitted.

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 statis…

If you're running a decent linux you can turn auto-update off. No browser will let you do that.

All the portable-app versions of Chrome and Firefox (for example, the Firefox that comes with the Tor bundle) have auto-update disabled, for both the browser, and included extensions.

Re: Cryptography in the Browser

#57

Post by automatthew »

tptacek wrote: post #48
peterwwillis wrote: post #38

All browsers already have crypto. Why the fuck are people trying to invent their own when it's built in? http://en.wikipedia.org/wiki/Network_Security_Services https://developer.mozilla.org/en-US/docs/Mozilla_Crypto_FAQ All you need is some kind of new "Web Standard" glue between the browser and the JS and do whatever you feel like using the native crypto functionality of the browser. You don't need to add more layer…

How exactly do you think having built-in AES primitives solves a problem for browser crypto? Content-controlled Javascript still controls how those primitives are used.

The problem isn't only with primitives, as I think you've mentioned before. Even assuming a browser provides turnkey symmetric crypto for arbitrary plaintext lengths, "content-controlled JavaScript" can still subvert the ostensible encryptions in subtle ways.

Re: Cryptography in the Browser

#58

Post by eldondev »

DanBC wrote: post #53
azakai wrote: post #50

Earlier quoted context omitted.

No, it's more like an imperfect lock is still more security than no lock at all on your door.

No, it's more like people thinking they have a high grade lock on their door, when in fact they have a broken lock. They can't see it's broken, but anyone who knows about locks knows it's broken, and how to bypass it with a bobby pin.

Is this supposed to be serious, because we want javascript to be better, or sarcastic, because most people DO live behind locks that are broken and can be bypassed trivially with relatively unsophisticated tools? Everybody break out your bobby pins!

Re: Cryptography in the Browser

#59

Post by elithrar »

jerrya wrote: post #37
tinco wrote: post #32

Earlier quoted context omitted.

Please note the implications of this. The signed javascript would have to be hosted on a separate third party website, and it would have to be the _only_ script content of the website. Since code can be executed by almost every resource on a webpage, basically the entire would have to be stored on that separate third party website, the html, the css, maybe throw in the images too given their history of weird exploits…

And yet, jsquery works that way, doesn't it? Everyone pulls jsquery in from basically one site... Does the entire website have to be on that separate third party location, or just a self-booting kernel of crypto to enable a signed website to be downloaded from the desired source?

> And yet, jsquery works that way, doesn't it? Everyone pulls jsquery in from basically one site...

Not everyone (not even close). Many do, but if I'm running a site over SSL I'm going to be hosting my own copy of the jQuery libs.

Re: Cryptography in the Browser

#60

Post by nwh »

eldondev wrote: post #58
DanBC wrote: post #53

Earlier quoted context omitted.

No, it's more like people thinking they have a high grade lock on their door, when in fact they have a broken lock. They can't see it's broken, but anyone who knows about locks knows it's broken, and how to bypass it with a bobby pin.

Is this supposed to be serious, because we want javascript to be better, or sarcastic, because most people DO live behind locks that are broken and can be bypassed trivially with relatively unsophisticated tools? Everybody break out your bobby pins!

You would have extreme trouble picking a lock with a bobby pin, they're much too fat to do anything outside of a movie.
Post reply on HN