5 ms·

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 pro

by 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."?
        tialaramex 7y ago
        SheinhardtWigCo's central idea is that if someone receive a packet over the network it has an IP address in it, and that's the sender's "identity" and so the Signal servers can't avoid knowing Alice's "identity" when she does this, and then they can collect such data to try to re-assemble group membership in terms of IP address "identities". For example let's say a packet arrives from 10.20.30.40 [[ all IPs used are from 10/8 as examples I am aware that Signal probably rejects packets claiming to be from an RFC1918 network ]] which contains proof that group #1 member #4 has authorised adding a new member #8 SheinhardtWigCo believes this tells us that this identity (10.20.30.40) is a member of this group, group #1 and they suppose that Signal's server could in fact store this, and then perhaps later tell some Spooks a list of such members of group #1 and it could do this on a vast scale, so that it would be able to say for any "identity" (IP address) the list of all identities (IP addresses) which seem to be members of groups which that identity is also a member of. Now, I don't think Spooks would find that very useful, but there you go, that's what SheinhardtWigCo thinks is a big problem here. [ Edited to clarify early paragraph ]

by 0xCMP 7y ago

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."?
        tialaramex 7y ago
        SheinhardtWigCo's central idea is that if someone receive a packet over the network it has an IP address in it, and that's the sender's "identity" and so the Signal servers can't avoid knowing Alice's "identity" when she does this, and then they can collect such data to try to re-assemble group membership in terms of IP address "identities". For example let's say a packet arrives from 10.20.30.40 [[ all IPs used are from 10/8 as examples I am aware that Signal probably rejects packets claiming to be from an RFC1918 network ]] which contains proof that group #1 member #4 has authorised adding a new member #8 SheinhardtWigCo believes this tells us that this identity (10.20.30.40) is a member of this group, group #1 and they suppose that Signal's server could in fact store this, and then perhaps later tell some Spooks a list of such members of group #1 and it could do this on a vast scale, so that it would be able to say for any "identity" (IP address) the list of all identities (IP addresses) which seem to be members of groups which that identity is also a member of. Now, I don't think Spooks would find that very useful, but there you go, that's what SheinhardtWigCo thinks is a big problem here. [ Edited to clarify early paragraph ]