6 ms·

> Since this is browser crypto, and not native execution like Magic Wormhole, all of this is irrelevant; the important distinction between the two projects isn'

> Since this is browser crypto, and not native execution like Magic Wormhole, all of this is irrelevant; the important distinction between the two projects isn't that one uses a lesser cryptosystem, but rather that the other uses real end-to-end cryptography and the other uses client-server cryptography pretending to be end-to-end. Is my reading of this as a vague and misleading way of saying that because the code responsible for the encryption is provided by the server it doesn’t count as end-to-end encryption accurate? Or is it an even vaguer hint towards something else?

feross 5y ago
> Is my reading of this as a vague and misleading way of saying that because the code responsible for the encryption is provided by the server it doesn’t count as end-to-end encryption accurate? This is how I read tptacek's comment as well. It's vague and misleading to say that any code provided to a client by a server cannot be end-to-end encryption. By that logic, even something like the Signal Desktop client (which has an auto-updater) is not end-to-end encryption. This is a not a reasonable or honest definition of end-to-end encryption.
- tptacek 5y ago
  The point of end-to-end cryptography is not having to trust servers. Your argument is that a system that appears to need to trust its server on an HTTP-request-by-HTTP-request basis must be end-to-end, because browsers on either side also do some cryptography. But that's not how it works.
  - feross 5y ago
    You can't invent your own definition of end-to-end encryption. There is a material difference between a service which end-to-end encrypts your files – even if it sends you the code to do so – and one which does not. Services like Dropbox or WeTransfer receive plaintext copies of your files. Firefox Send did not. And Wormhole, using the same design, does not either.
    - tptacek 5y ago
      See https://news.ycombinator.com/item?id=26884466 https://news.ycombinator.com/item?id=26884466.
josephg 5y ago
With E2E encryption you need to trust the developer of the software and the distribution channel (apt, App Store, web server). The GP comment is parroting the claim that browser based E2E encrypted systems are inherently less secure than native apps because web servers are untrustworthy systems for delivering software. Does native software have fundamentally more trustworthy distribution channels than web servers? I see the argument in some cases - apt always delivers the same binary for the same request (I assume). And the App Store does binary signing, rather than just TLS. But plenty of native software is just installed via the developer’s website anyway. And if the developers host the website, they’re already a party you have to trust. Giving them more trust doesn’t change much - they could just slip something nasty in the binary if they wanted your data. I still don’t totally buy it.
- detaro 5y ago
  A key aspect is that for native apps its harder (not necessarily impossible) to just at a selected point in time deliver malicious code to a selected user, with nothing persisting it. Compared to a native app that's installed in a way that it can't modify itself (and thus needs to deliver a vulnerable or malicious version during installation) that's very weak - arguably an app that can invisibly update itself is somewhere inbetween. With a web app you always load the code from the server - while at the same time using E2E to protect yourself against said server...
  - feross 5y ago
    I agree with this analysis. We'd love to offer more assurances that the code hasn't changed out from under you when using Wormhole.app. We really need a better way to "pin" a site to a current version and only update it with user consent. Right now, we're limited by the capabilities of the web platform and will probably need to ship a native app to accomplish this.
    - codezero 5y ago
      What about using sub resource integrity to allow users to request a specific JS version using its integrity attribute in the URL, that way shares also use the same pinned version, and can check/verify the integrity themselves or via some centrally informative place as well.
tptacek 5y ago
I don't know what's "vague" or "misleading" about it. Almost every HTTP transaction you have with a server providing browser-based cryptography offers the server another opportunity to alter the code that handles cryptography secrets. It's not a matter of "software update", though that's where this discussion always seems to be pushed; it's every individual operation of the application. People --- including the author of this application, if I'm reading it right --- talk about the need to "audit" these kinds of applications. But there's no such thing as "auditing" a browser Javascript application. The code it feeds you on startup is not necessarily the code that you are running at any given point during its execution. The entire web security model is based on the idea that the origin is the root of security; that's why we gave it a special name. Compare with Magic Wormhole (a project I'm in no way affiliated with), which has the same basic functionality, and in which the server has no ability to subvert the cryptography used to transmit files; not on a run-by-run basis, or on a file-by-file basis, or even a protocol-message-by-protocol-message basis. This is an old argument, one widely (though not absolutely) shared among software security engineers, so it's a little rich to see people express shock at reading it here. You can disagree with me; many have, over the years. But you can't claim it's an argument from left field.
- feross 5y ago
  You can't invent your own definition of end-to-end encryption. There is a material difference between a service which end-to-end encrypts your files – even if it sends you the code to do so – and one which does not. When a user logs into 1Password.com, they're using end-to-end encryption. The master password and secret key never leave the browser. The server never receives the key and therefore does not have a way to access the contents of password vaults. This is very different from an application which, by design, sends your plaintext data to remote servers. The English phrase we use to describe this difference is "end-to-end encryption".
  - tptacek 5y ago
    I have not in fact invented my own definition of end-to-end encryption, and yours is not the first application --- nor is browser crypto the only cryptography setting --- that has tried to claim "end-to-end security" for a design where both ends implicitly trust the server.

feross 5y ago

> Is my reading of this as a vague and misleading way of saying that because the code responsible for the encryption is provided by the server it doesn’t count as end-to-end encryption accurate? This is how I read tptacek's comment as well. It's vague and misleading to say that any code provided to a client by a server cannot be end-to-end encryption. By that logic, even something like the Signal Desktop client (which has an auto-updater) is not end-to-end encryption. This is a not a reasonable or honest definition of end-to-end encryption.

tptacek 5y ago
The point of end-to-end cryptography is not having to trust servers. Your argument is that a system that appears to need to trust its server on an HTTP-request-by-HTTP-request basis must be end-to-end, because browsers on either side also do some cryptography. But that's not how it works.
- feross 5y ago
  You can't invent your own definition of end-to-end encryption. There is a material difference between a service which end-to-end encrypts your files – even if it sends you the code to do so – and one which does not. Services like Dropbox or WeTransfer receive plaintext copies of your files. Firefox Send did not. And Wormhole, using the same design, does not either.
  - tptacek 5y ago
    See https://news.ycombinator.com/item?id=26884466 https://news.ycombinator.com/item?id=26884466.

josephg 5y ago

With E2E encryption you need to trust the developer of the software and the distribution channel (apt, App Store, web server). The GP comment is parroting the claim that browser based E2E encrypted systems are inherently less secure than native apps because web servers are untrustworthy systems for delivering software. Does native software have fundamentally more trustworthy distribution channels than web servers? I see the argument in some cases - apt always delivers the same binary for the same request (I assume). And the App Store does binary signing, rather than just TLS. But plenty of native software is just installed via the developer’s website anyway. And if the developers host the website, they’re already a party you have to trust. Giving them more trust doesn’t change much - they could just slip something nasty in the binary if they wanted your data. I still don’t totally buy it.

detaro 5y ago
A key aspect is that for native apps its harder (not necessarily impossible) to just at a selected point in time deliver malicious code to a selected user, with nothing persisting it. Compared to a native app that's installed in a way that it can't modify itself (and thus needs to deliver a vulnerable or malicious version during installation) that's very weak - arguably an app that can invisibly update itself is somewhere inbetween. With a web app you always load the code from the server - while at the same time using E2E to protect yourself against said server...
- feross 5y ago
  I agree with this analysis. We'd love to offer more assurances that the code hasn't changed out from under you when using Wormhole.app. We really need a better way to "pin" a site to a current version and only update it with user consent. Right now, we're limited by the capabilities of the web platform and will probably need to ship a native app to accomplish this.
  - codezero 5y ago
    What about using sub resource integrity to allow users to request a specific JS version using its integrity attribute in the URL, that way shares also use the same pinned version, and can check/verify the integrity themselves or via some centrally informative place as well.

tptacek 5y ago

I don't know what's "vague" or "misleading" about it. Almost every HTTP transaction you have with a server providing browser-based cryptography offers the server another opportunity to alter the code that handles cryptography secrets. It's not a matter of "software update", though that's where this discussion always seems to be pushed; it's every individual operation of the application. People --- including the author of this application, if I'm reading it right --- talk about the need to "audit" these kinds of applications. But there's no such thing as "auditing" a browser Javascript application. The code it feeds you on startup is not necessarily the code that you are running at any given point during its execution. The entire web security model is based on the idea that the origin is the root of security; that's why we gave it a special name. Compare with Magic Wormhole (a project I'm in no way affiliated with), which has the same basic functionality, and in which the server has no ability to subvert the cryptography used to transmit files; not on a run-by-run basis, or on a file-by-file basis, or even a protocol-message-by-protocol-message basis. This is an old argument, one widely (though not absolutely) shared among software security engineers, so it's a little rich to see people express shock at reading it here. You can disagree with me; many have, over the years. But you can't claim it's an argument from left field.

feross 5y ago
You can't invent your own definition of end-to-end encryption. There is a material difference between a service which end-to-end encrypts your files – even if it sends you the code to do so – and one which does not. When a user logs into 1Password.com, they're using end-to-end encryption. The master password and secret key never leave the browser. The server never receives the key and therefore does not have a way to access the contents of password vaults. This is very different from an application which, by design, sends your plaintext data to remote servers. The English phrase we use to describe this difference is "end-to-end encryption".
- tptacek 5y ago
  I have not in fact invented my own definition of end-to-end encryption, and yours is not the first application --- nor is browser crypto the only cryptography setting --- that has tried to claim "end-to-end security" for a design where both ends implicitly trust the server.