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

[tialaramex]

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 ]

[kyboren]

I see, thanks. I was confusing "logging" for logging the association between AuthCredential and UID rather than logging IP addresses. For what it's worth, Signal does allow connecting over Tor.