3 ms·

Nobody can verify backend code though, that's always an issue.

jraph 3y ago
Signal is e2ee. The point of e2ee is that you can not trust the backend code (except for clear data it actually manipulates - which is still an issue indeed - Message contents are encrypted though) This is the case for any e2ee solutions. For instance my company develops CryptPad [1], which is a full open source office suite with e2ee. The server admins can't access your content and you don't need to trust the backend, which just passes messages and store encrypted messages. This is the whole point. e2ee has drawbacks: it's very difficult, if not impossible, to provide indexed search for encrypted content on the server, the client needs to do it which might be impractical. [1] https://cryptpad.org/ https://cryptpad.org/
- dadoomer 3y ago
  I really like cryptpad. Thank you for developing it. I have used it a few times in a professional setting even when there is no need for end-to-end encryption, and it is a good experience so far. I encourage others to try it .
- NayamAmarshe 3y ago
  > Signal is e2ee. That still does not change anything though. The backend is unverifiable, that's a fact. Why talk about E2EE, I wasn't really talking about that. Signal for a whole year was running a different server code and nobody even could tell that they added some cryptocoin stuff. On top of that, metadata, server connection and anything other than the message content is all at the mercy of the server owner.
  - bentley 3y ago
    > On top of that, metadata, server connection and anything other than the message content is all at the mercy of the server owner. Except to the extent that the client is explicitly designed to minimize what metadata is exposed to the server.
    - NayamAmarshe 3y ago
      Yes but that still does not take care of the API logging problem. The server can log your IP, origin of request, client details and everything related to an API call. That's what I'm mainly talking about.
      - tapoxi 3y ago
        But due to sealed sender it doesn't know who is sending the message, only who is receiving messages. It has your IP, but of course it needs that, as well as every piece of network gear along the route. If you want to hide that you'd need Tor or a VPN.
  - e12e 3y ago
    > That still does not change anything though. Of course it does. Just like PGP works fine over untrusted channels - like if I posted a gnupg ascii-armored message here. e2ee makes all the difference - if two trusted and mutually authenticated clients are communicating with proper e2ee - the best an attacker can do is traffic analysis and denial of service...?
    - hutzlibu 3y ago
      "the best an attacker can do is traffic analysis and denial of service...? " That's already a lot. If the evil secret police knows when and with whom you texted, then they don't even need to know the text of the messages, to link you to the opposition. And then just extract you and then the password with force to get the rest.
      - DoctorOW 3y ago
        Relevant: https://xkcd.com/538/ https://xkcd.com/538/
        hutzlibu 3y ago
        It is, but encryption is still useful, as not everyone on this planet is in reach of evil secret police and their goons and wrenches are limited.
      - e12e 3y ago
        It certainly is a lot. It's enough for a drone strike. But almost by definition, if you have a back-end, there will be meta-data. There's been a few attempts at getting around it, with "one-to-many" (eg opaque PGP posts to Usenet groups), Mixmasters (remailers) or onion routing. None are AFAIK truly practical with a state-level adversary. e2ee is a good start, that doesn't mean you don't need to analyse the risks.
  - beepbooptheory 3y ago
    If, as we are saying, the client code is public and one can theoretically analyze the code and prove that messages that go out are indeed only going out encrypted, then that must change something here? At that point at least, you can only be suspicious of the cryptography itself, but I believe that is public too.
    - NayamAmarshe 3y ago
      I was talking about the relevant data points other than the message content, mainly metadata. The server can not only log IPs, but also locations, client details and a lot more. The API calls aren't proxied, they're more or less direct.
  - akvadrako 3y ago
    First, it doesn't matter a lot if the backend is verifiable with E2E, that's the point. Second, some sensitive parts of Signal backend are verifiable, assuming Intel is not compromised, because they use Intel SGX.
    - NayamAmarshe 3y ago
      > First, it doesn't matter a lot if the backend is verifiable with E2E, that's the point. E2EE is only useful for content that is encrypted. Not the API calls themselves.
  - renewiltord 3y ago
    That's the interesting thing about being E2EE. You don't need to verify the backend. This is a private key and ETH wallet with a separator that is obvious on decryption: YSBwcml2YXRlIGtleSBhbmQgRVRIIHdhbGxldCB3aXRoIGEgc2VwYXJhdG9yIHRoYXQgaXMgb2J2aW91cyBvbiBkZWNyeXB0aW9uCg== Use whatever backend you want to store that.
  - beckford 3y ago
    Completely agree. For a while I did run a fork of the Signal Server. Beyond the sheer difficulty getting it to run without the server being updated for a year during the mobilecoin launch, it was extremely disconcerting to see PHONE NUMBERS spread throughout the log messages. It doesn't take much imagination to see how you can build a network of who you are talking to (etc.) from this log information. While it is quite possible that they had some non-default log configuration (and hopefully the metadata leaking in the logs is fixed), if you can't run the server you can't check what data is being leaked. Take the E2EE claim with a grain of salt if it is difficult to run a server.
    - gray_charger 3y ago
      > ...it was extremely disconcerting to see PHONE NUMBERS spread throughout the log messages. It doesn't take much imagination to see how you can build a network of who you are talking to (etc.) from this log information. The intent of Signal is to provide confidentiality of message content, not any sort of anonymity. This covers like 90+% of user's threat models and it's focusing on one problem makes it very effective at solving that problem. If one also needs anonymity then communication should happen over something like Tor or I2P.

Signal is e2ee. The point of e2ee is that you can not trust the backend code (except for clear data it actually manipulates - which is still an issue indeed - Message contents are encrypted though) This is the case for any e2ee solutions. For instance my company develops CryptPad [1], which is a full open source office suite with e2ee. The server admins can't access your content and you don't need to trust the backend, which just passes messages and store encrypted messages. This is the whole point. e2ee has drawbacks: it's very difficult, if not impossible, to provide indexed search for encrypted content on the server, the client needs to do it which might be impractical. [1] https://cryptpad.org/ https://cryptpad.org/

dadoomer 3y ago
I really like cryptpad. Thank you for developing it. I have used it a few times in a professional setting even when there is no need for end-to-end encryption, and it is a good experience so far. I encourage others to try it .
NayamAmarshe 3y ago
> Signal is e2ee. That still does not change anything though. The backend is unverifiable, that's a fact. Why talk about E2EE, I wasn't really talking about that. Signal for a whole year was running a different server code and nobody even could tell that they added some cryptocoin stuff. On top of that, metadata, server connection and anything other than the message content is all at the mercy of the server owner.
- bentley 3y ago
  > On top of that, metadata, server connection and anything other than the message content is all at the mercy of the server owner. Except to the extent that the client is explicitly designed to minimize what metadata is exposed to the server.
  - NayamAmarshe 3y ago
    Yes but that still does not take care of the API logging problem. The server can log your IP, origin of request, client details and everything related to an API call. That's what I'm mainly talking about.
    - tapoxi 3y ago
      But due to sealed sender it doesn't know who is sending the message, only who is receiving messages. It has your IP, but of course it needs that, as well as every piece of network gear along the route. If you want to hide that you'd need Tor or a VPN.
- e12e 3y ago
  > That still does not change anything though. Of course it does. Just like PGP works fine over untrusted channels - like if I posted a gnupg ascii-armored message here. e2ee makes all the difference - if two trusted and mutually authenticated clients are communicating with proper e2ee - the best an attacker can do is traffic analysis and denial of service...?
  - hutzlibu 3y ago
    "the best an attacker can do is traffic analysis and denial of service...? " That's already a lot. If the evil secret police knows when and with whom you texted, then they don't even need to know the text of the messages, to link you to the opposition. And then just extract you and then the password with force to get the rest.
    - DoctorOW 3y ago
      Relevant: https://xkcd.com/538/ https://xkcd.com/538/
      - hutzlibu 3y ago
        It is, but encryption is still useful, as not everyone on this planet is in reach of evil secret police and their goons and wrenches are limited.
    - e12e 3y ago
      It certainly is a lot. It's enough for a drone strike. But almost by definition, if you have a back-end, there will be meta-data. There's been a few attempts at getting around it, with "one-to-many" (eg opaque PGP posts to Usenet groups), Mixmasters (remailers) or onion routing. None are AFAIK truly practical with a state-level adversary. e2ee is a good start, that doesn't mean you don't need to analyse the risks.
- beepbooptheory 3y ago
  If, as we are saying, the client code is public and one can theoretically analyze the code and prove that messages that go out are indeed only going out encrypted, then that must change something here? At that point at least, you can only be suspicious of the cryptography itself, but I believe that is public too.
  - NayamAmarshe 3y ago
    I was talking about the relevant data points other than the message content, mainly metadata. The server can not only log IPs, but also locations, client details and a lot more. The API calls aren't proxied, they're more or less direct.
- akvadrako 3y ago
  First, it doesn't matter a lot if the backend is verifiable with E2E, that's the point. Second, some sensitive parts of Signal backend are verifiable, assuming Intel is not compromised, because they use Intel SGX.
  - NayamAmarshe 3y ago
    > First, it doesn't matter a lot if the backend is verifiable with E2E, that's the point. E2EE is only useful for content that is encrypted. Not the API calls themselves.
- renewiltord 3y ago
  That's the interesting thing about being E2EE. You don't need to verify the backend. This is a private key and ETH wallet with a separator that is obvious on decryption: YSBwcml2YXRlIGtleSBhbmQgRVRIIHdhbGxldCB3aXRoIGEgc2VwYXJhdG9yIHRoYXQgaXMgb2J2aW91cyBvbiBkZWNyeXB0aW9uCg== Use whatever backend you want to store that.
- beckford 3y ago
  Completely agree. For a while I did run a fork of the Signal Server. Beyond the sheer difficulty getting it to run without the server being updated for a year during the mobilecoin launch, it was extremely disconcerting to see PHONE NUMBERS spread throughout the log messages. It doesn't take much imagination to see how you can build a network of who you are talking to (etc.) from this log information. While it is quite possible that they had some non-default log configuration (and hopefully the metadata leaking in the logs is fixed), if you can't run the server you can't check what data is being leaked. Take the E2EE claim with a grain of salt if it is difficult to run a server.
  - gray_charger 3y ago
    > ...it was extremely disconcerting to see PHONE NUMBERS spread throughout the log messages. It doesn't take much imagination to see how you can build a network of who you are talking to (etc.) from this log information. The intent of Signal is to provide confidentiality of message content, not any sort of anonymity. This covers like 90+% of user's threat models and it's focusing on one problem makes it very effective at solving that problem. If one also needs anonymity then communication should happen over something like Tor or I2P.