4 ms·

The point of this seems to be hiding the identity of users when they fetch or modify group attributes - but why? The user’s identity is otherwise known to the s

The point of this seems to be hiding the identity of users when they fetch or modify group attributes - but why? The user’s identity is otherwise known to the server: they know that account X was accessed by IP address Y, and that IP address Y fetched metadata for group Z, therefore account X is in group Z. They can also figure out group membership by tracking clusters of messages that are sent simultaneously. What am I missing?

0xCMP 7y ago
They do not know that information unless they’re monitoring on-the-server in the clear. They simply know they’re talking to Signal servers. This new feature protects in the case of Information Requests because they themselves don’t know who is in what groups.
- SheinhardtWigCo 7y ago
  You either have to trust the server operator not to keep logs, or assume they are keeping logs and _do_ know what groups you’re in. In either case, what is this fancy crypto scheme actually buying you?
  - Forbo 7y ago
    > You either have to trust the server operator not to keep logs You don't have to trust, you can verify. This has been proven in court: https://signal.org/bigbrother/eastern-virginia-grand-jury/ https://signal.org/bigbrother/eastern-virginia-grand-jury/
  - tptacek 7y ago
    The fancy crypto is what allows them not to (effectively) keep those logs in the first place. If you build this feature without the fancy crypto, then even if you say you're not logging this stuff, you (effectively) are, because your system depends on durable access to that metadata in order to function. This is, for instance, the major security difference between Signal and Wire. One strong indication you have that Signal isn't logging this stuff is that they had to wait until they were able to advance the state of the art in anonymous credentials in order to implement group access control at all.
    - SheinhardtWigCo 7y ago
      To verify the claim that my group message content is protected, I can examine the Signal client. I don’t have to trust the server operator whatsoever; I can independently confirm there is no way for them to see the content of my messages. In contrast, I cannot verify this new claim that my group memberships are protected. I have to trust them. I think you are basically saying: ‘well, they built all this crypto that is only useful if you believe they’re not logging, so I believe they’re not logging.’
      - tptacek 7y ago
        No, what I'm saying is that without the cryptographic protections, a messaging provider can't claim not to be logging, because their serverside logic requires the log. Prior to doing this cryptographic work, Signal simply went without having these features at all.
        eximius 7y ago
        You're both right. The other poster's claim is that we cannot verify the code running on the server. They could support this new scheme AND just store every thing in plain text. We can only verify the interface is the same (because that's what we're using). But you're also right it would be a long con to go without these features for so long, develop state of the art cryptography to add them securely and privately, then not use that.
        kyboren 7y ago
        > They could support this new scheme AND just store every thing in plain text. Could they? I am not clear that this is possible. I thought the entire point of "Alice provides a zero-knowledge proof to the server that she possesses an AuthCredential matching some particular entry" is that the server learns nothing about Alice other than her possession of a matching AuthCredential. Indeed, the paper says: "Because of the zero-knowledge property, the server has assurance that the user possesses such an auth credential without learning the UID certified by the credential, or other information that might link this use of the credential to other uses or to credential issuance." It would be nice if someone more knowledgeable could confirm whether it is indeed possible for Signal to compromise user privacy while using this scheme. Is SheinhardtWigCo right when they write, "In contrast, I cannot verify this new claim that my group memberships are protected. I have to trust them."?

0xCMP 7y ago

They do not know that information unless they’re monitoring on-the-server in the clear. They simply know they’re talking to Signal servers. This new feature protects in the case of Information Requests because they themselves don’t know who is in what groups.

SheinhardtWigCo 7y ago
You either have to trust the server operator not to keep logs, or assume they are keeping logs and _do_ know what groups you’re in. In either case, what is this fancy crypto scheme actually buying you?
- Forbo 7y ago
  > You either have to trust the server operator not to keep logs You don't have to trust, you can verify. This has been proven in court: https://signal.org/bigbrother/eastern-virginia-grand-jury/ https://signal.org/bigbrother/eastern-virginia-grand-jury/
- tptacek 7y ago
  The fancy crypto is what allows them not to (effectively) keep those logs in the first place. If you build this feature without the fancy crypto, then even if you say you're not logging this stuff, you (effectively) are, because your system depends on durable access to that metadata in order to function. This is, for instance, the major security difference between Signal and Wire. One strong indication you have that Signal isn't logging this stuff is that they had to wait until they were able to advance the state of the art in anonymous credentials in order to implement group access control at all.
  - SheinhardtWigCo 7y ago
    To verify the claim that my group message content is protected, I can examine the Signal client. I don’t have to trust the server operator whatsoever; I can independently confirm there is no way for them to see the content of my messages. In contrast, I cannot verify this new claim that my group memberships are protected. I have to trust them. I think you are basically saying: ‘well, they built all this crypto that is only useful if you believe they’re not logging, so I believe they’re not logging.’
    - tptacek 7y ago
      No, what I'm saying is that without the cryptographic protections, a messaging provider can't claim not to be logging, because their serverside logic requires the log. Prior to doing this cryptographic work, Signal simply went without having these features at all.
      - eximius 7y ago
        You're both right. The other poster's claim is that we cannot verify the code running on the server. They could support this new scheme AND just store every thing in plain text. We can only verify the interface is the same (because that's what we're using). But you're also right it would be a long con to go without these features for so long, develop state of the art cryptography to add them securely and privately, then not use that.
        kyboren 7y ago
        > They could support this new scheme AND just store every thing in plain text. Could they? I am not clear that this is possible. I thought the entire point of "Alice provides a zero-knowledge proof to the server that she possesses an AuthCredential matching some particular entry" is that the server learns nothing about Alice other than her possession of a matching AuthCredential. Indeed, the paper says: "Because of the zero-knowledge property, the server has assurance that the user possesses such an auth credential without learning the UID certified by the credential, or other information that might link this use of the credential to other uses or to credential issuance." It would be nice if someone more knowledgeable could confirm whether it is indeed possible for Signal to compromise user privacy while using this scheme. Is SheinhardtWigCo right when they write, "In contrast, I cannot verify this new claim that my group memberships are protected. I have to trust them."?