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

About backdoors in crypto messengers

blogs.fsfe.org

Post reply on HN
Print view View original

41–50 of 71 posts

Re: About backdoors in crypto messengers

#41

Post by tptacek »

jordskott wrote: post #24
roddux wrote: post #8

The backdoor referred to can be applied to any Android app that uses Google Maps. Also mentioned is that using the built-in Google keyboard is a vulnerability, because in theory it gives Google the ability to keylog you. I supposed this boils down to knowing your adversaries. If you number Google amongst that list, life is going to be really difficult - no matter who you are.

I guess it mostly boils down to Moxie and his ridiculous claims of how much more secure Signal is when compared to other solutions (like XMPP and anything based on PGP). Don't get me wrong, I understand the design and user experience decisions of making Signal depending on GCM but Moxie just loves to bash on XMPP and federated protocols and putting Signal on a pedestal of exemplary security. I admire the dedication o…

It's not Moxie doing that, it's virtually the entire community of cryptographic engineers. And Open Whisper Systems is a grant-funded nonprofit that until recently could so barely afford developers they were considering withdrawing their iOS version, so the idea that this is all about Moxie's business interests is horseshit.

Re: About backdoors in crypto messengers

#42

Post by tptacek »

snowpanda wrote: post #38
arghwhat wrote: post #35

tl;dr: this is stupid. People seem to love analyzing security of tiny corners of systems while ignoring the rest of the system, and entirely avoiding figuring out a scope for the security. The post complains about Signal using a Google service, that Google could utilize (either now or through an update) for malicious activity. A Google service that without a fair share of poking around is only available on Google ver…

Your entire comment is based around the "but there are bigger problems" argument. That's like saying you shouldn't fix your leaking engine, if your brakes don't work.

This analogy is basically perfect.

Re: About backdoors in crypto messengers

#43

Post by arghwhat »

snowpanda wrote: post #38
arghwhat wrote: post #35

tl;dr: this is stupid. People seem to love analyzing security of tiny corners of systems while ignoring the rest of the system, and entirely avoiding figuring out a scope for the security. The post complains about Signal using a Google service, that Google could utilize (either now or through an update) for malicious activity. A Google service that without a fair share of poking around is only available on Google ver…

Your entire comment is based around the "but there are bigger problems" argument. That's like saying you shouldn't fix your leaking engine, if your brakes don't work.

No.

I'm saying that if you're trying to fix an engine leak, start with the giant hole in the block from the anti-tank round that was fired at point blank at it instead of starting with the leaking gasket.

Re: About backdoors in crypto messengers

#44

Post by angry_octet »

gcb0 wrote: post #27

for the record, firefox for android also integrates the google backdoor for the sole purpose of allowing chromecast for videos... which zero users use or want.

Speak for yourself, Chromecast is very useful. Though obviously you should be able to turn it off.

Re: About backdoors in crypto messengers

#45

Post by jacobush »

em3rgent0rdr wrote: post #32
jacobush wrote: post #21

Earlier quoted context omitted.

True, but you still need to be aware of who your potential adversary is. If it is someone with access to SMS network texts logs, these encrypted texts will light up like a Christmas tree for someone looking for something unusual.

The threat model is that google and cell phone networks are untrusted adversaries. So your same concern can be said about Signal messages going through Google servers under the surveillance of the NSA. Either way the adversary sees a bunch of suspicious encrypted messages, but can't read them. But if the user has proprietary google code installed on their phone (i.e. Google Play Services), then the backdoor which thi…

It depends on who you are hiding from. In some freer countries, encrypted texts at most get you flagged on some kind of list. In others you may get enhanced interrogation.

Re: About backdoors in crypto messengers

#46

Post by dTal »

arghwhat wrote: post #35

tl;dr: this is stupid. People seem to love analyzing security of tiny corners of systems while ignoring the rest of the system, and entirely avoiding figuring out a scope for the security. The post complains about Signal using a Google service, that Google could utilize (either now or through an update) for malicious activity. A Google service that without a fair share of poking around is only available on Google ver…

>If you cannot trust Google to provide a "non-evil" Google play services, why the flying fuck do you think the Google-provided (or manufacturer-under-tight-google-control-provided) OS is fine?

Because the likelihood of an a-priori exploit hidden in AOSP is far more remote than the possibility of malicious exploitation, at some point in the future, of the gaping wide security hole that is the "give Google root" subsystem.

>Now, if you are security conscious and willing to let go of the conveniences of selling your soul to Google, you would be running a non-Google'd version of Android without Google services. Your only valid complaint in this case, is that Signal depends on Google services to operate, which makes you unable to use it (without hacking Google back into your Android version, but if you do that you might just as well stick to a Google version).

Yup. And that's unacceptable. You can't really claim to be security conscious if your product comes with the stipulation that you give a megacorp root on your computer, can you?

Re: About backdoors in crypto messengers

#47

Post by angry_octet »

em3rgent0rdr wrote: post #36
_0ffh wrote: post #9

Earlier quoted context omitted.

You don't have to look far. The actual Signal client source is licensed under GPLv3. Edit: And server code under AGPLv3.

well LibreSignal was shut down because Moxie didn't like them using WhisperSystem's servers. I guess the libre community could figure out how to setup and fund an alternative server, but since Signal's server code isn't federated , then I don't believe there would be a straightforward way to send messages between the two systems. https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

Obviously they can run an alternative server, and if their version is sufficiently more attractive people will switch their client.

They could 'solve' all these usability problems, fix the use of google interfaces the tin foil hat brigade detest, and deploy it on a non-existent non-proprietary secure phone platform. Oh and make it federated but keep it immune from spam. Yeah, seems like that is a bit hard.

Re: About backdoors in crypto messengers

#48

Post by angry_octet »

Angostura wrote: post #30
binaryapparatus wrote: post #5

It seems that if you really want proper secure channel you need to write one yourself. Anything out there is subject to being compromised. Is there open source alternative for Signal?

Or use Signal on iOS? (This is a genuine question)

This would arguably be more secure. Depends who you trust least I guess, Apple or Google + OEMs. I think Apple has a lot to lose if they were to produce a backdoored firmware. Some android handset contract manufacturer or OEM? Not so much.

Re: About backdoors in crypto messengers

#49

Post by arghwhat »

dTal wrote: post #46
arghwhat wrote: post #35

tl;dr: this is stupid. People seem to love analyzing security of tiny corners of systems while ignoring the rest of the system, and entirely avoiding figuring out a scope for the security. The post complains about Signal using a Google service, that Google could utilize (either now or through an update) for malicious activity. A Google service that without a fair share of poking around is only available on Google ver…

>If you cannot trust Google to provide a "non-evil" Google play services, why the flying fuck do you think the Google-provided (or manufacturer-under-tight-google-control-provided) OS is fine? Because the likelihood of an a-priori exploit hidden in AOSP is far more remote than the possibility of malicious exploitation, at some point in the future, of the gaping wide security hole that is the "give Google root" subsys…

> Because the likelihood of an a-priori exploit hidden in AOSP is far more remote than the possibility of malicious exploitation, at some point in the future, of the gaping wide security hole that is the "give Google root" subsystem.

I am not talking about AOSP. AOSP does not ship Google Play services unless you try to squeeze them in yourself (which would be silly - why would you run a google-clean system and stuff google back in?). I am talking about versions of Android that come with Google Play services - that is, Google shipped or manufacturer-controlled-by-google shipped.

(I sense that I may have misunderstood your point)

> Yup. And that's unacceptable. You can't really claim to be security conscious if your product comes with the stipulation that you give a megacorp root on your computer, can you?

Indeed it is unacceptable. However, Signal on a Google-powered android system is no less "backdoorable" if you avoid Google Play services. The only way out is to take a Google-less Signal, and put it on a Google-less Android. This is where OWS can start to get on my nerves, because they indeed do not want to make a google play services free version (Even if you do not care about security, you might care about the compatibility), and that they effectively took down libresignal.

Their reasons for doing so were sound (dealing with uncontrolled, potentially borked clients on a protocol and service that is still evolving is quite a pain), but they could quite easily have abstracted these things away in the official Signal implementation so that things could work both with and without, especially seeing how security oriented they are.

However, my problem with this post was that it took a Google Play powered signal on a Google powered Android, and started poking at how Google could backdoor Signal, when the ENTIRE system is under Google's control. I'm not saying that this does not matter until we have solved world hunger, I am saying that fixing this specific instance of the problem (Google Play services dependency of Signal) does not solve the specified problem at all (Google backdooring of Signal).

Post reply on HN