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

41–50 of 85 posts

Re: Cryptography in the Browser

#41

Post by moxie »

nlacasse wrote: post #33
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…

Thanks for the reply. Opal requires as little trust as possible, but you are correct that some server-trust is required at the moment. I hope that apps like Opal will encourage more progress on browser/javascript cryptography. The W3C crypto spec is coming along nicely, and things like Content Security Policy address some of the concerns about delivering secure javascript. One nice thing about web-apps is that they a…

> Opal requires as little trust as possible, but you are correct that some server-trust is required at the moment.

Unless there is some other mechanism at play here, it requires full server trust.

> I hope that apps like Opal will encourage more progress on browser/javascript cryptography. The W3C crypto spec is coming along nicely, and things like Content Security Policy address some of the concerns about delivering secure javascript.

I don't think you can just cross your fingers and hope for the best here. Whether or not it's coming along nicely is debatable, but one way or another the W3C crypto API has no bearing at all on this problem.

You're talking about implementing a "secure" service using a mechanism that is known to be insecure. For a mechanism like this to function correctly, it would likely require substantial changes to the way the web browser works that aren't currently on anyone's roadmap.

Again, this is not a theoretical problem. Two companies have done the exact same handwaving that you are doing now about users watching tcpdump to verify their traffic, and both of them were functionally destroyed when that handwaving didn't work. It doesn't seem prudent to knowingly put users (or yourselves!) into that position again.

Re: Cryptography in the Browser

#42

Post by tptacek »

nlacasse wrote: post #24
foobarqux wrote: post #18

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.

Emscripten compiles the input source with LLVM, then converts the LLVM bytecode to JS. Most of the optimization passes are done by the LLVM compiler. Are you suggesting that LLVM (or optimizing compilers in general) should not be used to compile crypto libraries? I completely agree that further analysis is needed on js-nacl, but I hadn't considered that compiler optimizations might lead to vulnerabilities.

That's might be a sign you don't pay enough attention cryptographic research; compiler optimization side channels are not news.

Of course, the notion that the compiler is a threat here is getting a bit ahead of ourselves, because you don't even know what side channels are in the runtime.

Re: Cryptography in the Browser

#43

Post by nlacasse »

pcwalton wrote: post #30
_prometheus wrote: post #26

Earlier quoted context omitted.

Or, could use pepper.js. http://trypepperjs.appspot.com/ https://github.com/google/pepper.js (note the `google` in the link).

Different NaCl. djb's NaCl is a crypto library. Google's NaCl is a "native code in the browser" component of Chrome/Chromium. It's terribly confusing, especially since this article talks about both :)

What's worse is that djb's crypto NaCl wants to be pronounced "salt".

Re: Cryptography in the Browser

#44

Post by foobarqux »

nlacasse wrote: post #24
foobarqux wrote: post #18

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.

Emscripten compiles the input source with LLVM, then converts the LLVM bytecode to JS. Most of the optimization passes are done by the LLVM compiler. Are you suggesting that LLVM (or optimizing compilers in general) should not be used to compile crypto libraries? I completely agree that further analysis is needed on js-nacl, but I hadn't considered that compiler optimizations might lead to vulnerabilities.

My primary concern is the LLVM bytecode to JS transformation.

Even on the LLVM side certain optimizations may be dangerous in crypto code. I wouldn't play with optimization settings unless I was sure I knew what I was doing. And I'd still think twice.

Re: Cryptography in the Browser

#45

Post by tptacek »

nlacasse wrote: post #35
nwh wrote: post #31

Earlier quoted context omitted.

It always comes down to this; would you prefer security, or just something that makes you feel fuzzy? Crypto in JavaScript only gives the latter.

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!

Re: Cryptography in the Browser

#46

Post by tptacek »

tinco wrote: post #13

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…

Part of the problem is that the JS crypto article they linked to isn't very good, but has for some reason become emblematic of the whole argument against JS crypto. It deserves an update.

Re: Cryptography in the Browser

#47

Post by tptacek »

Jach wrote: post #28
Judson wrote: post #5

Earlier quoted context omitted.

I have seen people point to using plugins to verify assets delivered by the server, but at that point, why not just do the crypto with the plugin.

The benefit of a plugin to verify assets is that it can work with other things besides the crypto lib. As your sibling comment mentions an attacker could deliver other JS that just traces your input or something different. Well, a user could ask a plugin to say "Hey, track the JS on this page. Alert me if any of it changes, any of it is removed, or any new JS is added." After an alert, the user can see a diff, decide…

How exactly do you use a plugin to verify the state of a Javascript runtime? You can't just verify assets; you need to verify the current bindings of every function relevant to your crypto code.

Re: Cryptography in the Browser

#48

Post by tptacek »

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.

Re: Cryptography in the Browser

#49

Post by blazingice »

wmf wrote: post #16
jxson wrote: post #15

Earlier quoted context omitted.

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?

Some JS engines already disallow security-violating operations from happening (such as inserting evil hooks into document.location). These same protections could apply to any Crypto object.

Re: Cryptography in the Browser

#50

Post by azakai »

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!

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