Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technology preview: Private contact discovery for Signal

signal.org

Post reply on HN
Print view View original

31–40 of 169 posts

Re: Technology preview: Private contact discovery for Signal

#31

Post by ianmiers »

Confiks wrote: 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…

Don't "trust us" is not the same thing as you don't have trust anyone.

Before this, you had to trust Open Whisper Systems was not coerced and that Intel had not been coerced into backdooring their hardware.

Now, you need only trust that Intel hasn't backdoored their hardware.

Its not perfect, but its better. Especially since its entirely plausible, from a legal perspective, that Open Whisper Systems might be compelled to record any contact data they get. It is comparatively less plausible that a court might compel Intel to backdoor their code in order to enable an order against Open Whisper Systems. And that is what would have to happen here.

Re: Technology preview: Private contact discovery for Signal

#32

Post by zeveb »

> 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 transmitting something which represents the full set of both parties, which is a non-starter when one of the sets contains at least 10 million records.' This is just flat-out wrong though: the sets to be intersected are the contacts of two users, not Signal's registered users and the contacts of one user.

[0] https://signal.org/blog/contact-discovery/

Re: Technology preview: Private contact discovery for Signal

#33

Post by bascule »

> "It gets worse! The amount of encrypted RAM available to an enclave is limited to 128MB, which isn’t enough to store a large data set of registered users."

(So they used ORAM)

That's all very neat, but before a 128MB limit scares anyone off from playing with SGX, it's no longer a limit.

As of the Linux SGX SDK v1.9, enclaves can be up to 64GB (31.75GB heap space and 31.625GB buffers). The Baidu Rust SGX SDK supports this, for example:

https://github.com/baidu/rust-sgx-sdk#v020-release

Re: Technology preview: Private contact discovery for Signal

#34

Post by bascule »

zeveb wrote: 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 bootstrapping problem?

Re: Technology preview: Private contact discovery for Signal

#36

Post by mintplant »

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.

For the uninitiated, stickers are essentially a UI layer on top of image sending. Each user has a collection of stickers which they can add images to. This collection can be scrolled through quickly and any sticker can be sent to a chat with a tap, like a sort of custom emoji. Other users who see a sticker can add it to their own local collection by tapping on the sticker message. I see no technical reason why this couldn't be built on top of the Signal Protocol.

Re: Technology preview: Private contact discovery for Signal

#37

Post by scienhack »

It is actually really neat how DRM tech is being reversed to benefit the consumer and privacy for once!

Almost daily you read about yet another new "innocent" tech being exploited and used for some corporate gain, taking advantage of the end-users. It's refreshing to see it go the other way!

Re: Technology preview: Private contact discovery for Signal

#38

Post by kuschku »

cvwright wrote: post #28
kuschku wrote: post #13

Considering that Signal is advertised (with Snowden as face) for people who need privacy from governments (including the US government), I am doubtful if this is useful for the advertised purpose. (For normal users this is already overkill, of course). Even if we assume the NSA has no backdoors in the secure enclave, there have been countless demonstrations against secure enclaves in today’s real-world processors on…

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.

Re: Technology preview: Private contact discovery for Signal

#39

Post by schoen »

mintplant wrote: post #36

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/

Re: Technology preview: Private contact discovery for Signal

#40

Post by Ar-Curunir »

bascule wrote: post #33

> "It gets worse! The amount of encrypted RAM available to an enclave is limited to 128MB, which isn’t enough to store a large data set of registered users." (So they used ORAM) That's all very neat, but before a 128MB limit scares anyone off from playing with SGX, it's no longer a limit. As of the Linux SGX SDK v1.9, enclaves can be up to 64GB (31.75GB heap space and 31.625GB buffers). The Baidu Rust SGX SDK support…

Just to clarify, they didn't use ORAM, but designed a special algorithm for their specific access pattern. In particular, they do a linear scan of the entire user database, whereas ORAM would afford them polylogarithmic running time.
Post reply on HN