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

91–100 of 169 posts

Re: Technology preview: Private contact discovery for Signal

#91

Post by pas »

tuxxy wrote: post #75
mintplant wrote: post #41

Earlier quoted context omitted.

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…

I'm not criticizing you when you say that you need stickers, but please help me understand: how do you rely on stickers to communicate? I can understand them being a nice UI/UX feature that makes the app more fun, but I cannot possibly imagine that people actually rely on stickers to communicate. Maybe you mean something different and I'm misunderstanding you?

To succinctly convey emotions, opinions, viewpoints, "feels". To simply have a non-verbal vocabulary, to have a different quality to certain parts of the communication, to signify a different quality of seriousness/playfulness/feeling.

It's the new emoticon. :-)

Re: Technology preview: Private contact discovery for Signal

#92

Post by teraflop »

bascule wrote: post #79
teraflop wrote: post #42

Earlier quoted context omitted.

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…

Can you describe which API you're even talking about? This one? /attestation/sgx/v1/report If so, perhaps you missed this: > "The Attestation Service verifies the validity of the platform. It is the responsibility of the Service Provider to validate the ISV enclave identity." This API gives back considerably more than just an "OK" or "not OK". It gives back an attestation verification report (see section 4.2.1 of htt…

I did see that document, and I don't see how it addresses the underlying trust issue. Again, I don't claim to be super-knowledgeable about this stuff, which is why I asked if I'm missing something.

> If so, perhaps you missed this: "The Attestation Service verifies the validity of the platform. ..."

No, I didn't miss it. The Attestation Service claims to "verify" the validity of the platform, but it provides no proof of that verification. And if the platform is not valid (i.e. not verified to be using an authentic Intel key) then it doesn't matter what other checks you do; the security of the entire system falls apart, because the supposedly "secure" enclave could actually be being emulated.

> It also carries a data-at-rest signature in addition to TLS:

That's a signature generated by the Attestation Service, not by the original processor. It's generated using a "Report Signing Key" which has no cryptographic relationship with the processor's keys, or with the signature of the attestation; it just tells you that Intel claims to have checked that attestation and found it to be valid.

> An OCSP server could just as easily lie to you about the revocation status of an X.509 certificate. C'est la vie.

Right, this system seems as weak as OCSP, in the sense that it can be easily compromised by (for instance) a court order to modify the behavior of Intel's verification API. That's much weaker than the original claim, which was that it could be compromised only by tampering with the processors during manufacture. (Not to mention, the TLS certificate infrastructure would be vastly less secure if browsers had to rely entirely on OCSP and couldn't do any certificate validation of their own. OCSP can lie about revocation, but it can't lie about the signature itself.)

I'll add that v1 of the reporting API seems to have been even weaker than OCSP. In that version, the signed response didn't even include any identifying information about the request, so if Intel faked a response, you wouldn't even be able to prove it to a third party! Thankfully, v2 seems to have fixed this obvious oversight.

Re: Technology preview: Private contact discovery for Signal

#93

Post by NMDaniel »

pas wrote: post #91
tuxxy wrote: post #75

Earlier quoted context omitted.

I'm not criticizing you when you say that you need stickers, but please help me understand: how do you rely on stickers to communicate? I can understand them being a nice UI/UX feature that makes the app more fun, but I cannot possibly imagine that people actually rely on stickers to communicate. Maybe you mean something different and I'm misunderstanding you?

To succinctly convey emotions, opinions, viewpoints, "feels". To simply have a non-verbal vocabulary, to have a different quality to certain parts of the communication, to signify a different quality of seriousness/playfulness/feeling. It's the new emoticon. :-)

So basically emojis?

Re: Technology preview: Private contact discovery for Signal

#94

Post by cvwright »

kuschku wrote: post #38
cvwright wrote: post #28

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.

First, you're not wrong about Signal being insufficient against nation state adversaries. The Grugq has a nice talk about opsec that I can't seem to find atm. He sums up the issues with Signal nicely in a Medium article. [1]

That said, this particular development is a lot more than a puppy. It's at least a full grown, happy, friendly Golden Retriever who's already house trained and knows how to fetch your slippers.

They've removed one of the biggest remaining weaknesses of their system, where they still required the users to "just trust" them. That's pretty cool, especially for the vast majority of us whose primary adversaries are smaller or profit-driven.

[1] https://medium.com/@thegrugq/signal-intelligence-free-for-al...

Re: Technology preview: Private contact discovery for Signal

#95

Post by mintplant »

NMDaniel wrote: post #93
pas wrote: post #91

Earlier quoted context omitted.

To succinctly convey emotions, opinions, viewpoints, "feels". To simply have a non-verbal vocabulary, to have a different quality to certain parts of the communication, to signify a different quality of seriousness/playfulness/feeling. It's the new emoticon. :-)

So basically emojis?

Sure, if emojis could be infinitely extended with arbitrary images and were sent as their own messages instead of being embedded inline with other text. Replying to another message with a sticker also fills the role played by reactions on Facebook Messenger.

Re: Technology preview: Private contact discovery for Signal

#96

Post by bascule »

teraflop wrote: post #92
bascule wrote: post #79

Earlier quoted context omitted.

Can you describe which API you're even talking about? This one? /attestation/sgx/v1/report If so, perhaps you missed this: > "The Attestation Service verifies the validity of the platform. It is the responsibility of the Service Provider to validate the ISV enclave identity." This API gives back considerably more than just an "OK" or "not OK". It gives back an attestation verification report (see section 4.2.1 of htt…

I did see that document, and I don't see how it addresses the underlying trust issue. Again, I don't claim to be super-knowledgeable about this stuff, which is why I asked if I'm missing something. > If so, perhaps you missed this: "The Attestation Service verifies the validity of the platform. ..." No, I didn't miss it. The Attestation Service claims to "verify" the validity of the platform, but it provides no proof…

In the end this system is just a PKI, albeit one based on a "privacy preserving" scheme based on bilinear pairings. It has all of the same failings as any PKI. They aren't going to do any better than OCSP.

> the entire system falls apart, because the supposedly "secure" enclave could actually be being emulated.

I'm not sure what else you're expecting? Even if the signatures were cryptographically verifiable end-to-end (which I believe is still on Intel's roadmap, but in the meantime they have centralized revocation) Intel could still issue an attestation certificate for a malicious enclave which is in fact a white box software emulation of an enclave, and you'd be none the wiser.

There is no magical way for Intel to provide a mathematical statement that a device is a genuine Intel CPU. You are trusting the hardware and the key management to do what Intel says on the box.

Re: Technology preview: Private contact discovery for Signal

#97

Post by incompatible »

Orangeair wrote: post #74
thinkloop wrote: post #52

Earlier quoted context omitted.

In case someone from Open WhisperSystems is reading: please do NOT add stickers and junk to your clean and pretty system. I know a lot of people that would leave the service if it turned into WeChat (including me). Stick to the fundamental engineering of privacy as you are doing, and forget the gimmicks.

I think this is an unhelpful suggestion. It seems to me that you're advocating that the developers take an approach which will give them a smaller install base in favor of engineering focus on privacy and security. But communicating privately and securely with someone is impossible if they aren't also using the app. This is the same problem with PGP/GPG -- it may be incredibly secure, but if no one uses it, it doesn'…

Perhaps it could have an opt-in system, where stickers don't work unless both sides in the conversation enable the feature.

Re: Technology preview: Private contact discovery for Signal

#98

Post by Confiks »

permanentdecaf wrote: post #27
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 opera…

I understand that you will have to trust the CPU to do any computation. In a sense, it indeed shortens the 'trust stack', and as said in another comment "now, you need only trust that Intel hasn't backdoored their hardware".

Maybe the main point should have been that that this scheme "encourages a centralization of trust into a private key managed by processor manufacturers". You might say that by integrating SGX mechanisms into your security model, you create a set of 'feudal lords' [1] which can wield their power over you.

A manufacturer may legitimately establish an enclave in you most trusted hardware which you may not audit or even measure. And if that security model becomes commonplace, for example when only allowing Widevine DRM inside SGX, you eventually cannot use your self-chosen hardware, but will have to pick a feudal lord.

[1] https://www.schneier.com/blog/archives/2013/06/more_on_feuda...

Re: Technology preview: Private contact discovery for Signal

#99

Post by betterunix2 »

Asdfbla wrote: post #16

Cool idea. When I read the title I thought that maybe they have discovered a practical private information retrieval method or some oblivious transfer-based method after all since their 2014 blog post (well, they kinda do something like that with oblivious accesses to the RAM I guess), but using the secure enclaves for running verifiable code seems like a very pragmatic and creative solution too. Granted, how secure…

"practical private information retrieval"

For single-server PIR that is almost certainly an impossibility, since no matter what sort of techniques you use you must scan the entire database on every request (there may be some batching that can be done if several requests are from the same user, but if you have millions of users that is not terribly helpful). Multi-server PIR is already practical, but deployment is a bit difficult: who will be the other server? How will you ensure the other server's database is synchronized with yours?

Re: Technology preview: Private contact discovery for Signal

#100

Post by mcny »

orbifold wrote: post #68
thinkloop wrote: post #52

Earlier quoted context omitted.

In case someone from Open WhisperSystems is reading: please do NOT add stickers and junk to your clean and pretty system. I know a lot of people that would leave the service if it turned into WeChat (including me). Stick to the fundamental engineering of privacy as you are doing, and forget the gimmicks.

In my opinion the signal ios client is significantly less polished than the telegram client. I could convince my girlfriend to switch to telegram, after she found signal to be intolerable on her android device as well.

> In my opinion the signal ios client is significantly less polished than the telegram client. I could convince my girlfriend to switch to telegram, after she found signal to be intolerable on her android device as well.

My reaction is the opposite. I love the signal iOS app because it doesn't try to do SMS. It lets you enter the code which is great if I want to use a Google Voice number instead of a carrier number (and I don't forward Google Voice texts to the carriers). I am not a fan of SMS fallback and I am glad I get the "Enable Signal for SMS" on Android as opposed to just sending a text.

Post reply on HN