zlacker

[parent] [thread] 18 comments
1. est31+(OP)[view] [source] 2020-06-05 09:44:03
> Signal DOES NOT get your full contact list

The full contact list is uploaded to Signal servers by the phones. The only protection layer that users have is the questionable security of Intel's SGX.

It's still much better than what WhatsApp is doing, just not a black and white situation.

To add a point to your list: Signal does not have automatic cloud backup of messages, unlike WhatsApp. On WhatsApp, 30% of users have cloud backups enabled [1], meaning that you can basically assume that any reasonably sized group's messages can be accessed by people who have subpoena-power over Google (chance that there is no backup-enabled account in a group of n people is (1-0.3)^n... for 6 people it's already 12%).

[1]: https://telegra.ph/whatsapp-backdoor-01-16

replies(2): >>acdha+k3 >>jwr+p4
2. acdha+k3[view] [source] 2020-06-05 10:12:42
>>est31+(OP)
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

replies(2): >>est31+u5 >>thu211+17
3. jwr+p4[view] [source] 2020-06-05 10:21:00
>>est31+(OP)
Not the full contact list, just hashes.

That was exactly my point: few people know about this.

replies(2): >>est31+h5 >>CultOf+6q6
◧◩
4. est31+h5[view] [source] [discussion] 2020-06-05 10:28:38
>>jwr+p4
A hash of the phone number is as good as the phone number itself. Given a list of all phone numbers in use, it's trivial to build a rainbow table for them. And many you can also brute-force.
◧◩
5. est31+u5[view] [source] [discussion] 2020-06-05 10:31:18
>>acdha+k3
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.

replies(3): >>acdha+46 >>jwr+Hb >>BCM43+8V
◧◩◪
6. acdha+46[view] [source] [discussion] 2020-06-05 10:36:41
>>est31+u5
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.
replies(1): >>est31+k7
◧◩
7. thu211+17[view] [source] [discussion] 2020-06-05 10:45:56
>>acdha+k3
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.

replies(1): >>im3w1l+vE
◧◩◪◨
8. est31+k7[view] [source] [discussion] 2020-06-05 10:50:52
>>acdha+46
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.
replies(1): >>acdha+Ug
◧◩◪
9. jwr+Hb[view] [source] [discussion] 2020-06-05 11:41:42
>>est31+u5
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.
replies(1): >>georgy+Ic
◧◩◪◨
10. georgy+Ic[view] [source] [discussion] 2020-06-05 11:54:42
>>jwr+Hb
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.

◧◩◪◨⬒
11. acdha+Ug[view] [source] [discussion] 2020-06-05 12:28:31
>>est31+k7
Yes, I know. My point was that a better term might help you make your point without sounding like you’re claiming something different.
◧◩◪
12. im3w1l+vE[view] [source] [discussion] 2020-06-05 14:49:16
>>thu211+17
> That didn't stop [facebook] blocking people from forwarding links related to coronavirus.

Source?

replies(1): >>thu211+gP
◧◩◪◨
13. thu211+gP[view] [source] [discussion] 2020-06-05 15:45:07
>>im3w1l+vE
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.

replies(2): >>im3w1l+tK1 >>CultOf+yp6
◧◩◪
14. BCM43+8V[view] [source] [discussion] 2020-06-05 16:17:05
>>est31+u5
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.
◧◩◪◨⬒
15. im3w1l+tK1[view] [source] [discussion] 2020-06-05 20:11:52
>>thu211+gP
I see. Given this clarification, I would argue that your original claim was misleading.
replies(1): >>thu211+T03
◧◩◪◨⬒⬓
16. thu211+T03[view] [source] [discussion] 2020-06-06 10:48:43
>>im3w1l+tK1
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.

replies(1): >>CultOf+Qp6
◧◩◪◨⬒
17. CultOf+yp6[view] [source] [discussion] 2020-06-07 22:07:21
>>thu211+gP
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.
◧◩◪◨⬒⬓⬔
18. CultOf+Qp6[view] [source] [discussion] 2020-06-07 22:09:20
>>thu211+T03
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.
◧◩
19. CultOf+6q6[view] [source] [discussion] 2020-06-07 22:11:39
>>jwr+p4
Actually Signal is uploading contacts with their first and lastname to the cloud now. Or is planning to do so. Read their blog about that f-ing PIN feature. Its explained there. I hope they don’t go through with it, I absolutely do not wish to use some cloud; not even Signal’s. My data should be 100% local. And that they’re gonna push this without a back-up feature for iOS feels a bit like them raising their middle finger to us.
[go to top]