Hacker News Reader

Comment by fouadmatin | Hacker News Reader

SubtleCrypto is a new browser-adopted spec for performing crypto operations natively. For example, instead of using Math.random() for random number generation, you can use https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getR... in combination with the SubtleCrypto functions to work with keys securely

Your points around a compromised JS bundle are still possible but that has more to do with a company’s deployment/change management setup than JS itself imo

View on HN

> Your points around a compromised JS bundle are still possible but that has more to do with a company’s deployment/change management setup than JS itself imo

But that's the only point I intend to address here. If Pascal had been the language of the web then my question would have been about Pascal.

Therefore I don't see how SubtleCrypto changes matters much.

In short, if I get it right, the argument would be that in eg a mobile app, all the e2e logic (the core crypto plus the code around it) go through peer-review, then some release management process, then some review by Apple or Google, before it lands in my hands via their app stores' well secured delivery mechanism. In a web app, a single compromised server will compromise all security instantly. Generally I'm fine with trusting Mozilla's servers, but if I have to trust their servers then what's the point of end to end encryption?

> In a web app, a single compromised server will compromise all security instantly.

This is only true if the server has access to the keys of your data. E2EE typically means that it doesn't, only you do.

In a browser, the server serving the JS has an opportunity to access the keys.

subtlecrypto has API to generate a keypair that you can't extract and access from the JS side. You can only use it to encrypt/decrypt buffers, but not access the key itself.

Sure, but having access to encryption/decryption/key derivation is pretty much equivalent to having the key in most circumstances. Plus, JS generates the key and sets "extractable" flag.

This is the case with all E2EE tools. You have to trust that they do their crypto correct and that they aren't evil. As Firefox Send is open source you can setup your own server if you don't trust Mozilla, but then again, if you don't trust Mozilla you might want to eyeball their code carefully first...

Your description is very simplistic, but yes, you have to trust the code that's delivered to you. For example, no Android/iOS user would check every single update to E2EE apps they install for backdoors. However with web, there's an opportunity for a backdoor in every single request and the server can ship different code to different users. In my opinion, using web cryptography is still worth it, but it's definitely more risky than native apps.

And how does that work with Firefox Send? Isn't the key somehow in the payload or the URL?

Without knowing almost anything about Firefox Send, it does seem that the key is embedded in the link you give to your friends. In that case E2E means that the key is not stored on the server. In order to guarantee that, the link is probably in two parts, one that identifies the file on the server and one is the key. The key part of the link is probably generated on your machine and thus never sent to the server (to prevent it being in any logs or what not). So if Mozilla's servers are compromised the attacker still would not be able to decrypt your files. Of course if the server is compromised the attacker could serve up malicious JS for future uploads.

If it works, it prevents mass surveillance and makes insider attacks much more difficult.

Didn't realize it had full support by every browser, even ie: https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getR...

The SubtleCrypto portion of the API is slightly less supported in that it appears to have spotty/non-compliant IE and Edge coverage.[1]

1: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...

The problem with that table is that this only lists the entry methods, which are supported in all browsers. However, the actual work is hidden behind parameters, not all of which are supported by all browsers, and some have to be in weird combinations. One example is that Edge does not support PBKDF2 in any form, which makes many of their further support a bit weird to use.

Here's a site where you can test your browser's compatibility with many combinations: https://diafygi.github.io/webcrypto-examples/

I think it uses a cryptofill shim for browsers that don't support all of the crypto api

Reply on news.ycombinator.com