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

Web-based cryptography is always snake oil

devever.net

Post reply on HN
Print view View original

21–30 of 137 posts

Re: Web-based cryptography is always snake oil

#21

Post by prmph »

omgtehlion wrote: post #6
utopiah wrote: post #2

I'm confused, is the argument that it doesn't work because Google is fueled by surveillance capitalism? If so what about Apple which is only partly so? What about Firefox and in particular its de-branded ones without Google search as default? I think what makes the Web special is precisely that there are different browsers beyond Chromium. If the Web was Chrome I would tend to agree but even though popular I do not t…

I could not find anything about google or other browser vendors in the article. My take is that you should trust provider (developer, hoster) of said encryption app to send you actual implementation, not something that looks like the real deal, but does not encrypt anything. From a regular user's point of view: you can not inspect what you run (due to technical reasons, that on the web anything can be downloaded and…

But we are talking about protecting data at rest on the vendor's servers. Unless the vendor stores no user data at, how does TLS protect that data?

Your argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.

Re: Web-based cryptography is always snake oil

#22

Post by bigfatkitten »

stymaar wrote: post #16

> A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against. This is both true, and also useless: pretty much any E2E system is falling under this definition. By definition you can't protect yourself from the entity that provides you the software you use, because you have now way to guarantee that they aren't going to backdoor you. That doesn't mean it's…

One thing you can do is have your adversary put their money where their mouth is and use the very same products, sourced independently, that they use to protect their own sensitive information.

There are limits to this of course. You can’t buy a TACLANE[1], but you can buy many of the other products[2] USG uses to protect its own classified information.

[1] https://gdmissionsystems.com/encryption/taclane-network-encr...

[2] https://www.nsa.gov/resources/Commercial-Solutions-for-Class...

Re: Web-based cryptography is always snake oil

#23

Post by prmph »

jdw64 wrote: post #5

Before reading this article, I used to believe that IT companies deeply respected users’ human rights, spending millions of dollars to build end‑to‑end encryption. But thanks to this very article, I learned that they were actually saving tens of millions in administrative litigation costs – costs they would otherwise have had to pay every month to respond to wiretap warrants. Some might call this a “cryptographic inn…

End-to-end encryption is about protecting data at rest on the vendor's servers. TLS only secures data in transit.

The article's argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.

Sure, the article makes good arguments about the trust that is still implicit in E2EE, but it goes too far in its dismissal of it.

Re: Web-based cryptography is always snake oil

#24

Post by p-e-w »

figassis wrote: post #19

The author is basically saying if you participate in any part of the encryption process, you're deceiving users in saying things are e2e encrypted. Isn't this conflating encryption with trust? Of course whoever claims to encrypt your data needs to be trustworthy, and whether they actually are is another matter, but If my app allows you to generate a client side key, export it and use it to encrypt data client side an…

> Isn't this conflating encryption with trust?

Absolutely, and the claim is somewhere between nonsense and pedantry bordering on nonsense.

The exact same thing is true for, say, Signal. The provider delivers the client, and they aggressively block non-official clients from participating. So the “ends” in end-to-end are ultimately controlled by Signal. But as long as you trust the Signal company not to insert a backdoor into your client, it’s still true that the company can’t read your texts.

Re: Web-based cryptography is always snake oil

#25

Post by hypfer »

Isn't non-web-based cryptography affected (as per this take) in the same way but with extra steps?

A sophisticated actor might as well also control the application that ends up on my device. It does not have to be the same delivery mechanism as long as I did not write it myself.

So all cryptography is snake oil?

___

I mean I kinda sorta get the point and there would be some merit to discuss there, but the weird framing makes that very hard to do.

Of course it's easier to break web e2ee if you are for example cloudflare compared with someone also having to compromise the Debian repos.

But that's not what snake oil means.

Re: Web-based cryptography is always snake oil

#26

Post by captn3m0 »

prophesi wrote: post #3

The discussion on the proposed solution is interesting https://github.com/w3c/ServiceWorker/issues/1680

There are a lot of other implementations of this idea that don't necessarily rely on trust-on-first-use. The securedrop team explicitly includes malicious JS served by the primary-domain in the threat-model and made WEBCAT[0] as an outcome of that research. Their article on webcrypto is much better than this one.

The solution obviously is to go out-of-band:

> When a user visits a website that has enrolled in WEBCAT, before the site can load the content is checked against a signed manifest to ensure that it has not been tampered with (more on enrollment later). If everything checks out, the page loads normally. If, however, any content does not match what’s expected, the page load is aborted and a warning is displayed, protecting the user from potentially malicious content before it can execute.

[0]: https://securedrop.org/news/introducing-webcat-web-based-cod...

[1]: https://securedrop.org/news/browser-based-cryptography/

Re: Web-based cryptography is always snake oil

#27

Post by Panzerschrek »

> The purpose of cryptography theatre is not to deliver actual security from a cryptographic perspective but act as a kind of magic spell

This reminds me Telegram, which promises to be secure, but requires giving it my phone number, which is the most insecure thing one can do.

Re: Web-based cryptography is always snake oil

#28

Post by hrmon »

Many comments suggest that the definition and criteria proposed are infeasible and useless. They are not wrong. But still it points out something the layperson misses (or even many tech-savvy people): An E2EE service from A does not provably protect your data against A.

Re: Web-based cryptography is always snake oil

#29

Post by tancop »

this is one of the problems content addressed stores like nix and ipfs can prevent. every version of the code is immutable and impossible to delete. if the devs update the "latest pointer" to a backdoored release users can just stay on the old version or move to a fork. and in the happy case (honest developer) you get all the benefits of auto update.

for this to work in practice it needs to be paired with reproducible builds, open source and either p2p or server choice (use signal.mydomain.net instead of signal.org). but these are all things that already exist and none of them is really hard to set up. the harder problem is distributing community block lists of bad package versions but that can be done with atproto or simple ublock style filter files.

i think the real bottleneck for adoption is that the only browser with built in ipfs support is brave, the one thats full of crypto ads and affiliate link fraud. i dont know if firefox would ever take it up or we need to build a brand new browser. or find a way to do it one layer down with a system service.

Re: Web-based cryptography is always snake oil

#30

Post by sneak »

Reminder: iMessage claims to be e2ee, but the on-by-default iCloud Backup on iOS backs up material that is sufficient to defeat this (either the endpoint keys, in the case of "Messages in iCloud" disabled, or the messages themselves, in the case of "Messages in iCloud" enabled).

This means that, in practice, iMessage is not e2ee.

Before you say "But what about Advanced Data Protection that enables e2ee for iCloud Backup?" - virtually nobody has this on, Apple prohibits you from turning it on in the UK, and even if you enable it - the people you iMessage with don't, so your conversations are in their backups. This means that if either endpoint of the iMessage conversation is in the UK, and both parties have iCloud Backup enabled (the default), then your iMessages are not e2ee as a non-endpoint has an escrowed copy of the plaintext or keys.

Post reply on HN