[0xCMP]

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]

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?

[tptacek]

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]

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]

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]

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.

[tialaramex]

> They could support this new scheme AND just store every thing in plain text.

Store _what_ in plain text?

Right at the top of the article are some commonplace things other "chat" systems, even if they claim end-to-end encryption - store in a central database. Metadata, like the name of the group, a logo or "avatar" and then also the core fact of the group, a list of its members.

Signal's server doesn't end up knowing /any/ of those things. It doesn't need them for anything it does, so it never gets told what they are. It couldn't store them in plain text any more than it could your Signal messages.

With the proposed enhancement Signal's server would store the data so as to serialise access, but it would still be encrypted with keys the server does not have so it's meaningless to the server.

Members of each group learn a key (picked at random by the group's founding member) -- which Signal's server doesn't know -- and that key lets them decrypt the metadata about the group and encrypt new data if they e.g. decided to change the group's name, invite somebody to the group or remove someone from the group.

The part we can't _prove_ Signal is doing as a result of this work is the new use of Anonymous Credentials and Roles. Maybe Signal will actually let Alice add an entry to the members list for my group Carolines And Tiaras even though Alice isn't a member. This won't work very well, because since Alice isn't a member she can't add _correct_ entries, for example she can't add herself or a collaborator, but she can add gibberish and maybe annoy the group members.

[kyboren]

> 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."?

[Forbo]

> 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/