4 ms·

Why couldn't the entire system be E2E encrypted by default, though? In 2022, that's my standard expectation from any service. Even such things as Pocket / Insta

by krn 4y ago

Why couldn't the entire system be E2E encrypted by default, though? In 2022, that's my standard expectation from any service. Even such things as Pocket / Instapaper / Raindrop should come with E2E encryption by default. It's better for the service provider, too: no issues with GDPR, or in case of a database hack.

ilogik 4y ago
If you don't trust the person that wrote the software, it doesn't matter if it's E2E encrypted or not. There could be a back-door
- ilyt 4y ago
  which software ? You might have 3rd party client implementation that talks with another client and only server would be "unknown" party. E2E allows both clients to talk to eachother without server having a way to snoop on
- krn 4y ago
  E2E encryption happens on the client side, not on the server side. Therefore, no need to trust anybody, as long as the software is open-source.
  - hawski 4y ago
    If you run binaries compiled by the author of the software it wouldn't matter that it is open source, so play store is out of the question. So then it must be open source and you must use distributor you trust: your distro maintainers and F-Droid. Also you must trust that people did really take a look at the code.
    - krn 4y ago
      That's exactly how Signal and Keybase work, and nobody has any problems with that.
      - hawski 4y ago
        I had exactly this in mind. Mostly if I wouldn't trust the author with binaries I wouldn't really trust with source code either.
      - hamburglar 4y ago
        That’s because most people hear “E2E” and think that somehow means they can automatically trust the client app. It’s a panacea.
  - kube-system 4y ago
    > Therefore, no need to trust anybody, as long as the software is open-source. Demonstrably untrue. You must trust that the contributors are trustworthy, they have implemented a strong security posture for their project, and that the code is reviewed by people who are trustworthy. Many open-source projects have been, and continue to be, compromised on a regular basis.
    - krn 4y ago
      > You must trust that the contributors are trustworthy In theory, that's only the case if you are unable to review the code yourself. In practice, it's like saying that TLS encryption is pointless, because one needs to trust every single person who implements it.
      - hatware 4y ago
        We're sure you review all the code you run.
      - kube-system 4y ago
        That's only the case if I am unable to review the code myself, before any update, I fully understand the code, and I am smart enough that the contributors are unable to pull a fast one on me. Given that I'm not a cryptography expert, I have a limited number of hours in the day, and open-source supply chain attacks are typically obfuscated, I don't consider that to be a trivial statement.
  - beders 4y ago
    Not on phones. You have 0 guarantee that the open source code is actually the code that runs on your device. And you have 0 guarantee that the device itself is not compromised. And you have 0 guarantee that the OS is not storing your data. E2E on mobile devices is a security blanket with holes the size of the solar system.
- xyzzy4747 4y ago
  If you don’t trust a communication channel, you could always do a Diffie-Hellman key exchange in the clients which lets you create a shared encrypted channel between two parties by sharing public keys. This works even if they are trying to monitor you.
  - megous 4y ago
    Doesn't work with simplex channels.
    - xyzzy4747 4y ago
      It can work with simplex channels if you have the public key of the receiver. Both parties just need to know each other's public keys to create encrypted communication. After exchanging the public keys, it can be one-way communication. I guess it wouldn't work for a one-to-many channel though, just individual one-to-one channels.
binwiederhier 4y ago
Encryption and convenience usually don't go well together. ntfy was mainly built for simplicity. That said, I have designed and started working on E2E here: https://github.com/binwiederhier/ntfy/issues/69 https://github.com/binwiederhier/ntfy/issues/69
- deleted 4y ago
  [deleted]
horsawlarway 4y ago
Genuine question - have you ever implemented an E2E encrypted system? Because it's not particularly easy to do, and there are a lot of caveats and drawbacks. Let me rephrase your assumption: "Why couldn't you just mail me the letter in a 100lb safe. In 2022, that's my standard expectation from any service". So - are you willing to pay to ship 100lbs for every letter you send? Are you meticulously managing the details of how to handle locking and unlocking that safe? Are you working out the details on recovery and storage, handling lost devices, configuring a communication channel for sharing certs/keys, managing several crypto dependencies and libraries - all so that you can go "Hey - what's up!" in a notification to your phone? Or should you just stop whining - accept that this is free - and take the authors advice and host it yourself?
- krn 4y ago
  > Are you working out the details on recovery and storage, handling lost devices, configuring a communication channel for sharing certs/keys, managing several crypto dependencies and libraries - all so that you can go "Hey - what's up!" in a notification to your phone? In 2022, there is no need to invent anything new about E2E encryption. There are many successful open-source examples, including Keybase and Firefox Sync. There is no question that it adds development overhead, but I personally wouldn't even run a public service for others without E2E encryption. > Or should you just stop whining - accept that this is free - and take the authors advice and host it yourself? I am not attacking the author, nor do I currently care about this particular service he is providing. This is Hacker News, a discussion platform, and I am raising a question about software development in general.
  - seqastian 4y ago
    > I personally wouldn't even run a public service for others without E2E encryption. So don't? seems like everyone got what they wanted.
    - krn 4y ago
      Well, thinking logically: if everyone really got what they wanted, that question wouldn't be in the FAQ, would it?
krono 4y ago
The most important bits aren't the technical aspects, but rather who controls them. It is entirely meaningless when the keys are generated by a closed source application, when there exists no way to verify that the data isn't exfiltrated before its encryption or after its decryption, or when the only transportation method is entirely in an untrusted party's hands. When all those things are controlled by the same entity, especially one with a history of abusive and manipulative behaviour such as the operator of WhatsApp, it's not "encryption" but a "bad joke".
hdjjhhvvhga 4y ago
Encryption by default eliminates the biggest advantage: simplicity. But as an option, it's an useful addition that will be implemented sooner or later.
oliwarner 4y ago
Go figure out key exchange and use this as transport for encrypted messages. Encrypting stuff isn't hard.
- hamburglar 4y ago
  Encrypting stuff in a way that can’t be trivially subverted by a malicious client app is actually pretty hard, so what have you actually gained if you’re going to trust the client app?
hatware 4y ago
>Why couldn't the entire system be E2E encrypted by default, though? Probably because getting the system together in its current state was enough work. > In 2022, that's my standard expectation from any service. You have high standards. Do you expect others to raise their standards as high as yours...?
bccdee 4y ago
The pitch is that you can go `curl -d "My message" ntfy.sh/my_topic` and it just works. That's impossible if you want E2EE. Fortunately, it's open-source, so if you really want, you can fork the app to add a decryption layer and then use `curl -d "$(echo "My Message" | openssl enc -aes-256-cbc -pbkdf2 -e -k "My Password")" ntfy.sh/my_topic` and that'll be E2E encrypted. Or, you know, host your own ntfy server and trust in SSL.
- binwiederhier 4y ago
  You have perfectly captured my intention. :-) ntfy is supposed to be simple simple simple. E2E stands in the way in many ways. I have implemented crypto formats and such in the past, and the lack of a standard in this space is really blocking wide spread adoption and interoperability IMHO. That said, I have proposed a design here (https://github.com/binwiederhier/ntfy/issues/69#issuecomment-1183839284 https://github.com/binwiederhier/ntfy/issues/69#issuecomment...) that I have already partially implemented, and that seems easy enough to implement in many languages. But it definitely won't be the one-liner anymore.
googlryas 4y ago
The answer is simply because that is not how the dev implemented it. Why couldn't you write a patch to do that, and submit it? Or clone the code and release e2entfy.sh?

by krn 4y ago

ilogik 4y ago

If you don't trust the person that wrote the software, it doesn't matter if it's E2E encrypted or not. There could be a back-door

ilyt 4y ago
which software ? You might have 3rd party client implementation that talks with another client and only server would be "unknown" party. E2E allows both clients to talk to eachother without server having a way to snoop on
krn 4y ago
E2E encryption happens on the client side, not on the server side. Therefore, no need to trust anybody, as long as the software is open-source.
- hawski 4y ago
  If you run binaries compiled by the author of the software it wouldn't matter that it is open source, so play store is out of the question. So then it must be open source and you must use distributor you trust: your distro maintainers and F-Droid. Also you must trust that people did really take a look at the code.
  - krn 4y ago
    That's exactly how Signal and Keybase work, and nobody has any problems with that.
    - hawski 4y ago
      I had exactly this in mind. Mostly if I wouldn't trust the author with binaries I wouldn't really trust with source code either.
    - hamburglar 4y ago
      That’s because most people hear “E2E” and think that somehow means they can automatically trust the client app. It’s a panacea.
- kube-system 4y ago
  > Therefore, no need to trust anybody, as long as the software is open-source. Demonstrably untrue. You must trust that the contributors are trustworthy, they have implemented a strong security posture for their project, and that the code is reviewed by people who are trustworthy. Many open-source projects have been, and continue to be, compromised on a regular basis.
  - krn 4y ago
    > You must trust that the contributors are trustworthy In theory, that's only the case if you are unable to review the code yourself. In practice, it's like saying that TLS encryption is pointless, because one needs to trust every single person who implements it.
    - hatware 4y ago
      We're sure you review all the code you run.
    - kube-system 4y ago
      That's only the case if I am unable to review the code myself, before any update, I fully understand the code, and I am smart enough that the contributors are unable to pull a fast one on me. Given that I'm not a cryptography expert, I have a limited number of hours in the day, and open-source supply chain attacks are typically obfuscated, I don't consider that to be a trivial statement.
- beders 4y ago
  Not on phones. You have 0 guarantee that the open source code is actually the code that runs on your device. And you have 0 guarantee that the device itself is not compromised. And you have 0 guarantee that the OS is not storing your data. E2E on mobile devices is a security blanket with holes the size of the solar system.
xyzzy4747 4y ago
If you don’t trust a communication channel, you could always do a Diffie-Hellman key exchange in the clients which lets you create a shared encrypted channel between two parties by sharing public keys. This works even if they are trying to monitor you.
- megous 4y ago
  Doesn't work with simplex channels.
  - xyzzy4747 4y ago
    It can work with simplex channels if you have the public key of the receiver. Both parties just need to know each other's public keys to create encrypted communication. After exchanging the public keys, it can be one-way communication. I guess it wouldn't work for a one-to-many channel though, just individual one-to-one channels.

binwiederhier 4y ago

Encryption and convenience usually don't go well together. ntfy was mainly built for simplicity. That said, I have designed and started working on E2E here: https://github.com/binwiederhier/ntfy/issues/69 https://github.com/binwiederhier/ntfy/issues/69

deleted 4y ago
[deleted]

horsawlarway 4y ago

Genuine question - have you ever implemented an E2E encrypted system? Because it's not particularly easy to do, and there are a lot of caveats and drawbacks. Let me rephrase your assumption: "Why couldn't you just mail me the letter in a 100lb safe. In 2022, that's my standard expectation from any service". So - are you willing to pay to ship 100lbs for every letter you send? Are you meticulously managing the details of how to handle locking and unlocking that safe? Are you working out the details on recovery and storage, handling lost devices, configuring a communication channel for sharing certs/keys, managing several crypto dependencies and libraries - all so that you can go "Hey - what's up!" in a notification to your phone? Or should you just stop whining - accept that this is free - and take the authors advice and host it yourself?

krn 4y ago
> Are you working out the details on recovery and storage, handling lost devices, configuring a communication channel for sharing certs/keys, managing several crypto dependencies and libraries - all so that you can go "Hey - what's up!" in a notification to your phone? In 2022, there is no need to invent anything new about E2E encryption. There are many successful open-source examples, including Keybase and Firefox Sync. There is no question that it adds development overhead, but I personally wouldn't even run a public service for others without E2E encryption. > Or should you just stop whining - accept that this is free - and take the authors advice and host it yourself? I am not attacking the author, nor do I currently care about this particular service he is providing. This is Hacker News, a discussion platform, and I am raising a question about software development in general.
- seqastian 4y ago
  > I personally wouldn't even run a public service for others without E2E encryption. So don't? seems like everyone got what they wanted.
  - krn 4y ago
    Well, thinking logically: if everyone really got what they wanted, that question wouldn't be in the FAQ, would it?

krono 4y ago

The most important bits aren't the technical aspects, but rather who controls them. It is entirely meaningless when the keys are generated by a closed source application, when there exists no way to verify that the data isn't exfiltrated before its encryption or after its decryption, or when the only transportation method is entirely in an untrusted party's hands. When all those things are controlled by the same entity, especially one with a history of abusive and manipulative behaviour such as the operator of WhatsApp, it's not "encryption" but a "bad joke".

hdjjhhvvhga 4y ago

Encryption by default eliminates the biggest advantage: simplicity. But as an option, it's an useful addition that will be implemented sooner or later.

oliwarner 4y ago

Go figure out key exchange and use this as transport for encrypted messages. Encrypting stuff isn't hard.

hamburglar 4y ago
Encrypting stuff in a way that can’t be trivially subverted by a malicious client app is actually pretty hard, so what have you actually gained if you’re going to trust the client app?

hatware 4y ago

>Why couldn't the entire system be E2E encrypted by default, though? Probably because getting the system together in its current state was enough work. > In 2022, that's my standard expectation from any service. You have high standards. Do you expect others to raise their standards as high as yours...?

bccdee 4y ago

The pitch is that you can go `curl -d "My message" ntfy.sh/my_topic` and it just works. That's impossible if you want E2EE. Fortunately, it's open-source, so if you really want, you can fork the app to add a decryption layer and then use `curl -d "$(echo "My Message" | openssl enc -aes-256-cbc -pbkdf2 -e -k "My Password")" ntfy.sh/my_topic` and that'll be E2E encrypted. Or, you know, host your own ntfy server and trust in SSL.

binwiederhier 4y ago
You have perfectly captured my intention. :-) ntfy is supposed to be simple simple simple. E2E stands in the way in many ways. I have implemented crypto formats and such in the past, and the lack of a standard in this space is really blocking wide spread adoption and interoperability IMHO. That said, I have proposed a design here (https://github.com/binwiederhier/ntfy/issues/69#issuecomment-1183839284 https://github.com/binwiederhier/ntfy/issues/69#issuecomment...) that I have already partially implemented, and that seems easy enough to implement in many languages. But it definitely won't be the one-liner anymore.

googlryas 4y ago

The answer is simply because that is not how the dev implemented it. Why couldn't you write a patch to do that, and submit it? Or clone the code and release e2entfy.sh?