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

51–60 of 71 posts

Re: About backdoors in crypto messengers

#51

Post by majewsky »

arghwhat wrote: post #49
dTal wrote: post #46

Earlier quoted context omitted.

>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…

> 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

Except they're working on it right now: https://github.com/WhisperSystems/Signal-Android/pull/5962

Re: About backdoors in crypto messengers

#52

Post by arghwhat »

majewsky wrote: post #51
arghwhat wrote: post #49

Earlier quoted context omitted.

> 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…

> 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 Except they're working on it right now: https://github.com/WhisperSystems/Signal-Android/pull/5962

Oh, thanks for the heads up.

Re: About backdoors in crypto messengers

#53

Post by thinkloop »

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…

> They could backdoor the process isolation and poke around at Signal memory if they felt like it.

Actual question: are google services not apps that run on android similar to other apps, within confined environments?

Re: About backdoors in crypto messengers

#54

Post by arghwhat »

thinkloop wrote: post #53
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…

> They could backdoor the process isolation and poke around at Signal memory if they felt like it. Actual question: are google services not apps that run on android similar to other apps, within confined environments?

Yes, it is isolated with interaction through IPC and intents, although Google Play Services have a lot of permissions, it is a normal "app". To communicate with it, you use a Google-provided, obfuscated library which potentially could be malicious.

However, the "real backdoor" mentioned is in a component that is loaded dynamically when Signal prepares a MapView. The dynamic load means that Google can change what is loaded into the Signal app in the future, unlike the Google API client which while potentially malicious, is static until OWS updates it.

Re: About backdoors in crypto messengers

#55

Post by vurpo »

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?

Matrix is decentralized, proper open source, modern, has audited end-to-end encryption and all that. Be aware that if you install the Riot app from the Play Store, it uses GCM (which means that client is technically vulnerable to the same attack as described in the article), but if you install it from F-Droid it does not.

One strength of Matrix over Signal is indeed that you are free to choose or develop your own client to use with it. You can also host your own server for the decentralized Matrix network, but that point is kind of orthogonal and not related to this specific issue.

Re: About backdoors in crypto messengers

#56

Post by em3rgent0rdr »

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…

isn't Axolotl an open protocol to be freely implemented by anyone? https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm#Usage

Re: About backdoors in crypto messengers

#57

Post by vurpo »

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...

Moxie and Whisper Systems is clearly against decentralization and federation, based on that blog post they wrote. This means it's unlikely that Signal is ever going to have any support for federation.

Re: About backdoors in crypto messengers

#59

Post by temprature »

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...

> but since Signal's server code isn't federated

The Signal server code has supported federation since the first commit in the git history. Whisper Systems' instance of the server doesn't federate with any other server anymore but there is nothing stopping the LibreSignal crowd from standing up their own network of federation-enabled servers.

Re: About backdoors in crypto messengers

#60

Post by em3rgent0rdr »

throw2016 wrote: post #33

It difficult to see how a service that ties to your phone number can make any claim about privacy halfway seriously. This is reckless. And worse tie itself to a company whose business model is based on creepily stalking you all over the internet and getting users psychologically accustomed to the fact they are under surveillance. These are serious escalations that go unnoticed because SV has become a magnet for those…

The claim is secure transport only. They have never made a claim that adversaries won't be able to detect that you are sending encrypted messages.
Post reply on HN