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

21–30 of 169 posts

Re: Technology preview: Private contact discovery for Signal

#21

Post by tptacek »

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…

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.

Re: Technology preview: Private contact discovery for Signal

#24

Post by rightos »

tptacek wrote: post #14
sigil wrote: post #6

So this looks better than the status quo, but is it really trustless? Couldn't OWS still be compelled to drop something in that walks & talks like this secure enclave, but enables remote collection of address books? It seems we've just moved the trust down the stack into hardware. Kinda depressed that we seem to have given up on the scalable Private Set Intersection problem. It's a hard problem but an important one f…

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.

Re: Technology preview: Private contact discovery for Signal

#26

Post by [deleted] »

tptacek wrote: post #14
sigil wrote: post #6

So this looks better than the status quo, but is it really trustless? Couldn't OWS still be compelled to drop something in that walks & talks like this secure enclave, but enables remote collection of address books? It seems we've just moved the trust down the stack into hardware. Kinda depressed that we seem to have given up on the scalable Private Set Intersection problem. It's a hard problem but an important one f…

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.

[deleted]

Re: Technology preview: Private contact discovery for Signal

#27

Post by permanentdecaf »

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…

I am by no means an SGX expert, but my understanding has been that it allows you to shorten the "trust stack."

What you're referring to as "the server" is really a technology stack that starts with the CPU hardware and extends to the service operator. Without SGX, the trust stack probably looks something like: Intel, the OS, the VM, the cloud provider (Amazon, Google, Microsoft), the server software, the server operator.

Any of those points on the trust stack can be compromised by their principals or by an attacker (for example, Amazon could choose to interfere with Signal, or someone could hack Amazon and do the same). This is true for the OS, the software, the service provider, and everything else in the stack. Users have to trust all of those points, and additionally trust them not to be compromised.

SGX shortens the trust stack all the way down to the CPU. It takes the OS, the VM, the cloud provider, the service operator, and everything else out of the equation. Clients no longer have to trust any of them, either to be honest or to avoid compromise.

If trusting the CPU isn't acceptable to you, then that might be a bigger problem than you realize, since all computing has to. If you'd rather put your trust in AES, the problem is that you still have to trust the CPU to perform AES the way you would like it to.

Re: Technology preview: Private contact discovery for Signal

#28

Post by cvwright »

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 security community would still complain.

(And then there's always someone who wanted a kitten instead of a puppy...)

Re: Technology preview: Private contact discovery for Signal

#29

Post by jcrawfordor »

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…

A problem I see a lot in this community when it comes to security is letting perfect be the enemy of good.

Yes, this is vulnerable to an effort by Intel, but that's still a significant increase in complexity and capital required to pull of an attack. Really, "still vulnerable to malicious insertion by the hardware vendor" is probably one of the most positive things you can say about a security system, as generally, especially when it comes to privacy, there are many attack vectors that are _so much easier_. For instance, OWS itself.

The improvement here is reducing the attack surface. Yes, that doesn't look like an improvement if you choose to look only at the particular part of the attack surface that this change doesn't address. But in real terms it is a substantial improvement.

Re: Technology preview: Private contact discovery for Signal

#30

Post by mtgx »

In a previous comment on that Moxie interview story posted here, I complained that OWS doesn't do a great job of building a community or making it excited about its product.

Something I forgot to add then: why doesn't Signal have a public roadmap? Almost all open source projects that I've seen have one. Why? Because they are typically community-driven and developed projects and because they rely on the community to buy into the project's future, and give a hand developing it or funding it.

But we don't see that with Signal. Why does the roadmap have to be secret? I'm not even talking about deadlines and schedules. Just decide on a bunch of features and present them on the site. You may get more volunteers willing to help if they see an interesting new feature popping up on the horizon.

Also, please do something about the call routing speed. It takes too long for a call to connect. If it's a funding issue, then say so. In fact, it wouldn't hurt to have "crowdfunding campaigns" for the various features on the roadmap. Show progress lines and whatnot, and then start developing that feature when it's fully funded, etc

The whole project needs to become more open towards the community and less "we'll just be here in our basement for the next 2 years developing an awesome secret feature."

Post reply on HN