And, that software regularly re-sends that encrypted list to Signal's servers' SGX enclaves for their contact-discovery protocol.
So whether or not Signal, or some entity near/around it, "has" the contact list is a matter of how much users trust Intel™ SGX® (as well as the chain of processes that deliver/update the Signal software on-device.)
What they're moving towards is a design that looks like what Apple did with their HSM quorum system. The contact information we're talking about is encrypted clientside, but with (usually) a memorable pin. Without countermeasures, memorable PINs are very easy to attack; SGX allows them to artificially limit guesses. As a user, you retain a security dial on this: you can use a more complicated passcode than a 4-digit pin if you don't trust SGX.
Obtaining the whole database Signal maintains gives you ciphertext that you need to mount attacks on user-by-user (and to make those attacks, you'd have to break SGX). It doesn't simply give you the plaintext SQL database other messaging systems collect.
AFAIK, it prompts at first, maybe a few times, but then stops.
> Signal's software-on-device definitely has the contact list
Definitely not required at all. Signal can use its own contact list.
> that software regularly re-sends that encrypted list to Signal's servers' SGX enclaves for their contact-discovery protocol
The SGX enclaves are not for contact discovery. Contact discovery worked long before Signal implemented the SGX enclaves.
As I understand it: The SGX enclaves store a crypto key that Signal adds to the user's password, to enable data migration: Users tend to choose weak passwords; if Signal truly wants their data to be secure, strong passwords aren't realistic. Their solution is ingenious (IMHO): 1) Append a random key to strengthen the password chosen by the user. 2) A locally stored key would be a big problem for data migration, such as lost phones; the key would be lost too, and thus all the user data. 3) Therefore, they store the key centrally, as securely as possible (in the SGX enclave). That does make the key more vulnerable, but if you choose a strong password then it's irrelevant - the attacker needs to defeat both the key and your password. You can also disable this backup feature if you like. Some reading (partly because I might misremember a detail or two):
https://signal.org/blog/secure-value-recovery/
https://blog.cryptographyengineering.com/2020/07/10/a-few-th...
I am not sure how Signal backups work or that user contacts, encrypted, are backed up to the SGX enclave. Where does it say that?
> So whether or not Signal, or some entity near/around it, "has" the contact list is a matter of how much users trust Intel™ SGX® (as well as the chain of processes that deliver/update the Signal software on-device.)
Again, if you choose a strong password then you only need to trust yourself, and I think you can disable it altogether.
It's been re-prompting me for years. If there's a time it stops, I haven't found it.
> I am not sure how Signal backups work or that user contacts, encrypted, are backed up to the SGX enclave. Where does it say that?
You're talking about backups. I'm talking about contact-discovery, wherein the client regularly sends (hashed versions of) all the phone numbers from your contacts (if you've shared them with the app) to Signal's servers, to let you (& them!) know you're both on Signal. How else would you think the notification you get when someone in your contact list joins Signal is generated?
Signal's claim that these oft-repeated intersection operations leave no permanent records on their servers seemed (last I looked deeply) based on the SGX attestation: that your list is encrypted such that only the trusted code will process it. If Signal, or hackers, or Intel Corp, or the "Intel Community" can compromise SGX's guarantees, they can decrypt & log the full set of phone numbers uploaded.
So again, it reduces to how much you trust Intel™ SGX®.
(Also note that even if you do trust SGX, someone you've never met can, by having your phone number in their contacts, receive a notification when you join Signal. And separately from any SGX-mediated threats, a persistent attacker with privileged views of your devices' network traffic – such as via an ISP or mobile carrier – can get, via the volume & timing of traffic to and from Signal's servers, a pretty good idea of who you're talking to.)
> I'm talking about contact-discovery, wherein the client regularly sends (hashed versions of) all the phone numbers from your contacts (if you've shared them with the app) to Signal's servers
If they are hashed, why do you need to trust anyone?
Note it relies on SGX for privacy. (Anything they did earlier may have involved even more trust of Signal Inc's servers.)
Hashes across the (tiny!) space of all phone numbers are easy to reverse via brute-force.
But also, again: how do you think Signal is able to notify you when any phone number in your contacts – even if you're not in theirs! – first joins Signal?
I think novok is right in their uncle comment -- the decision to force people to use phone numbers, with all the related privacy problems, was to increase adoption. And we should be upfront on it: "Yes, Signal could have made things more private if they would allow usernames/emails/UINs... but instead they decided to force phone numbers to get market share as fast as possible. Yes, this means millions of people are forced to share the Signal contact list with Facebook and Google, but it was worth it -- look we have 40 million users now!"
There is nothing wrong with reducing user's privacy in order to get more market share. But let's not claim that this was for users' benefits.