Live data from Hacker News

Technology preview: Private contact discovery for Signal

signal.org

41–50 of 169 posts

Re: Technology preview: Private contact discovery for Signal

#41
post #39

In case someone from Open WhisperSystems is reading: please add stickers. Seriously, I know so many people who are on Telegram just because of its sticker system and won't consider anything without that feature. This comes up again and again in online discussions where Signal is mentioned, and it hurts to see all the care and effort the OWS team has put into providing real security rejected out of hand because of it.…

I find it really unfortunate that this is stopping people from adopting Signal. However, I believe that this feature was added last year: https://signal.org/blog/doodles-stickers-censorship/

No, that's a different feature with the same name. That allows you to quickly layer graphics from a built-in set on top of existing photos, like in Snapchat. The "stickers" I'm referring to, in the Telegram/WeChat/LINE sense, are essentially custom emojis, or macros for sending one of a collection of reaction images as its own message.

https://telegram.org/blog/stickers-revolution

Various communities absolutely rely on this style of communication, so it becomes a dealbreaking feature.

Re: Technology preview: Private contact discovery for Signal

#42
post #21
post #18

I don't really understand why this is an improvement on the existing architecture. In the current contact discovery implementation you need to fully trust the server, namely the open source component that is the contact discovery service. In this proposed new implementation, you still have to trust the server; you need to trust closed source processor hardware offering the Software Guard Extensions. Those extensions…

SGX attestation involves a key burned into e-fuses on processors at manufacture; the process was designed to prevent Intel from being able to derive keys used for individual enclaves. Obviously, Intel could have a malicious manufacturing process --- but then, that's the case for any piece of merchant silicon you'd use to build any computer.

If I'm reading the documentation [1][2] correctly, you're overselling the security. Verifying an SGX attestation requires trusting not only the integrity of the per-processor secret keys, but the honesty of an Intel-provided online verification API.

The API allows you to POST an attestation report to Intel's verification web service, and get back a response saying "OK" or "not OK". You can use TLS to verify that the authentication was done by Intel rather than a MITM, but there seems to be no cryptographic way to prevent Intel from simply lying to you. They don't offer any way for third-parties to verify attestation reports themselves. [3]

Is there something I'm misunderstanding?

[1]: https://software.intel.com/en-us/articles/intel-software-gua...

[2]: https://software.intel.com/sites/default/files/managed/ac/40...

[3]: https://software.intel.com/en-us/forums/intel-software-guard...

Re: Technology preview: Private contact discovery for Signal

#43
It doesn't say a word about running inside SGX without the insecure developer mode... or about the use of SGX meaning they're stuck with hardware which has the highly questionable ME layer.

SGX as an additive layer for things you can't make strongly private is interesting... though I wonder if it wouldn't have first made sense to implement a private intersection so that signal users wouldn't have to send numbers that are guaranteed to have no hits.

Re: Technology preview: Private contact discovery for Signal

#44
post #24
post #14

Earlier quoted context omitted.

The point of SGX is that the enclave is cryptographically verifiable. You can't simply emulate the enclave's software and interface; you also have to have the corresponding private key.

So is that key produced and provided by OWS? Or is it an Intel signed key? Either way, it's far from trustless, but it does provide a benefit in that if the initial setup was done correctly a compromise of OWS servers can no longer result in leaked contact hashes.

The key is created by Intel during CPU manufacturing process. Of course it's not trustless but it shortens the list of companies you have to trust.

Running remote software and attestation that it indeed is what you think without trusting anyone can be... hard.

Re: Technology preview: Private contact discovery for Signal

#45

In case someone from Open WhisperSystems is reading: please add stickers. Seriously, I know so many people who are on Telegram just because of its sticker system and won't consider anything without that feature. This comes up again and again in online discussions where Signal is mentioned, and it hurts to see all the care and effort the OWS team has put into providing real security rejected out of hand because of it.…

Is this referring to the same type of "sticker" I hear about in iMessage? Because I still have no idea what those are about, but I hear people talking about them all the time.

Re: Technology preview: Private contact discovery for Signal

#46
This is definitely interesting (and probably the first end-user-valuable SGX-on-server application I've seen), but there are two issues IMO:

1) Intel SGX isn't really capable of resisting moderately serious physical side channel attacks by someone with physical proximity or access to the server. It's decent for low-value, or widely deployed apps where compromise of a single instance only hurts once user, but for a central singular service, less so. Inferior to, say, a conventional HSM with code run inside it. (SGX would be great for client-side stuff, or for, say, a Tor or multi-server VPN server array, which is something I worked on using TXT before.)

2) Intel's still a gatekeeper on what SGX applications can be meaningfully distributed; to run in release-mode, you need a key signed by them, and to get this requires a commercial agreement. If you run in debug or pre-release, anyone with a debugger can pull keys.

If Intel were to fix the latter (even if it cost, say, $100 to get the signing rights, or some non-discriminatory "you must do X, Y and not A, B" were published), the former wouldn't be a deal-killer for some things. If the server operator were a mostly-trusted third party (e.g. a cloud provider), and the people writing and signing the code were never able to get physical access to the hardware, it might work a lot better in most server threat models.

In Signal's particular case it's probably true that most Signal users trust Moxie/OWS, and this is really about putting a much higher bar in place for government compulsion to tamper with or disclose the contact info, so this is a net win.

Re: Technology preview: Private contact discovery for Signal

#47
post #38

Earlier quoted context omitted.

This attitude is a big reason why doing constructive work in security is hard. Yes, there are huge challenges and lots of different attack vectors. No, that doesn't invalidate the progress that's made when someone invests a lot of time and effort to solve 80% of an extremely difficult problem. Sometimes it feels like you could solve world hunger and world peace, but unless you also gave everyone a puppy, half of the…

Well, it is a major step – but Moxie always sells his solutions, even if they’re just a puppy, as solutions for world hunger. As I mentioned, advertising with Snowden leads to a promise that Signal can not fulfill. Not even with this. But, you know, there is already a solution for all the issues here: Don’t use phone numbers, use usernames! As it turns out, that is far more private and secure.

> Don’t use phone numbers, use usernames! As it turns out, that is far more private and secure.

It is. But it's not convenient. Everyone has contact list with numbers and people want to talk to their friends immediately not call them for their ID for service X.

Re: Technology preview: Private contact discovery for Signal

#49
post #45

In case someone from Open WhisperSystems is reading: please add stickers. Seriously, I know so many people who are on Telegram just because of its sticker system and won't consider anything without that feature. This comes up again and again in online discussions where Signal is mentioned, and it hurts to see all the care and effort the OWS team has put into providing real security rejected out of hand because of it.…

Is this referring to the same type of "sticker" I hear about in iMessage? Because I still have no idea what those are about, but I hear people talking about them all the time.

That looks kinda similar, except it seems iMessage allows you to slap stickers in arbitrary positions on top of other messages, whereas the implementations I'm thinking of just treat a sticker as its own message. Also Apple has some sort of sticker store and approval process, whereas on Telegram for example anyone can add their own image files for use as stickers.

Re: Technology preview: Private contact discovery for Signal

#50
post #34
post #32

> There are a range of options that don’t work, like using bloom filters, encrypted bloom filters, sharded bloom filters, private information retrieval, or private set intersection. He just takes as a given that private set intersection doesn't work, and in the original 2014 document[0] writes, 'There are cryptographic protocols for performing privacy-preserving set intersections, but they generally involve transmitt…

Who are the two users in this case? How did they discover each other? From the OP: > "Very few people want to install a communication app, open the compose screen for the first time, and be met by an empty list of who they can communicate with." Signal needs to bootstrap itself automatically in order to solve this problem. Can you explain how two users doing a private set intersection of their contacts solves this bo…

The two users are two folks who wish to communicate who hold their phones back-to-back and let NFC validate who they each are. Both parties are now able to perform a private set intersection to find people whom they know in common who also use Signal, and are able to then use private set intersection with each of those people to find more.

The idea is that users bootstrap via the social graph of folks they physically know (or, of course, they could fall back to manually entering keys, for experts). Users place their trust in one another, rather than in the server.

Post reply on HN