Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

End-to-end encryption in the browser

blog.excalidraw.com

Post reply on HN
Print view View original

101–110 of 112 posts

Re: End-to-end encryption in the browser

#101

Post by dchest »

vbezhenar wrote: post #92
dchest wrote: post #81

Earlier quoted context omitted.

It's a good idea if you encrypt with the same key _once_ — you can avoid attaching nonces to your ciphertext (less code and data), and have only 16-byte key in the URL. In fact, using a random IV with AES-GCM is not exactly safe: 12-byte nonce is too small to avoid collisions with many encryptions. The recommendation is to not encrypt more than 2^32 messages with the same key if you use the random nonce.

What would happen if an attacker gets two different messages with identical IV and key?

They'll get the XOR of the two original messages, and also can break authentication: https://crypto.stackexchange.com/questions/26790/how-bad-it-...

Re: End-to-end encryption in the browser

#102

Post by _bxg1 »

vbezhenar wrote: post #86
_bxg1 wrote: post #47

Earlier quoted context omitted.

Others have said it's open-source. Build it yourself, inspect what your browser downloads, hash and compare like normal.

How do you hash your browser downloads? Also you need to perform that on every request. It should be possible with additional addons, but definitely not out of the box.

You can easily open the dev tools, view the payloads, and copy them locally. It would be trickier to prevent evaluation before you've done so, but all you have to do is not enter anything sensitive until you've checked

Re: End-to-end encryption in the browser

#103

Post by vbezhenar »

dchest wrote: post #101
vbezhenar wrote: post #92

Earlier quoted context omitted.

What would happen if an attacker gets two different messages with identical IV and key?

They'll get the XOR of the two original messages, and also can break authentication: https://crypto.stackexchange.com/questions/26790/how-bad-it-...

That's scary, thanks!

Re: End-to-end encryption in the browser

#105

Post by [deleted] »

inetknght wrote: post #84
henriquez wrote: post #33

Earlier quoted context omitted.

Why? It makes it easy to share a sketch with someone else while still preventing the server from decrypting the data. Anything stored in a location hash (after the # symbol) does not get passed to the server. The threat model the author tried to work around is not the user dumbly compromising their own work. The author wants to prevent proprietary and PII data from being stored on their own server. End-to-end encrypt…

> Why? It makes it easy to share a sketch with someone else while still preventing the server from decrypting the data. Anything stored in a location hash (after the # symbol) does not get passed to the server. I'll hit the URL bar and hit control-C. That's way better than any javashit which wants to touch my clipboard. Copying the current URL also copies the key in that case. Now I'm accidentally sharing my encrypti…

[deleted]

Re: End-to-end encryption in the browser

#106

Post by lioeters »

dchest wrote: post #80
lioeters wrote: post #77

Earlier quoted context omitted.

> I think you're just initializing a bunch of null bytes. You're right. From MDN: > The Uint8Array typed array represents an array of 8-bit unsigned integers. The contents are initialized to 0 . ..And the function signature for crypto.subtle.encrypt() describes the iv parameter for the algorithm: > iv - A BufferSource — the initialization vector. This must be unique for every encryption operation carried out with a g…

never reuse an IV with the same key Exactly, the key is always different.

Thank you, I'd misunderstood the author's intention, my fault for not reading the article carefully.

> In this case, we only encrypt the content once with the random key so we don’t need an iv and can leave it filled with 0.

Re: End-to-end encryption in the browser

#107

Post by tatersolid »

kybernetikos wrote: post #75
m1el wrote: post #21

Earlier quoted context omitted.

And how can I be sure that the code delivered by the server is the same code as in the public codebase? Nothing stops the owner of the service to run arbitrary JavaScript in Users' browser.

Subresource Integrity allows the HTML file to insist that the js file hasn't changed. I guess it would be possible to download and run the html file from your own machine. Alternatively, it would be possible to create a service worker that uses a local copy and makes much more of a deal about files changing - it could always confirm changes with the user before allowing a change. Security sensitive apps should probab…

JS allows overriding overriding any object or method with separately loaded code. So even your “trusted” code could be compromised by separate “trusted” code.

Even native app packagers and languages can suffer from this when loading libraries dynamically (from search-path or symlink manipulation for example).

Re: End-to-end encryption in the browser

#108

Post by rixtox »

m1el wrote: post #17

I appreciate the effort, but this is one of those cases in which there isn't much security added by encryption. If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.

I think the key problem here is where and how do we establish a root of trust for Web applications.

Currently we have some form of root of trust for HTTPS/TLS, code signing, trusted execution, that the OS or browser or chipsets distribute a set of "trusted" root certificates. For the consumers, they are implicitly backed by the big companies that manage the screening, auditing, and distribution of these certificates. But of course, these certificates have limited use cases that not yet covering the end-to-end encryption application for Web.

One way or another, we have to start our root of trust at some layer, either it's hardware, OS, drivers, or applications. But in general, the lower the layer gets, the lower the risk would be. Because it's easier for an evil actor to target specific user in higher layers.

There are more to be solved than just the root of trust for E2E on Web. For example, even if we can use trusted execution environment on a Web application to ensure secure key generation and key escore, we still have to face the problem of how to input or present the cleartext data with the user. If we still let the JS code to handle the cleartext in any way, there could still be a chance that the distributor of the JS code might steal them.

With that said, not only should we have a root of trust, but we also have to trust the UI provider that operates on the sensitive data for user input or display. The lowest UI layer is usually the OS, so even we have hardware root of trust, but if the trusted UI is in the OS layer, we would still be throttled at the level of trust on the OS layer.

Re: End-to-end encryption in the browser

#109

Post by smolder »

seemslegit wrote: post #76
smolder wrote: post #41

Earlier quoted context omitted.

Let's say someone vacuums up all the packets going over the wire passively and has some way of breaking TLS. Redundant encryption would be a further obstacle to reading the contents. TLS gets MITM'd in some environments, so it's useful there.

MITM'd == not passive, so can inject malicious js.

Good point, but what's the relative difficulty of recording all your MITM'd TLS traffic org-wide as plaintext versus attacking specific sites with custom JS to exflitrate JS encryption keys? It's additional friction for lazy spying, mostly, and for a situation where TLS traffic is passively snooped and broken by other means than MITM.

Re: End-to-end encryption in the browser

#110

Post by franky47 »

rcxdude wrote: post #70
franky47 wrote: post #29

Earlier quoted context omitted.

If the JavaScript bundle that is being served is built on a public CI/CD service, it could be possible to do the following, for transparency and verification: - Include in a header comment: the build URL, Git SHA-1 of the commit, and other metadata - Sign the bundle using public/secret key cryptography Having the build URL and sources URL help with discoverability and transparency, while integrity can be verified wit…

Yes, but there's no provision in the browser to do these kinds of integrity checks. If the browser isn't verifying it there's no point in adding any of this info, because it can be substituted covertly. In principle such 'version-pinning' could be added to the browser, but no-one has done so yet.

Agreed. Even subresource integrity [1] does not help here, because if the HTML is compromised, then everything else can be too.

[1] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Post reply on HN