WhisperPush – End of Life
cyanogenmod.org
cyanogenmod.org
Why not just use signal and skip the special cyanogen version?
As of 2009, non-military cryptography exports from the U.S. are controlled by the Department of Commerce's Bureau of Industry and Security. Some restrictions still exist, even for mass market products, particularly with regard to export to "rogue states" and terrorist organizations. [...] custom cryptographic software, and even cryptographic consulting services still require an export license.
You might argue that trying to regulate software to keep it from falling into the hands of terrorists is a fool's errand, and you'd be right, but until 1996 [2] it was illegal to export cryptographic software in the first place.
[1] https://en.wikipedia.org/wiki/Export_of_cryptography_from_th... [2] https://www.eff.org/press/archives/2008/04/21-37
https://copperhead.co/android/
Oh, and fun fact. Copperhead OS was initially built on CyanogenMod for device compatibility purposes, but they eventually dumped it for AOSP because CM's code became too complex/insecure.
That's a rather uncharitable interpretation. If a state was ordering them to include a backdoor in the next release, their options boil down to either 'include a backdoor' or 'shut down the service'[0]. Implying that a service that chooses the latter is more likely to also include a backdoor doesn't seem justified.
[0] (or 'have the resources for a massive secret legal battle', which may not even be possible depending on the nation state and nature of the order).
If there is now one less security feature to please anonymous (for now) states, how to trust them not including other "features" on their requests? Uncharitable, and a tad paranoiac, as it may be...
Such a heuristic isn't paranoid -- if anything, it's rather credulous (by applying comparatively less scrutiny to services which operate out of the same jurisdiction (one known to serve orders of this type) yet which somehow happily continue operating).
* It's not possible to use without a phone number. If you want to use it on a WiFi only device, you're out of luck.
* Which wouldn't be so bad, but there's no way to transfer between devices. You can't take an encrypted backup (on Android) and because you use their encryption keys, moving to another device means other Signal users get scary messages about not trusting you.
Minor problems & edge cases, sure - but still frustrating.
Read more here: https://fdroid.eutopia.cz/
> If we were going to rank our priorities, they would be in this order:
> 1) Make mass surveillance impossible.
> 2) Stop targeted attacks against crypto nerds.
As long as US Army is not using metadata to shoot people with hellfire missiles on American soil, Signal is good enough for general population.
If you want perfect protocol - work on Vuvuzela. But good luck porting traffic analysis resistant solution to mobile phones with their limited battery capacity.
Not American soil... but... NSA 'drone strikes based on mobile phone data'
http://www.independent.co.uk/news/world/politics/nsa-drone-s...
What do you know, general population of the world does not live on American soil.
I can't trust Moxie after he called Google, Microsoft and Apple having absolute control over people's good thing, and called people having control over their own devices "going back to the old broken desktop security model".
Can you trust someone like that? It all makes me think that Signal is some kind of honeypot.
...
Now, when you've suddenly realized that people:
1) will not stop using mobile phones
2) mobile phones are tracking devices
3) preventing mobiles from tracking you is well beyond skills of both average tech person and average joe
4) average person is not capable of keeping malware away from their machine
What do you propose? Can you do better than moxie? Or will you continue to spread FUD about best available tech?
When speaking about non-technical, generally-clueless-about-computers people? This is ABSOLUTELY the correct attitude to have. Being able to trick someone into installing softare that reports back everything you do on your computer by getting the user to Punch The Monkey is a BUG, not a feature. The screaming hellpit that is the state of PC security is very bad for the average computer user.
For technical users, systems (like Secure Boot, along with a chain of bootloader/kernel/userspace software verifiers [0]) that let you -say- securely attest that you trust an alternative source of software are really good, when implemented properly. They help prevent drive-by malware installation, as well as let you know when your machine has been tampered with. This is a GOOD property to have.
What about users who want to run their homebrew software (or even start to learn how to code), but don't want to be bothered with code signing key enrollment? On the one hand, I guess -in this world- they're left out in the cold, if they're not doing something in the browser. On the other hand, any programmer is going to quickly face challenges far greater than any non-pathologically-bad key enrollment mechanisms... if the would-be non-web-programmer never gets over this hurdle, it's very likely (in its absence) he would have been stopped by any of the other couple-hundred difficult things along the way.
[0] It's late, so some of these verifiers (particularly the userspace one) might not exist in any mainstream distro.
You are still exposed to Google/Apple, since it can easily combine your contact information with traffic information and with great deal of probability detect who was the recipient.
I still would take it over encrypted SMS, where this data is open to carriers and carriers are basically perma-owned by everyone.
1) Google can see Alice send message via Signal
2) Google can see Bob receive message via Signal
3) Google knows that Alice is in Bob's contacts, and Bob is in Alice's contacts
Those three pieces of data should be enough. I don't see why Google can't do time correlation of those messages. Both Alice's and Bob's contact lists are very finite. It might be not obvious for single message, but for series of messages (and people chat this way) it should be very obvious who is talking to whom.
* Time of Tx to Signal server
* Rough message length
* Time of Tx of message from Signal server to recipient (assuming that they were listening on that path, too)
Is my understanding incorrect? Can a passive adversary inspect the data from a TextSecure/Signal client and determine more (or just the above) information from the data sent from the TS client to the TS server?
If the passive adversary has enough listening posts, it's totally possible for them to be reasonably certain that they probably got all three, unless some sufficiently clever stuff is happening either at the WS servers, or in Google's servers.
Hmmm...
I wonder why they don't link the tweets?
Except:
(Feb 2013) "So that's where we are. I believe that the decision not to distribute prebuilt APKs achieves the following balance:
1) It does not encourage the average user to tick "allow 3rd party APKs" in Android settings.
2) It allows "power" users who can appropriately manage the risks to install TextSecure without Play by building from source.
The thesis essentially being, if you aren't able to build TextSecure from source, you probably aren't capable of managing the risks associated with 3rd party sources." [0]
and
(Jul 2013) "Hey @rickbarton , to my knowledge we have not forbidden anything. People have requested that we distribute official binary APKs outside of the Play Store, which we are currently choosing not to do for several reasons (#127, #281). If we can address those issues we would be happy to distribute binary APKs.
However, this does not "forbid" anyone else from doing whatever they please. ..." [1]
Other things:
* The author neither links to nor provides screenshots of, nor quotes from the Twitter comments that he references. This is a bit of a red flag.
* The author asserts that "Moxie is not open to arguments and wants TextSecure to be distributed only via Google Play. He already locked this discussion.", which is plainly not true. If it was true, Issue #127 would be closed, and Moxie would not have made the comment that he did on issue #281. [2] It's also notable that the discussion lock didn't happen until 2015-01-09... a year and a half after the requirements for official distribution outside of Google Play were laid out in the comment attached to issue #281.
The fellow running the Eutopia.cz F-Droid repo clearly has an axe to grind, and is either unable to, or in too much of a hurry to understand the actual situation on the ground. When dealing with security software, you really, really want skilled, careful, meticulous people to be in charge of design, implementation, and packaging. This guy doesn't seem to be such a person.
[0] https://github.com/WhisperSystems/Signal-Android/issues/127#...
[1] https://github.com/WhisperSystems/Signal-Android/issues/282#...
[2] https://github.com/WhisperSystems/Signal-Android/issues/281#...
The decision to not allow exporting the key mitigates certain kind of attacks. I think the wording of the warning is appropriate and not that scary.
- Doesn't need access to Google Play
- Won't need Google Cloud Messaging (websockets instead)
I would really like these features to be supported in the official client. I don't understand why moxie doesn't reckon that these are legitimate concerns. Leaking metadata can be dangerous.
> Leaking metadata can be dangerous.
You should
* Read about how Signal's crypto works
* Remember that anyone can stand up a Signal server, and build a custom Signal client that will associate with the server that you stood up, rather than the official Signal servers.
But AFAIK moxie has some reservations about making it available via f-droid too.
If you didn't, please go back and read them, and the first ten or so comments of each bug I link to. The "reservations" about F-Droid have to do with its unsuitability for securely distributing software, and have nothing to do with a desire to prevent distribution of Signal through non-Google App Stores.
And while I understand moxie's concerns about fdroid, and I would like fdroid to fix these, I'm not sure if he is making the correct compromise. Getting access to Google Play throughout the regular route implies getting closed stuff from Google into your phone...
IIRC, getting access to software through the F-Droid marketplace explicitly required (at the time the big discussion was made (~3 years ago)) users to expose themselves to the risk that a compromise of F-Droid's online signing key (that -IIRC- wasn't even contained in an HSM(!)) would open them up to silent replacement of any and all software installed through F-Droid by the attacker. Note that "the attacker" could also be "anyone associated with F-Droid".
Despite what one might think about their for-profit datamining, Google has a really good track record with regards to the nitty-gritty of computer security.
When Moxie looked at what F-Droid provided, it was entirely inadequate to securely distribute software to TextSecure's target audience. Because TS/Signal is not currently officially distributed on the F-Droid market, I have to assume that it still cannot provide what is required to securely distribute Signal.
And, to top it all off, the F-Droid folks are so lazy that they write things like this:
"The latest version of the application is 0.6.2, and the security flaw has now been fixed. However, the author has not published any source code corresponding to the binary he released of this version, and far from wishing to help anyone stuck with his previous disastrous mistake, he actually asked for the application to be removed from our repository as he wants to distribute it via Google Play only." [0]
TS's source has been distributed via GitHub for ages. The version that the F-Droid guy says didn't have publicly available source at the time of his post appears to have been published for two weeks prior to his post. [1] If the guy who wrote that blog post is still in a position of responsibility at F-Droid, I don't trust the organization to pay sufficiently close attention to detail to package any security-critical software.
[0] https://f-droid.org/posts/security-notice-textsecure/
[1] https://github.com/WhisperSystems/Signal-Android/commit/f666... [2]
[2] And the initial import date on the GH repo jives with the date on the notice that TS had been released as OSS. [3]
[3] https://web.archive.org/web/20111225144326/http://www.whispe...
You can use it on a WiFi only device. I currently have signal installed on a brand new iPod touch 6th Gen.
Its a device for using Signal messaging and phone calls only.
On a separate smart-phone, I entered the phone number, registered, waited for the phone call and then entered the verification code in the app.
I applied as much hardening as possible to the iPod and tether it either to my regular phone via WiFi or via a dedicated 4G modem i also have.
Easy and significantly safer (i think) as it mitigates base-band attack issues.
If you buy a temporary SIM, and that number is recycled, a new user can register it with Signal.
If that's the case, then you can register it to Signal on an iPod and not have to worry about base-band attacks on iPhone/Android devices. That's the point.
That's easy to say when you aren't the person who'll be subject to criminal liability for violation of a gag order.
I gather that you read the thread, so I won't go point by point and explain the reasonableness of his responses to the issue. I will -however- link to the Github issues that I remember that contain relevant discussion. [0] (Issues 127 and 281 are particularly relevant. 282 is included for the folks who don't understand that Signal for Android is distributed under the terms of the GPLv3.)
Moxie cares about providing solid, functional, easy-to-use, as-idiot-proof-as-possible communication encryption software. His target audience is everyone, not just the technically skilled. To that end, he wishes to make it very difficult for non-technical users to get Signal from a source that is substantially less secure than the Google Play App Store.
Anyone is free to download the source and build and sign their own binary. If you're technical enough to do this, you're presumed to be technical enough to understand the risks you're taking by doing this. For everyone who is not sufficiently knowledgeable to build from source, any binary package distribution mechanism needs to be at least as secure as Google's, and provide the additional features mentioned in Issue 281.
Also notice that Moxie supports the effort to replace use of GCM with Websockets. [1] Google does security well, but Moxie is neither beholden to them, nor is he opposed to equally secure and capable replacements to the services that Google provides.
Whisper Systems is carefully doing excellent work with Signal. Software like this is a great benefit to society.
[0] https://github.com/WhisperSystems/Signal-Android/issues/127 https://github.com/WhisperSystems/Signal-Android/issues/281 https://github.com/WhisperSystems/Signal-Android/issues/282
[1] https://github.com/WhisperSystems/Signal-Android/issues/1000
F-Droid has signed apps.
>[...] Google does security well, but Moxie is neither beholden to them, nor is he opposed to equally secure and capable replacements to the services that Google provides.
Google is a known collaborator with three letter agencies (remember that famous "SSL added and removed here :)" diagram?). It's grossly unacceptable for security related software to require Google Play Services (spyware) on the end user's phone.
If I'm remembering the discussion correctly [0], at the time that Moxie felt that distribution by F-Droid was entirely unsuitable because of -among other things- their insecure code signing key handling practices. Remember that Moxie's target audience is everyone, not just technical users. I elaborate on this point in a couple of my other comments in the sub-threads.
> Google is a known collaborator with three letter agencies...
People say this. I contrast it with the fact that Google now configures its US datacenters (and the links between them) as if they were sited in hostile nations such as China. Switching from the "friendly nation" configuration to the "hostile nation" configuration was a crash project after the Snowden revelations. The project was not cheap. The situation on the ground is -always- more nuanced than can be expressed in a soundbite.
> It's grossly unacceptable for security related software to require Google Play Services (spyware) on the end user's phone.
* Can you point to a reliable, credible source that has analysed Google Play Services and determined that they are spyware, by any reasonable definition?
* As I mentioned in other comments in this thread, Moxie is not opposed to either distribution in non-Google App Stores, nor is he opposed to replacing the use of GCM (AFAIK, the only part of GPS that Signal uses) with Websockets. However, any replacement must be at least as secure and functional as what it replaces. Check my other comments in the subthreads for more information.
[0] And I may not be, it's goddamn late.
The SSL diagram indicates not Google's participation; it shows that NSA was wiretapping their datacenters without their knowledge. PRISM indicates Google collaboration, though.
But see, the presence of Google Play in your phone does not magically allow Google or NSA to listen to Signal conversations.
The easiest way for them to do this would be sending a fake update with a backdoor. This is way more intrusive, targeted and detectable than tapping cables or getting access to Google data.
I'm not sure how familiar you are with Google Play Services, but it's designed to do exactly this. It's what Google came up with when they got fed up with OEMs failing to distribute newer versions of their things to end users. It can silently install updates and has access to almost every permission on your phone, and cannot be removed.
Unless Google also deactivates signature verification for the originally-not-signed-by-Google app that it pushes to the target's phone, the design of both Android and the Android Market make this impossible. You can't silently update an app signed with one key with an app signed with a different key.
If -however- you're talking about Google installing software that snoops on the conversation between the Signal software and Signal servers, then -in that case- Google gets nothing that any other adversary that has access to at least one node between those two points gets... namely, undecryptable cyphertext.
If you're trying to make the stronger claim that Google inserts special code (that they don't include in AOSP) that they use to read the unencrypted data of interest from RAM and transmit to their servers, then I reply:
"All modern computers -including Apple devices- suffer from this class of problem. You have to trust everyone who wrote kernelspace code loaded into your system, the OS authors, the people who put the boards in your computer into their housing, and the folks who made the boards and chips to begin with. This is a hard problem. Frankly, Google's solution to this problem is just about the best consumer-level solution in the industry, and keeps getting better as time goes on."
Nothing changed really, except that we have one less bloat in the CM rom.