3 ms·

> 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

by stymaar 3mo ago

> 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 snake oil though, as the entity you want protection against is generally not the software provider but a third party. Using e2e from a US-based entity means you are prone to spying from the US government, but at least you know you're reasonably secure against the IRGC, the Chinese intelligence service, the FSB, and so on. It also means you are safe from data leaks, which are by far the most common threat today. No system can be secure unconditionally, it's always secure under a particular threat model. And in practice “the attacker is able to deploy arbitrary code on your behalf for an extended period of time without being detected ” is a much narrower attack surface than “the attacker is able to obtain read-only access to your DB or your backups for at least a few minutes”. In the former case, the encryption being broken is also the least of your concern, as you've basically given remote access to all of your user's devices at this point…

bigfatkitten 3mo ago
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-encryption https://gdmissionsystems.com/encryption/taclane-network-encr... [2] https://www.nsa.gov/resources/Commercial-Solutions-for-Classified-Program/ https://www.nsa.gov/resources/Commercial-Solutions-for-Class...
- crote 3mo ago
  The obvious counterexample is NOBUS[0] vulnerabilities, and intentional backdoors like the Clipper Chip[1] or Dual_EC_DRBG[2]: if you genuinely believe you are the only one who could possibly exploit it, there's no reason to avoid using it. A more modern example is probably the NSA aggressively pushing[3] for replacing classical encryption with post-quantum encryption, rather than taking the more conservative and probably-more-secure approach of layering the two - while at the same time mandating the use of two layers of those same algorithms for their own use[4]! [0]: https://en.wikipedia.org/wiki/NOBUS https://en.wikipedia.org/wiki/NOBUS [1]: https://en.wikipedia.org/wiki/Clipper_chip https://en.wikipedia.org/wiki/Clipper_chip [2]: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG [3]: https://blog.cr.yp.to/20251004-weakened.html https://blog.cr.yp.to/20251004-weakened.html [4]: https://defense-solutions.curtisswright.com/capabilities/technologies/security/nsa-commercial-solutions-classified https://defense-solutions.curtisswright.com/capabilities/tec...
  - bigfatkitten 3mo ago
    > The obvious counterexample is NOBUS[0] vulnerabilities, and intentional backdoors like the Clipper Chip[1] or Dual_EC_DRBG[2]: if you genuinely believe you are the only one who could possibly exploit it, there's no reason to avoid using it. The problem with these examples is that they weren't used in national security systems, which are the systems for which NSA has a legislated defensive responsibility. Clipper was designed for use by the public; it was not intended to ever be used to protect classified (or even sensitive unclassified) information at all. Likewise with Dual_EC_DRBG. The CSfC component requirements drew from the Common Criteria Protection Profiles, where Dual_EC_DRBG was never an option.
  - tptacek 3mo ago
    The NSA isn't aggressively pushing for PQC; the industry is. Note that the PQC standard we have was the product of a competition won by European academic cryptographers.
    - adrian_b 3mo ago
      That is not what the comment to which you replied said. There is a consensus about pushing PQC and about the PQC standard. The dispute is about something else, about whether the current Diffie-Hellman based key establishment algorithms should be immediately and completely replaced by PQC (which is what NSA pushes), or to be more prudent and use for some time both methods (so that the key exchange cannot be broken when any of the 2 algorithms is broken), to afford more time for gaining confidence in the standardized PQC algorithms, until eventually one might decide that it is reasonable to omit the current algorithms. What NSA wants reduces somewhat the costs, but not by much, because PQC is much more expensive, so most of the cost is determined by it and not by the classic algorithms, even when they are used together, and also because keeping the current algorithms does not require any development work, as there are mature implementations in SW or in HW for all applications. The opponents argue that this small cost reduction is not worthwhile, because it eliminates the serious risks that flaws may be discovered later in the current PQC standards. Moreover what NSA wants would complicate the protocols, because many would not accept the risks of the NSA variant, so it would remain optional to omit the classic algorithms, increasing the number of choices in the protocol, which is always undesirable in security protocols.
sneak 3mo ago
> This is both true, and also useless: pretty much any E2E system is falling under this definition. This is not true. I can build Signal from source from GitHub, and use Signal-the-service with the client (which did not come from Signal, but GitHub/my compiler). Many cryptosystems are like this. In any case, if you are getting something from the App Store, you can get it once and disable autoupdates, which prevents the service provider (presuming they are the same as the people who published the app) from backdooring you at some point in the future. Alternately, even with updates, unless Apple is colluding with them to serve only you* a specific backdoored app, you can at least be reasonably confident that it's not specifically backdooring only you* in an undetectable fashion.
- stymaar 3mo ago
  > 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 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 get out of sync. Also, what do you do if there's a high severity CVE on the program? You still don't update or you re-audit all the new code? What you describe may be possible for an intelligence agency, but completely out of reach for an individual. > unless Apple is colluding with them Given the most likely adversary is the US intelligence with a warrant, it's absolutely not far fetched to assume that in your threat model. > you can at least be reasonably confident that it's not specifically backdooring only you That's not really reassuring…
  - subscribed 3mo ago
    >> 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 get out of sync. That's demonstrably false. On one of my idle/backup phones I'm using Signal 8.8.2, released in April 2026, almost 3 full months ago. It can not only connect to the network but everything works, with every contact. You might think of the official Signal client expiration, but that's client side (meaning that you can compile and use the version that doesn't have it) and..... 90 days, not "a few". I don't have a concrete number for the server side of enforcement though (minimumVersions seems to be populated at start time, with the defaults not committed to the repo). It's not entirely unreasonable to assume that the lowest official supported version is the one that introduced the concept of usernames, and the only meaningful capability test is SPQR. > Also, what do you do if there's a high severity CVE on the program? You still don't update or you re-audit all the new code? I think disabling auto update was shown as a possible strategy against a silent, targeted auto update. Not a way to remain protected against the general CVEs. Non sequitur.
adirelle 3mo ago
> the entity you want protection against is generally not the software provider but a third party. This. The author is dismissing the whole web-based cryptography, or any end-to-end cryptography for that matter, on the basis of a one-dimension analysis.
- sscaryterry 3mo ago
  The article is nothing but a rant.
  - earth-tattoo 3mo ago
    Craigslist used to have a Rants & Raves section for exactly these kind of things. I think they still have, but in old times it used to be so happening! Maybe hacker news needs to have one.
  - tarpitt 3mo ago
    Your comment is merely a comment and not an argument
- upofadown 3mo ago
  But claiming that your system is end to end encrypted means that you are claiming protection from you and your system. This is mainly a truth in advertising issue.
  - stymaar 3mo ago
    > means that you are claiming protection from you and your system. Not necessarily. I push for e2ee everywhere I can for a completely different reason: when (not “if”, “when“) we get breached, we cannot leak sensitive data we don't have.
    - tarpitt 3mo ago
      The problem is that your system can be changed at any time such that you can have the information.
xg15 3mo ago
> Using e2e from a US-based entity means you are prone to spying from the US government, but at least you know you're reasonably secure against the IRGC, the Chinese intelligence service, the FSB, and so on. You don't need E2E for that, using https/TLS for transport and servers hosted in the US would be enough.
- stymaar 3mo ago
  It will be enough until the server is pwnd and the data is leaked to the world. Data breaches happen literally every day.
  - xg15 3mo ago
    But that's OP's point. If the server is pwned, the hackers can simply change the front-end of the app and have it send the confidential data to wherever after it was decrypted on the client.
    - stymaar 3mo ago
      See what I wrote above: > in practice “the attacker is able to deploy arbitrary code on your behalf for an extended period of time without being detected ” is a much narrower attack surface than “the attacker is able to obtain read-only access to your DB or your backups for at least a few minutes”. In the former case, the encryption being broken is also the least of your concern, as you've basically given remote access to all of your user's devices at this point… Data breach occur every day, rootkits being covertly deployed in production apps for a substantial period are much rarer. E2ee only protects against the former, like a safety belt only prevent you from frontal shocks. Nobody would say they are snake oil because of that.
      - tarpitt 3mo ago
        I would say that they are snake oil because of that. Data breaches occur more often than rootkits because most developers see that this path adding easily-removable encryption does nothing in the long run.
xg15 3mo ago
> 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 respect to the server. I agree with you though that most current software that are made to auto-update at any time without any oversight do not fall under this umbrella. Web apps definitely don't fall under it.
- SoftTalker 3mo ago
  > 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.
  - rstuart4133 3mo ago
    > This would be extremely difficult, I would say impossible from a practical standpoint. It's not only practical and possible, it's so common it even has a name in software engineering circles: change control. It boils down to this: you delay installing the software until it's been reviewed, tested and deployed by others. Or as Linus would put it, until the many eyeballs have had their say. As for "the person in control of the platform": the solution is to remove some of that control. You make new versions of the software available for anonymous download, so the provider has no idea who is upgrading. All open source distributions provide their software in that way. No proprietary platforms I'm aware of do, because they want a "billing relationship" with the customer. Once downloads are anonymous, the owner of the software can't target individuals with a tailored Trojan Horse binary. Everyone gets the same binary, and so there are lots of eyeballs looking at it. The final piece of the puzzle is reproducible builds, which ensures the many eyeballs can see the code use to build the binary. All this has been around for a while now, so it's largely a solved problem in open source distributions. The problem with web-based cryptography is it isn't managed like an open source distribution. Downloads aren't anonymous, the source isn't available or signed, and it changes so fast change control isn't possible. So yeah, as things stand it's snake oil. But it doesn't have to be - it's just the way things are now.
upofadown 3mo ago
>...pretty much any E2E system is falling under this definition. The definition is quite clear. It does not apply when the implementation is not distributed by the same entity that creates it for example. There are other related issues but the message here is that web based cryptography has a particular weakness when it comes to things like end to end encrypted messaging which makes it so bad as to be worthless.
- stymaar 3mo ago
  > The definition is quite clear. It does not apply when the implementation is not distributed by the same entity that creates it for example. How can you be sure that the entity distributing the software didn't backdoor it? > the message here is that web based cryptography has a particular weakness when it comes to things like end to end encrypted messaging There's literally no substance about that claim in TFA.
conartist6 3mo ago
It's not useless, I don't think. If the software is open source and you only install new versions after their source code has been audited, you should be ok.
teravor 3mo ago
a website can serve you a keylogger client and no one will ever know most likely, harder to do with binaries/sources
eptcyka 3mo ago
> 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. But with repro builds and system transparency, hiding backdoors is impractical.
- sandeepkd 3mo ago
  Not really, time and time again people have abused their position/influence to build backdoors almost into everything for good or bad reasons. The whole idea of third party audits was to ensure that there are checks and balances. Then again the auditors are lowest paid to get stuff done and they take word of the company for most part. On other hand its quite natural, security is not really getting you direct revenue so business is least motivated in investing it or say continuously investing in it. The ones that do are doing partial lip service for most part.
  - tptacek 3mo ago
    Really? "Time and time again", "almost everything"? Make a list!
delusional 3mo ago
> Using e2e from a US-based entity means you are prone to spying from the US government, but at least you know you're reasonably secure against the IRGC, the Chinese intelligence service, the FSB, and so on. Framing this in terms of governmental espionage is nonsensical. Using e2e from a US-based entity makes you completely sure that the US government is spying on you, because they assert direct control over the software you are running. There is no venue to seek justice against an unlawful contract if the government is in on it. You should instead take a step back into reality and consider data misuse by normal non-government actors. Facebook claiming e2e encryption is a contractual matter, that you can litigate. That's where the actual protection is. That's also why real business demands not "unbreakable encryption" but reliable marker for access and tampering. It is much more useful to have a record of who accessed the data, than a claim that it's impossible.
- tptacek 3mo ago
  I think the whole US vs. non-US thing is total crap and there's nothing you can reasonably do with it in any direction, but I always think it's important to point out that US signals intelligence can lawfully compromise foreign communications; that's literally their chartered purpose.
  - delusional 3mo ago
    > there's nothing you can reasonably do with it in any direction I wholeheartedly agree. That's why bringing nation state threats into these kinds of discussions is so pointless. If you want security from governments, the amount of security work you have to do is so far beyond what any reasonable person is willing to endure that it makes no sense to talk about on hackernews. That stuff is for real professional discussions at real professional congresses.
  - stymaar 3mo ago
    > I think the whole US vs. non-US thing is total crap It's not. US companies can be subpoenaed in the US. > I always think it's important to point out that US signals intelligence can lawfully compromise foreign communications; that's literally their chartered purpose. Of course they can. But it's significantly easier to get a warrant to target a company under US jurisdiction.
ignoramous 3mo ago
> 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. There are levels to this (hermetic/reproducible builds & attestations, as one example). In fact, TFA is harsh for the only case it wants to make an example out of, WhatsApp Web: Code Verify works in partnership with Cloudflare, a web infrastructure and security company, to provide independent, third-party, transparent verification of the code you're being served on WhatsApp Web. We hope this gives at-risk users peace of mind. https://blog.cloudflare.com/cloudflare-verifies-code-whatsapp-web-serves-users https://blog.cloudflare.com/cloudflare-verifies-code-whatsap... & https://engineering.fb.com/2022/03/10/security/code-verify/ https://engineering.fb.com/2022/03/10/security/code-verify/
echoangle 3mo ago
> 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. Well that’s just wrong, just make it open source and do reproducible builds

by stymaar 3mo ago

bigfatkitten 3mo ago

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-encryption https://gdmissionsystems.com/encryption/taclane-network-encr... [2] https://www.nsa.gov/resources/Commercial-Solutions-for-Classified-Program/ https://www.nsa.gov/resources/Commercial-Solutions-for-Class...

crote 3mo ago
The obvious counterexample is NOBUS[0] vulnerabilities, and intentional backdoors like the Clipper Chip[1] or Dual_EC_DRBG[2]: if you genuinely believe you are the only one who could possibly exploit it, there's no reason to avoid using it. A more modern example is probably the NSA aggressively pushing[3] for replacing classical encryption with post-quantum encryption, rather than taking the more conservative and probably-more-secure approach of layering the two - while at the same time mandating the use of two layers of those same algorithms for their own use[4]! [0]: https://en.wikipedia.org/wiki/NOBUS https://en.wikipedia.org/wiki/NOBUS [1]: https://en.wikipedia.org/wiki/Clipper_chip https://en.wikipedia.org/wiki/Clipper_chip [2]: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG [3]: https://blog.cr.yp.to/20251004-weakened.html https://blog.cr.yp.to/20251004-weakened.html [4]: https://defense-solutions.curtisswright.com/capabilities/technologies/security/nsa-commercial-solutions-classified https://defense-solutions.curtisswright.com/capabilities/tec...
- bigfatkitten 3mo ago
  > The obvious counterexample is NOBUS[0] vulnerabilities, and intentional backdoors like the Clipper Chip[1] or Dual_EC_DRBG[2]: if you genuinely believe you are the only one who could possibly exploit it, there's no reason to avoid using it. The problem with these examples is that they weren't used in national security systems, which are the systems for which NSA has a legislated defensive responsibility. Clipper was designed for use by the public; it was not intended to ever be used to protect classified (or even sensitive unclassified) information at all. Likewise with Dual_EC_DRBG. The CSfC component requirements drew from the Common Criteria Protection Profiles, where Dual_EC_DRBG was never an option.
- tptacek 3mo ago
  The NSA isn't aggressively pushing for PQC; the industry is. Note that the PQC standard we have was the product of a competition won by European academic cryptographers.
  - adrian_b 3mo ago
    That is not what the comment to which you replied said. There is a consensus about pushing PQC and about the PQC standard. The dispute is about something else, about whether the current Diffie-Hellman based key establishment algorithms should be immediately and completely replaced by PQC (which is what NSA pushes), or to be more prudent and use for some time both methods (so that the key exchange cannot be broken when any of the 2 algorithms is broken), to afford more time for gaining confidence in the standardized PQC algorithms, until eventually one might decide that it is reasonable to omit the current algorithms. What NSA wants reduces somewhat the costs, but not by much, because PQC is much more expensive, so most of the cost is determined by it and not by the classic algorithms, even when they are used together, and also because keeping the current algorithms does not require any development work, as there are mature implementations in SW or in HW for all applications. The opponents argue that this small cost reduction is not worthwhile, because it eliminates the serious risks that flaws may be discovered later in the current PQC standards. Moreover what NSA wants would complicate the protocols, because many would not accept the risks of the NSA variant, so it would remain optional to omit the classic algorithms, increasing the number of choices in the protocol, which is always undesirable in security protocols.

sneak 3mo ago

> This is both true, and also useless: pretty much any E2E system is falling under this definition. This is not true. I can build Signal from source from GitHub, and use Signal-the-service with the client (which did not come from Signal, but GitHub/my compiler). Many cryptosystems are like this. In any case, if you are getting something from the App Store, you can get it once and disable autoupdates, which prevents the service provider (presuming they are the same as the people who published the app) from backdooring you at some point in the future. Alternately, even with updates, unless Apple is colluding with them to serve only you* a specific backdoored app, you can at least be reasonably confident that it's not specifically backdooring only you* in an undetectable fashion.

stymaar 3mo ago
> 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 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 get out of sync. Also, what do you do if there's a high severity CVE on the program? You still don't update or you re-audit all the new code? What you describe may be possible for an intelligence agency, but completely out of reach for an individual. > unless Apple is colluding with them Given the most likely adversary is the US intelligence with a warrant, it's absolutely not far fetched to assume that in your threat model. > you can at least be reasonably confident that it's not specifically backdooring only you That's not really reassuring…
- subscribed 3mo ago
  >> 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 get out of sync. That's demonstrably false. On one of my idle/backup phones I'm using Signal 8.8.2, released in April 2026, almost 3 full months ago. It can not only connect to the network but everything works, with every contact. You might think of the official Signal client expiration, but that's client side (meaning that you can compile and use the version that doesn't have it) and..... 90 days, not "a few". I don't have a concrete number for the server side of enforcement though (minimumVersions seems to be populated at start time, with the defaults not committed to the repo). It's not entirely unreasonable to assume that the lowest official supported version is the one that introduced the concept of usernames, and the only meaningful capability test is SPQR. > Also, what do you do if there's a high severity CVE on the program? You still don't update or you re-audit all the new code? I think disabling auto update was shown as a possible strategy against a silent, targeted auto update. Not a way to remain protected against the general CVEs. Non sequitur.

adirelle 3mo ago

> the entity you want protection against is generally not the software provider but a third party. This. The author is dismissing the whole web-based cryptography, or any end-to-end cryptography for that matter, on the basis of a one-dimension analysis.

sscaryterry 3mo ago
The article is nothing but a rant.
- earth-tattoo 3mo ago
  Craigslist used to have a Rants & Raves section for exactly these kind of things. I think they still have, but in old times it used to be so happening! Maybe hacker news needs to have one.
- tarpitt 3mo ago
  Your comment is merely a comment and not an argument
upofadown 3mo ago
But claiming that your system is end to end encrypted means that you are claiming protection from you and your system. This is mainly a truth in advertising issue.
- stymaar 3mo ago
  > means that you are claiming protection from you and your system. Not necessarily. I push for e2ee everywhere I can for a completely different reason: when (not “if”, “when“) we get breached, we cannot leak sensitive data we don't have.
  - tarpitt 3mo ago
    The problem is that your system can be changed at any time such that you can have the information.

xg15 3mo ago

stymaar 3mo ago
It will be enough until the server is pwnd and the data is leaked to the world. Data breaches happen literally every day.
- xg15 3mo ago
  But that's OP's point. If the server is pwned, the hackers can simply change the front-end of the app and have it send the confidential data to wherever after it was decrypted on the client.
  - stymaar 3mo ago
    See what I wrote above: > in practice “the attacker is able to deploy arbitrary code on your behalf for an extended period of time without being detected ” is a much narrower attack surface than “the attacker is able to obtain read-only access to your DB or your backups for at least a few minutes”. In the former case, the encryption being broken is also the least of your concern, as you've basically given remote access to all of your user's devices at this point… Data breach occur every day, rootkits being covertly deployed in production apps for a substantial period are much rarer. E2ee only protects against the former, like a safety belt only prevent you from frontal shocks. Nobody would say they are snake oil because of that.
    - tarpitt 3mo ago
      I would say that they are snake oil because of that. Data breaches occur more often than rootkits because most developers see that this path adding easily-removable encryption does nothing in the long run.

xg15 3mo ago

> 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 respect to the server. I agree with you though that most current software that are made to auto-update at any time without any oversight do not fall under this umbrella. Web apps definitely don't fall under it.

SoftTalker 3mo ago
> 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.
- rstuart4133 3mo ago
  > This would be extremely difficult, I would say impossible from a practical standpoint. It's not only practical and possible, it's so common it even has a name in software engineering circles: change control. It boils down to this: you delay installing the software until it's been reviewed, tested and deployed by others. Or as Linus would put it, until the many eyeballs have had their say. As for "the person in control of the platform": the solution is to remove some of that control. You make new versions of the software available for anonymous download, so the provider has no idea who is upgrading. All open source distributions provide their software in that way. No proprietary platforms I'm aware of do, because they want a "billing relationship" with the customer. Once downloads are anonymous, the owner of the software can't target individuals with a tailored Trojan Horse binary. Everyone gets the same binary, and so there are lots of eyeballs looking at it. The final piece of the puzzle is reproducible builds, which ensures the many eyeballs can see the code use to build the binary. All this has been around for a while now, so it's largely a solved problem in open source distributions. The problem with web-based cryptography is it isn't managed like an open source distribution. Downloads aren't anonymous, the source isn't available or signed, and it changes so fast change control isn't possible. So yeah, as things stand it's snake oil. But it doesn't have to be - it's just the way things are now.

upofadown 3mo ago

>...pretty much any E2E system is falling under this definition. The definition is quite clear. It does not apply when the implementation is not distributed by the same entity that creates it for example. There are other related issues but the message here is that web based cryptography has a particular weakness when it comes to things like end to end encrypted messaging which makes it so bad as to be worthless.

stymaar 3mo ago
> The definition is quite clear. It does not apply when the implementation is not distributed by the same entity that creates it for example. How can you be sure that the entity distributing the software didn't backdoor it? > the message here is that web based cryptography has a particular weakness when it comes to things like end to end encrypted messaging There's literally no substance about that claim in TFA.

conartist6 3mo ago

It's not useless, I don't think. If the software is open source and you only install new versions after their source code has been audited, you should be ok.

teravor 3mo ago

a website can serve you a keylogger client and no one will ever know most likely, harder to do with binaries/sources

eptcyka 3mo ago

> 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. But with repro builds and system transparency, hiding backdoors is impractical.

sandeepkd 3mo ago
Not really, time and time again people have abused their position/influence to build backdoors almost into everything for good or bad reasons. The whole idea of third party audits was to ensure that there are checks and balances. Then again the auditors are lowest paid to get stuff done and they take word of the company for most part. On other hand its quite natural, security is not really getting you direct revenue so business is least motivated in investing it or say continuously investing in it. The ones that do are doing partial lip service for most part.
- tptacek 3mo ago
  Really? "Time and time again", "almost everything"? Make a list!

delusional 3mo ago

> Using e2e from a US-based entity means you are prone to spying from the US government, but at least you know you're reasonably secure against the IRGC, the Chinese intelligence service, the FSB, and so on. Framing this in terms of governmental espionage is nonsensical. Using e2e from a US-based entity makes you completely sure that the US government is spying on you, because they assert direct control over the software you are running. There is no venue to seek justice against an unlawful contract if the government is in on it. You should instead take a step back into reality and consider data misuse by normal non-government actors. Facebook claiming e2e encryption is a contractual matter, that you can litigate. That's where the actual protection is. That's also why real business demands not "unbreakable encryption" but reliable marker for access and tampering. It is much more useful to have a record of who accessed the data, than a claim that it's impossible.

tptacek 3mo ago
I think the whole US vs. non-US thing is total crap and there's nothing you can reasonably do with it in any direction, but I always think it's important to point out that US signals intelligence can lawfully compromise foreign communications; that's literally their chartered purpose.
- delusional 3mo ago
  > there's nothing you can reasonably do with it in any direction I wholeheartedly agree. That's why bringing nation state threats into these kinds of discussions is so pointless. If you want security from governments, the amount of security work you have to do is so far beyond what any reasonable person is willing to endure that it makes no sense to talk about on hackernews. That stuff is for real professional discussions at real professional congresses.
- stymaar 3mo ago
  > I think the whole US vs. non-US thing is total crap It's not. US companies can be subpoenaed in the US. > I always think it's important to point out that US signals intelligence can lawfully compromise foreign communications; that's literally their chartered purpose. Of course they can. But it's significantly easier to get a warrant to target a company under US jurisdiction.

ignoramous 3mo ago

> 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. There are levels to this (hermetic/reproducible builds & attestations, as one example). In fact, TFA is harsh for the only case it wants to make an example out of, WhatsApp Web: Code Verify works in partnership with Cloudflare, a web infrastructure and security company, to provide independent, third-party, transparent verification of the code you're being served on WhatsApp Web. We hope this gives at-risk users peace of mind. https://blog.cloudflare.com/cloudflare-verifies-code-whatsapp-web-serves-users https://blog.cloudflare.com/cloudflare-verifies-code-whatsap... & https://engineering.fb.com/2022/03/10/security/code-verify/ https://engineering.fb.com/2022/03/10/security/code-verify/

echoangle 3mo ago

> 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. Well that’s just wrong, just make it open source and do reproducible builds