4 ms·

I really like the idea of this. For some applications it would be very useful assuming the implementation is up to it. Unfortunately, just reading the FAQ a s

I really like the idea of this. For some applications it would be very useful assuming the implementation is up to it. Unfortunately, just reading the FAQ a see a few red flags. It doesn't allow importing encrypted keys. This is an automatic "nope" for me. Authentication is as big an issue as encryption, so I need to generate my own keys. But I'm not about to upload an unencrypted key to my phone. Also, they kind of avoid talking about the very important issue that who you are talking to is not secret. Like I said, IMHO for some applications it's not a big deal. But for some applications it is a huge deal and it's pretty important to warn people up front. This is not a replacement for Signal. Possibly with some work it could be useful in limited contexts. However it is important to understand that it can't be a replacement for Signal in general.

swiley 6y ago
> Also, they kind of avoid talking about the very important issue that who you are talking to is not secret. Which chat apps fix this? I’m sure the people operating signal know who you talk to.
- mikekchar 6y ago
  There are ways that they could know. It's not terribly easy, but I think it would be ingenuous to say it is impossible. With SMTP (which could easily be part of the delivery of email), it's in plaintext going over the public network :-)
  - swiley 6y ago
    Most popular mail servers encrypt smtp now, if it bothers you than you could use servers that require it.
- cyphar 6y ago
  For Signal, sealed sender in theory makes some progress towards fixing this problem[1] but given the service fundamentally uses a central server, you could pretty easily figure out who is messaging who. There was an experimental chat application called Ricochet[2] which used Tor hidden services to anonymise users' social graphs, but unfortunately that project is no longer developed for quite a while. Pond[3] was also a similar system (though it was designed to solve the email problem and also aimed to solve some of the timing attacks against Tor by being a delayed-message protocol). I personally use Matrix[4] on my own homesever which appears to be the most privacy-preserving choice these days -- only the homeservers involved in a conversation ever see the messages. Unfortunately a lot of people use matrix.org as their homeserver (meaning they in theory have everyone's social graph) but for chats with most of my family and friends that isn't a problem (they are either on my homeserver or on their own). [1]: https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ [2]: https://ricochet.im/ https://ricochet.im/ [3]: https://github.com/agl/pond https://github.com/agl/pond [4]: https://matrix.org/ https://matrix.org/
  - Multicomp 6y ago
    Ricochet got replaced by cwtch which can be found below. I'm hopeful to start using this app to replace signal once it exits alpha. https://git.openprivacy.ca/cwtch.im/ui/releases https://git.openprivacy.ca/cwtch.im/ui/releases
  - tialaramex 6y ago
    > but given the service fundamentally uses a central server, you could pretty easily figure out who is messaging who. How? In Signal's design nobody ends up knowing this except the sender and recipient. As a Matrix enthusiast with their own "Homeserver" what you're doing is basically like dressing in head-to-foot desert camouflage gear to stand in Times Square. I guess it does do something, but maybe not what you think it does.
    - cyphar 6y ago
      > How? In Signal's design nobody ends up knowing this except the sender and recipient. The most obvious one is fairly basic traffic correlation using the IPs and timing information. You can figure out which IPs are communicating with which recipients (because the recipient of a message is necessarily public to the server, the device connects to the Signal servers to send the message, and everything is routed through servers controlled by a single party) as well as the IPs of recipients. When combined with timing information and the knowledge that users are only going to be able to talk to at most a few people simultaneously, you find that two people in the same IP-based social graph sending messages with the other person as a recipient at the same time are probably talking to each other. I'm not saying that Signal is doing this, I'm just saying that it is possible because of the design. This is basically the same reason why single-node VPNs cannot protect your anonymity against internal (and some external) threats and why something like Tor is needed to solve the problem. And note that this isn't even a slightly controversial statement -- it's even mentioned in the blog post announcing the "sealed sender" feature[1]: > In particular, additional resistance to traffic correlation via timing attacks and IP addresses are areas of ongoing development. We could argue about what "additional" means in this context, but given the design of the service I'm pretty sure they're just referring to their logging policies and Intel SGX usage. > what you're doing is basically like dressing in head-to-foot desert camouflage gear to stand in Times Square I don't understand the point you're making. If I'm talking in a public room, then obviously the messages are public. But if I'm only talking with folks on the same homeserver as me (or on homeservers they run) then only our homeservers know about our communications. Without tools like Ricochet there isn't (as far as I know) a way to get more metadata protection as easily. Don't get me wrong, it definitely isn't perfect and I wish it provided more protection -- but it is practically no worse than Signal in this respect (and it is significantly better for rooms that don't have :matrix.org users in them -- which is something I explicitly mentioned in my original comment). [1]: https://signal.org/blog/sealed-sender/#the-future-is-in-transit https://signal.org/blog/sealed-sender/#the-future-is-in-tran...
christefano 6y ago
> Unfortunately, just reading the FAQ a few red flags. It doesn’t allow importing encrypted keys. This is an automatic “nope” for me. This is answered in the FAQ: Can I re-use my existing private key? Yes. The best way is to send an Autocrypt Setup Message from the other e-mail client. Look for something like Start Autocrypt Setup Transfer in the settings of the other client and follow the instructions shown there. Alternatively, you can import the key manually in “Advanced settings / Manage private keys”. Caution: Make sure the key is not protected by a password, or remove the password beforehand. If you don’t have a key or don’t even know you would need one - don’t worry: Delta Chat generates one as needed, you don’t have to hit a button for it.
- cyphar 6y ago
  I think you missed the point GP was making. To quote: > Unfortunately, just reading the FAQ a few red flags. It doesn’t allow importing encrypted keys. [emphasis added] To which you responded with: > Alternatively, you can import the key manually in “Advanced settings / Manage private keys”. Caution: Make sure the key is not protected by a password, or remove the password beforehand. [emphasis added] GP is talking about it using a key which is encrypted with a passphrase, and it seems you agree that this isn't supported (otherwise why would it ask for you to decrypt the key on import?).

swiley 6y ago

> Also, they kind of avoid talking about the very important issue that who you are talking to is not secret. Which chat apps fix this? I’m sure the people operating signal know who you talk to.

mikekchar 6y ago
There are ways that they could know. It's not terribly easy, but I think it would be ingenuous to say it is impossible. With SMTP (which could easily be part of the delivery of email), it's in plaintext going over the public network :-)
- swiley 6y ago
  Most popular mail servers encrypt smtp now, if it bothers you than you could use servers that require it.
cyphar 6y ago
For Signal, sealed sender in theory makes some progress towards fixing this problem[1] but given the service fundamentally uses a central server, you could pretty easily figure out who is messaging who. There was an experimental chat application called Ricochet[2] which used Tor hidden services to anonymise users' social graphs, but unfortunately that project is no longer developed for quite a while. Pond[3] was also a similar system (though it was designed to solve the email problem and also aimed to solve some of the timing attacks against Tor by being a delayed-message protocol). I personally use Matrix[4] on my own homesever which appears to be the most privacy-preserving choice these days -- only the homeservers involved in a conversation ever see the messages. Unfortunately a lot of people use matrix.org as their homeserver (meaning they in theory have everyone's social graph) but for chats with most of my family and friends that isn't a problem (they are either on my homeserver or on their own). [1]: https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ [2]: https://ricochet.im/ https://ricochet.im/ [3]: https://github.com/agl/pond https://github.com/agl/pond [4]: https://matrix.org/ https://matrix.org/
- Multicomp 6y ago
  Ricochet got replaced by cwtch which can be found below. I'm hopeful to start using this app to replace signal once it exits alpha. https://git.openprivacy.ca/cwtch.im/ui/releases https://git.openprivacy.ca/cwtch.im/ui/releases
- tialaramex 6y ago
  > but given the service fundamentally uses a central server, you could pretty easily figure out who is messaging who. How? In Signal's design nobody ends up knowing this except the sender and recipient. As a Matrix enthusiast with their own "Homeserver" what you're doing is basically like dressing in head-to-foot desert camouflage gear to stand in Times Square. I guess it does do something, but maybe not what you think it does.
  - cyphar 6y ago
    > How? In Signal's design nobody ends up knowing this except the sender and recipient. The most obvious one is fairly basic traffic correlation using the IPs and timing information. You can figure out which IPs are communicating with which recipients (because the recipient of a message is necessarily public to the server, the device connects to the Signal servers to send the message, and everything is routed through servers controlled by a single party) as well as the IPs of recipients. When combined with timing information and the knowledge that users are only going to be able to talk to at most a few people simultaneously, you find that two people in the same IP-based social graph sending messages with the other person as a recipient at the same time are probably talking to each other. I'm not saying that Signal is doing this, I'm just saying that it is possible because of the design. This is basically the same reason why single-node VPNs cannot protect your anonymity against internal (and some external) threats and why something like Tor is needed to solve the problem. And note that this isn't even a slightly controversial statement -- it's even mentioned in the blog post announcing the "sealed sender" feature[1]: > In particular, additional resistance to traffic correlation via timing attacks and IP addresses are areas of ongoing development. We could argue about what "additional" means in this context, but given the design of the service I'm pretty sure they're just referring to their logging policies and Intel SGX usage. > what you're doing is basically like dressing in head-to-foot desert camouflage gear to stand in Times Square I don't understand the point you're making. If I'm talking in a public room, then obviously the messages are public. But if I'm only talking with folks on the same homeserver as me (or on homeservers they run) then only our homeservers know about our communications. Without tools like Ricochet there isn't (as far as I know) a way to get more metadata protection as easily. Don't get me wrong, it definitely isn't perfect and I wish it provided more protection -- but it is practically no worse than Signal in this respect (and it is significantly better for rooms that don't have :matrix.org users in them -- which is something I explicitly mentioned in my original comment). [1]: https://signal.org/blog/sealed-sender/#the-future-is-in-transit https://signal.org/blog/sealed-sender/#the-future-is-in-tran...

christefano 6y ago

> Unfortunately, just reading the FAQ a few red flags. It doesn’t allow importing encrypted keys. This is an automatic “nope” for me. This is answered in the FAQ: Can I re-use my existing private key? Yes. The best way is to send an Autocrypt Setup Message from the other e-mail client. Look for something like Start Autocrypt Setup Transfer in the settings of the other client and follow the instructions shown there. Alternatively, you can import the key manually in “Advanced settings / Manage private keys”. Caution: Make sure the key is not protected by a password, or remove the password beforehand. If you don’t have a key or don’t even know you would need one - don’t worry: Delta Chat generates one as needed, you don’t have to hit a button for it.

cyphar 6y ago
I think you missed the point GP was making. To quote: > Unfortunately, just reading the FAQ a few red flags. It doesn’t allow importing encrypted keys. [emphasis added] To which you responded with: > Alternatively, you can import the key manually in “Advanced settings / Manage private keys”. Caution: Make sure the key is not protected by a password, or remove the password beforehand. [emphasis added] GP is talking about it using a key which is encrypted with a passphrase, and it seems you agree that this isn't supported (otherwise why would it ask for you to decrypt the key on import?).