5 ms·

Browser crypto has come a long way. With libraries like libsodium and proper implementation I think it’s drastically better than at the time of those articles

Browser crypto has come a long way. With libraries like libsodium and proper implementation I think it’s drastically better than at the time of those articles (2013 and 2011). Source: we also write encryption libraries and have a free implementation of our browser sdk at https://share.labs.tozny.com https://share.labs.tozny.com

tptacek 7y ago
No, it's not drastically better than it was in 2013. People have done lots of things with browser cryptography, that's true. But none of what they've done addresses or mitigates the central flaw of browser javascript cryptography, which is that to use it, you have to continuously and durably trust the server. If you're doing that, you might as well just do the cryptography serverside.
- espadrine 7y ago
  My understanding of FileKit is that you do trust the Tanker server, but only for delivering JS and handling identities. It only contains public keys and encrypted DEKs (data encryption keys); see this image: https://docs.tanker.io/filekit/latest/going-further/file-encryption.png https://docs.tanker.io/filekit/latest/going-further/file-enc... The file content should therefore only be accessible by holders of private keys for which the file was encrypted.
  - tptacek 7y ago
    There's no difference between trusting the server to deliver Javascript cryptography source code and trusting the server with your secrets. The server can just deliver code (in a number of different ways) to compromise those secrets.
    - danShumway 7y ago
      Well... there's no technical difference. My understanding from the Apple/FBI fiasco is that it's an open question whether the US government is legally able to compel you to write and deliver custom code to your clients. But any local judge can issue you a warrant to hand over encrypted customer data that you're holding the key to. But IANAL, maybe my take on that is overly simplistic.
  - blastrock 7y ago
    Actually, Filekit is meant to be integrated into an application, and that application is responsible for delivering JS and handling identities, not the Tanker server.
- devoply 7y ago
  I wonder why browsers don't build their own browser api for file and mail crypto ... and that way you don't have to trust the server. And you can verify that the server is using browser crypto.
  - adamredwoods 7y ago
    I wonder if we'd even need the server at any capacity for encryption by that point.
- dboreham 7y ago
  Wondering...browsers do seem to be able to do secure crypto in two existing scenarios: when presenting a client TLS certificate; and when performing authentication via WebAuthn in conjunction with U2F. Would it be possible to re-purpose either of those mechanisms to do other potentially useful secure crypto (e.g. sign blockchain transactions)?
- tzs 7y ago
  The issue of having to trust the server also applies in a lot of non-browser cases. For example, I have to trust the 1Password update server, or forego 1Password updates. It looks like the issues with browser-based cryptography from those two articles fall into three broad groups. 1. You have to trust the server. 2. The browsers don't do a good job of letting a site's JavaScript keep things secret from other things running in the browser. 3. If you implement cryptography in JavaScript, you are probably going to screw it up. There's a lot more to doing it right than just knowing to use AES and whatever the currently favored hash function is. #1 is probably acceptable in a lot of cases, and #3 can probably be addressed by using the Webassembly version of libsodium.That leaves #2 as the apparently insurmountable issue. Suppose the user was willing to create a separate Firefox or Chrome profile just for using my web-based app, and did not install any browser plug-ins under that profile, set its home page to my app page, and never used that profile to visit any other sites. How close would that come to dealing with #2?
  - goliatone 7y ago
    Re #2 There’s this [1] tc39 proposal. You could also hack a solution using dynamic method names and Symbols. [1] https://github.com/tc39/proposal-private-methods/blob/master/README.md https://github.com/tc39/proposal-private-methods/blob/master...
    - csande17 7y ago
      I don't think the private methods proposal will help with cryptography at all. The "security" it provides boils down to making it difficult for code outside the class to access the value, like you can already do with closures like this: function makeCounter() { var x = 0; return function() { return ++x; }; } It doesn't help at all with side-channel attacks, which are the main reason why it's hard to safely perform cryptographic operations in a just-in-time interpreted language like JavaScript. It also doesn't stop rogue scripts on the same page from pulling the user's passwords/keys right out of the password field, URL bar, localStorage, or wherever else your script gets them from.
  - pvg 7y ago
- javajosh 7y ago
  the central flaw of browser javascript cryptography, which is that to use it, you have to continuously and durably trust the server What do you think of doing JavaScript Crypto in a browser extension? An extension runs code in the browser without persistent trust of a server (at least in the traditional webapp way; you have to persistently trust the extension update server, extension authors, chrome update server, etc). You could do things like quickly, interactively encrypt chunks of text with a symmetric key. Presumably you'd use an extension UI to enter your keys, to avoid keylogging. I think it would be illuminating to have a small suite of well-implemented cryptographic primitives, curated by a well-known expert, installed and ready to use on any string in the browser. (BTW why don't we see more random chunks of cyphertext everywhere? It would seem to me a good channel, to use a combination of public forums to transfer short bursts of cyphertext. Where are the encrypted Twitter broadcasts??)
  - tptacek 7y ago
    I don't love browser extensions but the trust model issues with it are not identical to content-controlled Javascript.
    - tipiak 7y ago
      The issue with browser extensions, is that you are not far away from the common hurdles of developing, using and releasing a "real" desktop/mobile application. Having nothing to install and landing on a page that just works, is a big plus for you users.
- dane-pgp 7y ago
  Interestingly, the technology of Signed HTTP Exchanges could potentially be used as the basis for a system that removes the need to trust the server. The current Internet-Draft even includes a section on the Binary Transparency use case: https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.appendix.A.4 https://wicg.github.io/webpackage/draft-yasskin-http-origin-... What's still missing, I think, is a way for a publisher to tell a browser "Only run new code from this domain after checking that the user is happy to upgrade". That would put the "web app" on roughly the same security footing as a desktop application with a built-in update system.
- chatmasta 7y ago
  I don't see how you have to trust the server unless it's also serving the client bundle. There are many decentralized use cases where you might "bring your own client" (or maybe one trusted server gives it to you) and use the client to interact with other untrusted servers. You can have a trusted client and an untrusted server.

tptacek 7y ago

No, it's not drastically better than it was in 2013. People have done lots of things with browser cryptography, that's true. But none of what they've done addresses or mitigates the central flaw of browser javascript cryptography, which is that to use it, you have to continuously and durably trust the server. If you're doing that, you might as well just do the cryptography serverside.

espadrine 7y ago
My understanding of FileKit is that you do trust the Tanker server, but only for delivering JS and handling identities. It only contains public keys and encrypted DEKs (data encryption keys); see this image: https://docs.tanker.io/filekit/latest/going-further/file-encryption.png https://docs.tanker.io/filekit/latest/going-further/file-enc... The file content should therefore only be accessible by holders of private keys for which the file was encrypted.
- tptacek 7y ago
  There's no difference between trusting the server to deliver Javascript cryptography source code and trusting the server with your secrets. The server can just deliver code (in a number of different ways) to compromise those secrets.
  - danShumway 7y ago
    Well... there's no technical difference. My understanding from the Apple/FBI fiasco is that it's an open question whether the US government is legally able to compel you to write and deliver custom code to your clients. But any local judge can issue you a warrant to hand over encrypted customer data that you're holding the key to. But IANAL, maybe my take on that is overly simplistic.
- blastrock 7y ago
  Actually, Filekit is meant to be integrated into an application, and that application is responsible for delivering JS and handling identities, not the Tanker server.
devoply 7y ago
I wonder why browsers don't build their own browser api for file and mail crypto ... and that way you don't have to trust the server. And you can verify that the server is using browser crypto.
- adamredwoods 7y ago
  I wonder if we'd even need the server at any capacity for encryption by that point.
dboreham 7y ago
Wondering...browsers do seem to be able to do secure crypto in two existing scenarios: when presenting a client TLS certificate; and when performing authentication via WebAuthn in conjunction with U2F. Would it be possible to re-purpose either of those mechanisms to do other potentially useful secure crypto (e.g. sign blockchain transactions)?
tzs 7y ago
The issue of having to trust the server also applies in a lot of non-browser cases. For example, I have to trust the 1Password update server, or forego 1Password updates. It looks like the issues with browser-based cryptography from those two articles fall into three broad groups. 1. You have to trust the server. 2. The browsers don't do a good job of letting a site's JavaScript keep things secret from other things running in the browser. 3. If you implement cryptography in JavaScript, you are probably going to screw it up. There's a lot more to doing it right than just knowing to use AES and whatever the currently favored hash function is. #1 is probably acceptable in a lot of cases, and #3 can probably be addressed by using the Webassembly version of libsodium.That leaves #2 as the apparently insurmountable issue. Suppose the user was willing to create a separate Firefox or Chrome profile just for using my web-based app, and did not install any browser plug-ins under that profile, set its home page to my app page, and never used that profile to visit any other sites. How close would that come to dealing with #2?
- goliatone 7y ago
  Re #2 There’s this [1] tc39 proposal. You could also hack a solution using dynamic method names and Symbols. [1] https://github.com/tc39/proposal-private-methods/blob/master/README.md https://github.com/tc39/proposal-private-methods/blob/master...
  - csande17 7y ago
    I don't think the private methods proposal will help with cryptography at all. The "security" it provides boils down to making it difficult for code outside the class to access the value, like you can already do with closures like this: function makeCounter() { var x = 0; return function() { return ++x; }; } It doesn't help at all with side-channel attacks, which are the main reason why it's hard to safely perform cryptographic operations in a just-in-time interpreted language like JavaScript. It also doesn't stop rogue scripts on the same page from pulling the user's passwords/keys right out of the password field, URL bar, localStorage, or wherever else your script gets them from.
- pvg 7y ago
javajosh 7y ago
the central flaw of browser javascript cryptography, which is that to use it, you have to continuously and durably trust the server What do you think of doing JavaScript Crypto in a browser extension? An extension runs code in the browser without persistent trust of a server (at least in the traditional webapp way; you have to persistently trust the extension update server, extension authors, chrome update server, etc). You could do things like quickly, interactively encrypt chunks of text with a symmetric key. Presumably you'd use an extension UI to enter your keys, to avoid keylogging. I think it would be illuminating to have a small suite of well-implemented cryptographic primitives, curated by a well-known expert, installed and ready to use on any string in the browser. (BTW why don't we see more random chunks of cyphertext everywhere? It would seem to me a good channel, to use a combination of public forums to transfer short bursts of cyphertext. Where are the encrypted Twitter broadcasts??)
- tptacek 7y ago
  I don't love browser extensions but the trust model issues with it are not identical to content-controlled Javascript.
  - tipiak 7y ago
    The issue with browser extensions, is that you are not far away from the common hurdles of developing, using and releasing a "real" desktop/mobile application. Having nothing to install and landing on a page that just works, is a big plus for you users.
dane-pgp 7y ago
Interestingly, the technology of Signed HTTP Exchanges could potentially be used as the basis for a system that removes the need to trust the server. The current Internet-Draft even includes a section on the Binary Transparency use case: https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.appendix.A.4 https://wicg.github.io/webpackage/draft-yasskin-http-origin-... What's still missing, I think, is a way for a publisher to tell a browser "Only run new code from this domain after checking that the user is happy to upgrade". That would put the "web app" on roughly the same security footing as a desktop application with a built-in update system.
chatmasta 7y ago
I don't see how you have to trust the server unless it's also serving the client bundle. There are many decentralized use cases where you might "bring your own client" (or maybe one trusted server gives it to you) and use the client to interact with other untrusted servers. You can have a trusted client and an untrusted server.