6 ms·

Why can't browsers just build crypto primitives in that can be called from js? I don't understand what people's obsession with browser crypto is...but I don't

by theboss 12y ago

Why can't browsers just build crypto primitives in that can be called from js? I don't understand what people's obsession with browser crypto is...but I don't know enough about browser's to think of a reason this solution is bad. Any guidance? edit: I understand that this won't solve all the problems...but at least the problem that you are constantly being served this chunk of potentially unsafe code. edit2: I've been doing some thinking. Even though I didn't really get a response I think the reason is that it doesn't buy you the ability to do anything new safely. You still have the old problems of other dom elements mucking with your dom elements that control the code, or whatever the site does...so it doesn't really buy you anything...it's just work for nothing. I still think it would be a useful start to one day having safe browser crypto

IgorPartola 12y ago
It is a long story and has been discussed one million times on here at least. Google the answer or just trust that crypto in JS cannot be not because the implementation is hard but because it is not possible in principle.
- theboss 12y ago
  I'm only talking about solving this 1 problem related to js crypto...
cynwoody 12y ago
The problem with browser crypto is that code is downloaded from the server ... nothing to install, so convenient. Right? The danger is that you are back to trusting the server. If they are compromised, you could get served special crypto code that uploads your private pass phrase the next time you log in. The crypto code needs to come from a trusted third party, and the protocol with the server must be dead simple and strictly arms-length, with no logic of any sort downloaded from the server. More like FTP than HTTP/HTML/JS.
- theboss 12y ago
  There are a ton of other problems associated with crypto code. I'm talking about crypto primitives being provided by the browser. The rest of the problems associated with it, I'm not asking about. You're echoing the problem that my question is asking if it solves... Edit: Also, you definitely need more than the code to come from a "trusted third party", otherwise we would see SaaS startups on HN providing "crypto as a service" (god help us).
IgorPartola 12y ago
Since you insist on a longer explanation, here goes: You can have crypto primitives in the browser: AES, RSA, ECDSA, etc. So given a private key and cyphertext you can decrypt it and given a public key and a piece of cyphertext you can encrypt it. The actual crypto code is just a callout to libssl. In this regard, you can do this right now: simply wrap libssl from within Chrome's JS engine and you are done. Now what? What can you actually do with this stuff? Well, you could create an email client: one that downloads a message over XHR and decrypts it. That's great, except the code to run this app is unsigned and downloaded from a remote server! I can pwn the server, add my own code that will backdoor the app and send me your private key as soon as it's in memory. "BUT!" you say. "I can sign the code!". I say to that, how will you verify that signature? By downloading the piece of code from a remote server? I'll just pwn the server and add my own code to accept my signatures, then add the code to send me your private key. "BUT!" you say. "I can have the signature verification code built into the browser. Look ma, no remote code download that's not signed!" I say to that, how do you know that the developer was not forced by the NSA or another powerful adversary to give up their private key or just coerced into created a backdoored package to own you specifically? You don't. You didn't grab the source and compile it. Instead, you downloaded and ran a code blob. The solution to all of this already exists and it does not involve the web. It's called package management. Your distro already does this: multiple people review the source code that goes into every package and every step of the way is cryptographically signed. The binaries are built on trusted machines and distributed with yet more signatures. There is peer review through and through. Compare this to a closed-source web application you are trying to secure. In this case the best you can do is say "if you trust me (the developer), and you trust that I know what I'm doing so my servers don't get pwn'ed, and you trust that I have not been coerced by the NSA/other gov't agency, then you can trust this code". Except, you don't need client-side crypto for that. You already have HTTPS which provides the same guarantee without re-inventing a square wheel. QED.
- theboss 12y ago
  Funny. I typed up my edit2, hit enter, and had a reply from you basically saying the same thing. Also, I never said anything about use-cases, signing code, etc. Only "does this safely get you the primitives", not about what you can do with them. The "you say" in your explanation are not what I said.
rdl 12y ago
I agree we need to move toward being able to build secure client apps in the browser. It's clearly "important", in that a lot of people want it, for meaningful and good reasons, and this is likely to continue. It's just not possible today. Signed extensions are a decent step today (although installing an extension is potentially about as heavy as installing a client app, depending on how locked down your environment is). CSP and some future extensions can be helpful. There's server-side stuff which can help, too. WebCrypto is a useful step. The problem is it's going to be a long process involving a lot of parts, controlled by different parties. So it's responsible to say "we're going to build a webapp which is as secure as we can make it today; these are the known vulnerabilities". Some users are in a good position to evaluate the risks, others aren't. I care a lot more about things doing what they say they're doing than what in particular they say they're doing. The scary thing is when the people building something don't seem to know the well-known vulnerabilities.

by theboss 12y ago

IgorPartola 12y ago

It is a long story and has been discussed one million times on here at least. Google the answer or just trust that crypto in JS cannot be not because the implementation is hard but because it is not possible in principle.

theboss 12y ago
I'm only talking about solving this 1 problem related to js crypto...

cynwoody 12y ago

The problem with browser crypto is that code is downloaded from the server ... nothing to install, so convenient. Right? The danger is that you are back to trusting the server. If they are compromised, you could get served special crypto code that uploads your private pass phrase the next time you log in. The crypto code needs to come from a trusted third party, and the protocol with the server must be dead simple and strictly arms-length, with no logic of any sort downloaded from the server. More like FTP than HTTP/HTML/JS.

theboss 12y ago
There are a ton of other problems associated with crypto code. I'm talking about crypto primitives being provided by the browser. The rest of the problems associated with it, I'm not asking about. You're echoing the problem that my question is asking if it solves... Edit: Also, you definitely need more than the code to come from a "trusted third party", otherwise we would see SaaS startups on HN providing "crypto as a service" (god help us).

IgorPartola 12y ago

Since you insist on a longer explanation, here goes: You can have crypto primitives in the browser: AES, RSA, ECDSA, etc. So given a private key and cyphertext you can decrypt it and given a public key and a piece of cyphertext you can encrypt it. The actual crypto code is just a callout to libssl. In this regard, you can do this right now: simply wrap libssl from within Chrome's JS engine and you are done. Now what? What can you actually do with this stuff? Well, you could create an email client: one that downloads a message over XHR and decrypts it. That's great, except the code to run this app is unsigned and downloaded from a remote server! I can pwn the server, add my own code that will backdoor the app and send me your private key as soon as it's in memory. "BUT!" you say. "I can sign the code!". I say to that, how will you verify that signature? By downloading the piece of code from a remote server? I'll just pwn the server and add my own code to accept my signatures, then add the code to send me your private key. "BUT!" you say. "I can have the signature verification code built into the browser. Look ma, no remote code download that's not signed!" I say to that, how do you know that the developer was not forced by the NSA or another powerful adversary to give up their private key or just coerced into created a backdoored package to own you specifically? You don't. You didn't grab the source and compile it. Instead, you downloaded and ran a code blob. The solution to all of this already exists and it does not involve the web. It's called package management. Your distro already does this: multiple people review the source code that goes into every package and every step of the way is cryptographically signed. The binaries are built on trusted machines and distributed with yet more signatures. There is peer review through and through. Compare this to a closed-source web application you are trying to secure. In this case the best you can do is say "if you trust me (the developer), and you trust that I know what I'm doing so my servers don't get pwn'ed, and you trust that I have not been coerced by the NSA/other gov't agency, then you can trust this code". Except, you don't need client-side crypto for that. You already have HTTPS which provides the same guarantee without re-inventing a square wheel. QED.

theboss 12y ago
Funny. I typed up my edit2, hit enter, and had a reply from you basically saying the same thing. Also, I never said anything about use-cases, signing code, etc. Only "does this safely get you the primitives", not about what you can do with them. The "you say" in your explanation are not what I said.

rdl 12y ago

I agree we need to move toward being able to build secure client apps in the browser. It's clearly "important", in that a lot of people want it, for meaningful and good reasons, and this is likely to continue. It's just not possible today. Signed extensions are a decent step today (although installing an extension is potentially about as heavy as installing a client app, depending on how locked down your environment is). CSP and some future extensions can be helpful. There's server-side stuff which can help, too. WebCrypto is a useful step. The problem is it's going to be a long process involving a lot of parts, controlled by different parties. So it's responsible to say "we're going to build a webapp which is as secure as we can make it today; these are the known vulnerabilities". Some users are in a good position to evaluate the risks, others aren't. I care a lot more about things doing what they say they're doing than what in particular they say they're doing. The scary thing is when the people building something don't seem to know the well-known vulnerabilities.