zlacker

Do you have a reference for the claim that your full contact list is uploaded to servers? That seems important since their privacy policy says that they only use hashes, and it can’t be dependent on SGX since it runs on non-Intel hardware:

https://signal.org/legal/#privacy-policy

>>acdha+(OP)
The method is explained here: https://signal.org/blog/private-contact-discovery/

Yes, it's hashes of phone numbers instead of the phone numbers themselves, but that's a detail. Phone numbers are easy to brute-force especially for people the protesters are worried about, as well as easy to build rainbow tables for.

>>est31+a2
I think you might want a better way of phrasing that: it’s not the “full contact list” - most people would assume that includes names and all of the other metadata - and since it’s rate-limited there’s an interesting trade off where it’s not easy to brute-force but it is targetable if you are trying to track specific known people.

>>acdha+(OP)
SGX is for the servers not the clients. Their enclave is open source so you can theoretically audit it using RA.

I say theoretically because these schemes all have a core problem when they're not federated - you have no idea what your client is really doing and it's the client performing remote attestation with the enclave. You have no control over it. It could update tomorrow and switch every last bit of encryption off. Or it could do RA but not pin the enclave hash to anything audited (i.e. it accepts any enclave signed by Signal).

It's not a theoretical problem. Facebook say that WhatsApp is end to end encrypted, in the same way as Signal. That didn't stop them blocking people from forwarding links related to coronavirus. The literal and entire point of E2E cryptography is to stop them monitoring and interfering with people's communications, Facebook have been assuring governments for years they're powerless to do that, but of course the moment Facebook wanted to fight "misinformation" it all went out the window.

Fundamentally Signal and WhatsApp can never provide meaningful encryption or privacy. They don't allow alternative clients, so regardless of how much code they throw into the mix they control the entire pipe end to end and can just as easily switch it off again. And the moment their employees feel they have a sufficiently good motivation, it'll happen again.

>>acdha+K2
The name, profile pic, etc. is less relevant than the social graph itself. State actors already have phone number <-> name mappings at least about their own residents. If you are just curious about who's visa applications to deny because according to data collected by your IMSI-catcher many of their contacts have participated in an anti-government protest, then the name etc. isn't really relevant.

>>est31+a2
I would disagree with the "that's a detail" statement. Properly salted hashes make building a social network graph much more difficult. It's only relatively easy to brute-force a single number.

>>jwr+n8
I don’t think they are salted. When someone joins signal they are compared to your hashes. That is how you get notified that one of your contacts have joined signal.

If they were all individually salted, there would be no way to compare against new joiners.

>>est31+04
Yes, I know. My point was that a better term might help you make your point without sounding like you’re claiming something different.

>>thu211+H3
> That didn't stop [facebook] blocking people from forwarding links related to coronavirus.

Source?

>>im3w1l+bB
https://duckduckgo.com/?q=facebook+whatsapp+covid+forwarding...

Pick any version of the story. Or read their blog post:

https://blog.whatsapp.com/Keeping-WhatsApp-Personal-and-Priv...

How do they know a message is forwarded? The encryption is meant to make identical plaintexts encrypt to different ciphertexts, so obviously they must be leaking the forwarding status in unencrypted parts of the message. And why is an encrypted service trying to combat misinformation to start with - isn't that a contradiction in terms? These things raise difficult questions. You'd hope that once a service decides to go fully encrypted, its staff would believe that what kind of information going over it or how accurate that is, isn't any longer their concern.

>>est31+a2
It's truncated hashes, not full hashes. So you don't see exactly which phone number it is, you get a bucket and the client checks if the full hash is in the bucket. Which is far from perfect, but it's a little better than the full hash.

>>thu211+WL
I see. Given this clarification, I would argue that your original claim was misleading.

>>im3w1l+9H1
OK. Where is the argument then? You've asserted, but not argued.

Today, Signal is claiming their encryption means the only data they have to give to government is date of install and last use. In the past they also claimed WhatsApp uses the same cryptography as them, at least for messages. These two claims cannot both be true. If there's some incredibly subtle detail that means deliberately exposing forwarding metadata in WhatsApp but not Signal they should really clarify that because it's not something I've ever seen a discussion of, and it doesn't follow from the cryptography they're using.

>>thu211+WL
There’s a counter added to the encrypted portion of metadata of the message. The receiving client increments the counter by +1 if it forwards it. At some point, some client receives a message that has the maximum amount of forwards and thus the option to forward it won’t be shown by that client. This is handled in-app. An old or modified client won’t do anything with it, you can try it. It’s not a server-side thing but embedded in the E2EE’d data.

>>thu211+zX2
They can both be true. Signal Protocol for message encryption is something different than Signal the official Signal Protocol client. ;) That’s where the difference lies and why the statement can be true: WhatsApp uses Signal Protocol for its encryption, but WhatsApp isn’t Signal.