Live data from Hacker News

Web-based cryptography is always snake oil

devever.net

131–137 of 137 posts

Re: Web-based cryptography is always snake oil

#131

Earlier quoted context omitted.

I have no idea who you're responding to because nobody on this thread has made that argument.

Maybe if you made your point straight instead of making laconic remarks this discussion would be more constructive… All I got from your few words is that apparently you consider the NSA breaking into a random foreign app a reasonable threat model to design around. Abduction from the CIA being only marginally more unlikely, why bother with anything? Or maybe I misunderstood your point but then again when you can't bot…

I can't help you with any of this, but again: the argument you made about cryptography and jurisdiction, nobody on this thread has taken the other side of.

Re: Web-based cryptography is always snake oil

#132

Earlier quoted context omitted.

Maybe if you made your point straight instead of making laconic remarks this discussion would be more constructive… All I got from your few words is that apparently you consider the NSA breaking into a random foreign app a reasonable threat model to design around. Abduction from the CIA being only marginally more unlikely, why bother with anything? Or maybe I misunderstood your point but then again when you can't bot…

I can't help you with any of this, but again: the argument you made about cryptography and jurisdiction, nobody on this thread has taken the other side of.

It's getting outright fascinating, why do you even stick in this conversation if you don't want to engage in it with more than one ambiguous sentence at a time?

Re: Web-based cryptography is always snake oil

#133
post #43

Earlier quoted context omitted.

> 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's not completely true. If I can control when (and if!) the software updates and if there is some kind of vetting process to verify that the version I'm currently running does not contain a backdoor, I can treat it like a third party with…

> if there is some kind of vetting process to verify that the version I'm currently running does not contain a backdoor This would be extremely difficult, I would say impossible from a practical standpoint.

Calculating a hash and comparing against reproducible builds doesn't seem to complicated.

Re: Web-based cryptography is always snake oil

#134
post #23
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.

>End-to-end encryption is about protecting data at rest on the vendor's servers

No its literally in the name. It's about encryption between the end points of data communication. In most cases between two clients with the middle man server exchanging and hosting the encrypted data between them.

Its about protecting live data which in practice also results in at rest data protection because all data is encrypted which only the end points can decrypt. FDE for example only protects at rest data but does nothing to prevent live data extraction.

Re: Web-based cryptography is always snake oil

#135
post #62

Earlier quoted context omitted.

>> This is not true. I can build Signal from source from GitHub > Sure, but can you find an NSA-designed backdoor in the source code? You're moving the goalpost. They were responding to the claim suggesting it's impossible to get non-Signal provided signal. >> you can get it once and disable autoupdates > Try doing that with Signal, and you'll be unable to connect to the main network in just a few days because you ge…

> You're moving the goalpost. They were responding to the claim suggesting it's impossible to get non-Signal provided signal. That was never my claim. The claim is that you cannot protect youself from Signal being malicious if Signal is the maker of the software. Compiling the software yourself doesn't help against the kind of adversary in the threat model. > That's demonstrably false. On one of my idle/backup phones…

Defense against Signal may not be total, but if you build from source (or use a reproducible build) you can check to be pretty sure you have the same software as everyone else, in which case a backdoor would have to be in a public version of Signal, which means any backdoor has a chance of getting discovered.

Backdoors can be well-hidden, but this is the kind of software that people look for vulnerabilities in [1]. This gives a lot less flexibility to any potential backdoor.

Additionally, someone could decide to write a new Signal client from scratch, designed to be compatible with the original server. Such a client would probably be less secure overall, at least at first, but it couldn't have a backdoor inserted by Signal developers, since it wouldn't contain any Signal code. Since the original client also supports end-to-end encryption, a new client can be compatible with old clients.

[1] https://community.signalusers.org/t/overview-of-third-party-...

Re: Web-based cryptography is always snake oil

#136

"Thus the client-side code is always distributed by the operator of the web server." The same goes for client side code distributed by the operators of free "communication services", e.g., Meta (WhatsApp), Signal, etc. "In other words, web-based "E2E" applications claim to secure against malice on the part of the server operator using encryption implemented in client-side JavaScript, but this is obviously not true, s…

1,2,1

Re: Web-based cryptography is always snake oil

#137

"Thus the client-side code is always distributed by the operator of the web server." The same goes for client side code distributed by the operators of free "communication services", e.g., Meta (WhatsApp), Signal, etc. "In other words, web-based "E2E" applications claim to secure against malice on the part of the server operator using encryption implemented in client-side JavaScript, but this is obviously not true, s…

*At
Post reply on HN