Would kill for the desktop version of this. This team is the gold standard of cryptographically secured messaging; what Colin Percival's Tarsnap is for backup, Whisper is for communications.
Hopefully iOS and Desktop clients help TextSecure take off and beat out the weak crypto apps. Multi-platform is critical these days for messaging apps.
Telegram's been around close to a year or so now. They are an established mainstream app and they look like an obvious "WhatsApp replacement" if one is looking for one. Far fewer people are looking for a secure IM app per se, so your numbers aren't really that surprising. Regrettably, unwashed gray masses don't give a flying f#ck about quality of the crypto, so TS doing crypto better is not a tangible conversion benefit.
i actually think the sign up process of textsecure is more obvious than telegrams.
but i found that use it to transparently send sms when needed super confusing to people.
people don't want to use sms. if they did they would just use that instead.
in cyanogenmod it's even more confusing. cyanogenmod integrated it to their base system, but you have no way of knowing if the text message you just sent is really encrypted or not (unless the other party tells you since he's running textsecure), i'm guessing/hoping that'll improve though
CM really needs to change the onboarding process for TextSecure since I've never enabled it because I don't understand it.
Mainly that "seamless" migration between SMS and data channelled messaging is not something I want to happen because SMS costs me a fortune on my plan, whereas low-volume data costs me nothing.
To that end, the options for the TS process during setup should make it clearer how data charges/SMS charges will be racked up, and indicate accordingly.
Right but what I'm saying is: this is not indicated when it's presented to you. And worse, it's not clear how it interacts - i.e. does TextSecure send an SMS with a hash to find the real message, or does it check if both devices are online (I now know its the latter).
But there's no way to tell at the most important moment - when this new thing is being put in front of me, and claiming to do things with a service that has a usage charge to me.
It would be much better if SMS defaulted to off, it was made clear what it was, and SMS Push added as a "would you like to?" option instead.
Most users flocked to WhatsApp to avoid SMS charges. So, I think SMS push should've been off by default. Many users won't find out until it's too late.
Is it? I just updated to Cyanogen 10.2.1 and TextSecure is definitely a different app from Messaging. Or is this an 11.x feature?
Edit: Oh, I see. Added as a silent feature in 10.2 messaging app. There is no visible indication that secure communication is happening (or possible). Ok. Better than nothing, and a good default.
Telegram's website has got a great layout that encourages you to install right on the first page. TextSecure's looks like a badly designed startup pitch deck. While Telegram uses misleading language that takes advantage of normal people's cognitive heuristics, TextSecure has in-jokes about anarchists and socialist revolutionaries. They're completely out of touch with normal users.
We've got a browser extension in development, with the possibility of using an email address instead of a phone # as ID-- no promises on time line though.
I had downloaded RedPhone and TextSecure. My contact list was a glorious zero people (everyone I know uses WhatsApp).
A few months ago I thought about using Threema and the like, but realized nobody's gonna switch with me. So I stayed. Didn't even try to convince anyone.
The day after FB bought WA my non-tech, not-concerned-about-NSA friends started to switch to Threema. On their own. Because Facebook.
Heck, they were even discussing all that on Facebook, as far as I know... that's irony.
So now most people I regularly chat with are on Threema.
And while I don't trust them (especially their competence -- although using NaCL is a good start) nearly as much as I trust Moxie, this issue is closed now. Nobody is going to move again without a very good reason.
The two people I regularly chat with still on WA can't use Threema, because they are still on Android 2.3.
But Threema really needs multi-device IDs. And the ability to change a group's composition. Other than that it's cool. You feel right at home, the emoticons look the same (from the same lib, I guess). And this whole "scan the other guy's public key" is not just a good idea, it's even close to gamification ("only two more people until everyone's green!").
And that's why I don't believe in some meaningful market share for Whispersystems. They are virtually unknown in non-tech circles. They still don't have an iOS app. Yes, I know, there were more important things up to now.
Still, the window of opportunity is closing. In three weeks no "normal" person is going to switch messaging service anymore. Everyone either stays at WhatsApp, or has already agreed with their whole circle of friends on another service.
Everyone I explain text secure to loves it and starts using it immediately. Its a dropin text message replacement app. It's main competition is android owners who can pick between text secure and the Hangouts app that had replaced the default SMS app.
Tend to agree. If it had've had an iOS version and a little broadcasting of what it is and does, it could have been in Telegrams or Threema's position now, post FB aka Borg acquisition.
It's going to be hard going to reflow the already interconnected with this. Wish it wasn't so.
> Now that the new TextSecure for Android is out, Christine and Fred assure us that TextSecure for iOS will be available in short order. The protocol includes support for users to have multiple devices, and Matt is working on a desktop client.
This is probably the most optimistic thing in security in the past year. Thank you!
It's still tricky to get security due to the platforms on which software runs, but now users can make reasonable choices about which platforms to trust, and by not tying your messaging application to hardware with a black-box baseband, users actually have a decent chance.
Hopefully there will be more progress on baseband-less mobile devices and reasonable networks for those users.
Will there eventually be support for using your email address as your identifier instead of a telephone number?
In a world of IP connected devices, the need to tether your self to the telecom cartel for an identifier is outdated. It would be ideal if future versions of TextSecure let you log in with just your email and then you could run the app on your tablet, desktop or any other devices without a SIM.
Yes it would make them susceptible...if, like Lavabit, they actually held private keys that secured your communications. They don't.
While I have the utmost admiration for Levison's stand, the fact that Lavabit held centralized private keys for its users was a very bad technical and security decision. Moxie has more about this here [1].
Now some may be wondering, what's to stop Whisper Systems from backdooring TextSecure by court order? In a word, this: [2]. The TextSecure client is open source. Not only can the community scan the source for something suspicious, but we can build and verify the binaries ourselves.
The fact that the app is open source is nice, but realistically speaking very few users will build their own copy from source over just downloading an existing binary from Google Play or the Apple App Store. Nothing (but garden variety trust in the source of the binaries) is stopping a situation where there is a clean open source version and then a version with a backdoor built into binaries submitted to the app stores.
And even if you are one of those paranoid users who builds from source, a backdoored central build could still impact you personally unless you're sure everyone you are messaging has also built their own from clean source.
Personally I wouldn't worry too much about this scenario playing out, but I don't see that the client being OSS really buys you much safety practically speaking.
I think you're right that the scenario is unlikely to happen, and I think it is for this and related reasons an OSS client actually offers you a great deal of additional safety over a closed-source one:
1) It allows you to ensure that your personal copy doesn't contain code that does overtly malicious things, like backdoor your computer.
2) An open-source client may not be an automatic certificate of good faith, but a closed-source client is practically a certificate of bad faith/incompetence when your business is security. (indeed, this scenario is predicated on the vendor attempting to capitalize on that very fact - and even if successful, the base-rate probability is still massively in favor of OSS)
3) It is very difficult to hide malicious code in a binary for which the source is available for comparison. It is comparatively very easy to hide malicious code in a closed-source binary.
4) If there is cleanly-building source available, not only users but many vendors (including most Linux distros) will package their own version from that. Many people who don't build the source themselves will still get a clean version.
5) The risk of discovery would be high and the consequences, catastrophic. Sooner or later someone will compile your source, compare the result with your binary, and find something suspicious.
It is overwhelmingly unlikely that an attacker would opt for this strategy. OSS is much safer.
This is true, but at least it lets a small group of people do the verification work and post in a public place if the publicly distributed binary stops matching up with the one built from source.
Yeah, but you have to trust that someone (who is really independent and not in on the backdoor) is actually doing that. Also, the fact that all binaries distributed through mobile stores have to be signed with a private key makes this a more difficult proposition with mobile software than it is with desktop software. (Unlike desktop EXEs you can't just hash the resulting binaries).
I supposed you could pull apart the container format (apk or ipa) and compare the .class files (Assuming Java, I haven't looked at this software so I don't know if it is standard Android or a lot of NDK stuff) or ObjC object files one by one to look for discrepancies versus a local build using the same tools... hopefully someone volunteers to do that and keeps doing it again on each new release.
For iOS I believe that decrypting the binary and doing an objdump, then comparing the resulting assembly is a reasonable approach to ensuring that two builds do the same thing. Comparing objdump results won't protect against particularly insidious backdoors like those injected through data resources or binary headers, but in tandem with a source audit should give a fairly respectable degree of assurance.
> For iOS I believe that decrypting the binary and doing an objdump, then comparing the resulting assembly is a reasonable approach to ensuring that two builds do the same thing.
Not a chance.
And if someone is doing this, we are well past "particularly insidious".
You have to trust everyone who claims the binary is clean, yes. But the vendor must also trust all these conspirators! And they can't bribe everyone - it only takes one honest guy with a decompiler and it's game over.
This is not a case of "many eyes make all bugs shallow, so all OSS software is safe". This is a case of "many eyes will look at my covert code, can't take the risk of discovery". Debian SSL is not comparable because it was an accidental (if stupid) bug. We are talking about deliberate malice, not bugs (which are inevitable in open and closed code alike).
At the state actor level do you really think you will be able to distinguish a stupid bug and an intentional flaw? Its not like they will make it call home with a bunch of code, they would just use a class of attack not well known and you wouldn't be able to tell the difference. That's all it takes, one little hole.
I imagine certain organisations knew about buffer overflow bugs long before they were used publicly, so imagine if this was the 70's and you saw some strcpy calls peppered into some useful code, would you really be able to know 1) the class of attack exists and 2) if it was intentional or not?
Yeah, but that is always a threat with any code ever written by anybody other than oneself. The only assurance against that is if one writes their own code compiled with their own compiler and run on their own fabricated hardware. Oh, and implementing their own security algorithms. Which means any data exchange would be impossible.
It all comes down to the idea that if you the user have concerns with the app, you the user can take the approrpriate measures to verify, given enough time.
I know that I have grabbed the apk's from Google Play before and then decompiled them to compare with the original sources. What I did was compile my own version, then decompile it again and compare those source with the decompiled original sources.
There were some differences where the compiler/decompiler made a different decision, and that had to be checked out manually but in the end it was a pretty nice experience.
But what is the alternative to open source for securing communications? From my perspective, you've just described problems with commercial app stores, the extra effort required to build from source, build reproducibility, and the effort required to audit software. NSA and their global colleagues aren't going to simply go away due to having their activities publicized for the nth time.
Well, there's not really any practical alternative. And I do think it being open source is much better than it being closed source, as long as people are aware that ultimately unless you build it yourself you can never be sure of the security inside (and even if you do build it yourself, you have to be sure there are no subtle bugs either intentionally or unintentionally introduced).
It would be really nice if WS moved to deterministic builds. Really helps with not everyone having to compile themselves (if somebody is checking the source).
Intercept legislation that applies to makers of non-interconnected (i.e., doesn't touch the PSTN) chat functions is extremely unlikely. I'm guessing whisper falls into that category.
I use Silent Circle myself, but I assume on Whisper you can't just type in a normal mobile number and have the chat message go to the right person. If you can, then those chats at least are subject to intercept, and maybe the other chats (whisper-whisper chats) are too. I don't remember how all those rules shake out/how courts have decided.
Upon compiling TextSecure from source and installing it on my phone (I don't have the play store), I've discovered it requires the Play Store to do the "iMessage" style messaging over data. I guess the encryption is still done on-phone before being sent through whatever data API, but I still wonder if that (the play store being installed) might enable key-sniffing? Perhaps that's somewhat negated by users having a strong passphrase though?
Kind of-- some older code was (is?) copyright WS, newer code is OWS, in both cases everything is GPLv3 and all future code will continue to be OWS & GPLv3.
I think their choice of GPL3 is a mistake; it's premised on the idea that people will only ever use one app to communicate and it'll be their app.
In reality that's never going to happen; people are always going to use multiple apps to communicate whether it's via photo sharing apps, games or something else.
We need a secure messaging infrastructure that transcends single apps - and that means it needs to be under a licence that can be integrated with both open source and closed source applications.
It's not just a case of integrating with consumer apps but also business apps. You want your secure messaging system to be able to connect to every CRM, help-desk, shopping etc. system and again that requires a more liberal licence than GPL3.
(Also it's not clear that you can legally distributed a GPL3 app on iOS)
I think GPLv3 is perfect in this scenario. There's no reason why you can't integrate it with a proprietary application or distribute it on iOS -- just purchase a proprietary license exception from the authors.
Hypothetically, if someone integrated this into their own proprietary app with hidden code under a proprietary license... how would you know it hadn't been compromised?
I think GPL3 is a fine license for the project. Affero GPL would be even better.
Communication is fundamental to what humans do, and if you want secure communications, the USER needs access to the source for auditing purposes. The GPL gives that freedom & protection to the user. BSD et al. only gives freedom to developers, and when building a platform that purports to be secure, the code must be visible to everyone that uses it. That's what the GPL provides.
Moxie, it's probably pointless to do it now, but right before or soon after Whisper is finished, you need to set-up some crowdsourcing of language localization for Whisper. Doesn't have to be anything complicated. Just arrange all the text nicely in a txt file and let people download it and then upload the file for a certain language.
I think localization could give a great boost to Whisper in countries where English isn't the native language or that well known, and it doesn't cost you much to do this. But as I said, it's probably best to just wait until Whisper is finished, if it's coming out this year.
Okay, it seems the server is open source? And the protocol supports federation? Could I just run my own server and it will just work™ with users on a different server?
Are you basically presenting me with an option next to xmpp/otr?
When I looked at it (which is already a couple of months ago), federation wasn't “just works™”. A new server needed to be explicitly permitted into the federated network by WhisperSystems. Every server has a full copy of the list of clients and on which server they are and servers trust other severs completely when they claim “we serve the user with phone number 555-123456”.
Aww, that is a shame. I was imagining something like the XMPP server "cloud" where everyone can easily setup their own server, eg for a more private setup with their closer friends (who would then be motivated to use that server).
Not if you want it to be “SMS based”, by which I mean: use phone numbers as identifiers. A server can’t easily prove to another that it serves the user with a specific phone number. There’s no cryptographic proof possible, there’s no hostname part like in email. You can verify by sending a text message, but that gets expensive if you need to do it often.
This is trying to combine 3 points on Zooko's Triangle [1]: You want human-meaningful names (which phone numbers are, because they map to existing things), so you have to make a trade-off between decentralization and security. WhisperSystems opted for security for some reduced decentralization. For something that’s aiming to replace text messaging, I can’t really blame them for that choice.
It's a shame there isn't a standard means to associate keypairs with existing phone numbers in a way that doesn't involve establishing new trust. A <your_phone_number_here>.yourcarrier.com DNSSEC secured subdomain provided by your existing carrier that can be coupled with BrowserID perhaps. All you need is a cryptographic tie-in, right?
I'm very excited to see this for iOS! I never really trusted iMessages but the most painful part of iMessages is the vendor lock-in. Now I don't have to worry about the type of device that my friends use.
On my wishlist is some kind of basic Google Voice number integration. Since messages are encrypted then clearly we can't use the GV web interface, which is fine, since what interests me is the "one phone number" feature of GV. I've given out my GV phone number to everyone and they get confused when they get SMSs from my actual SIM number. But besides that, excellent work as always!
Edit: after browsing some feature requests on their Github repo it looks like GV makes it difficult/impossible to do this. Too bad.
I thought I read that CyanogenMod had middleware that enabled SMS apps to use GV number/service, as well as native SMS. Found it [1] (support began in nightly CM 10.2 builds in early December).
The CM/GV integration is most likely going away. There was a recent post on G+[1] that called out May 15th as the end of unauthorized use of Google Voice
> - Finally, we want to make Google Voice as secure as possible. There are a few third-party applications that provide calling and SMS services by making unauthorized use of Google Voice. These apps violate our Terms of Service and pose a threat to your security, so we’re notifying these app developers that they must stop making unauthorized use of Google Voice to run their services and transition users by May 15, 2014.
Once there's a desktop version of this, Google Voice would be obsolete for me. The best part of Google Voice is being able to send/receive texts from the browser.
I feel the same about Google Voice at the moment. It's killer feature for me right now is the ability to text and call people from my Google Voice account from OS X. I use GrowlVoice[1] extensively. It's easily one of my favourite menubar applications.
If TextSecure could replace this functionality it'd cause me to seriously reconsider GV
Which sit on a server somewhere and then have to send them on to your specific device when you sign in. Generally you need a MAC address to identify the NIC in order to loan an IP address.
My only concern about this is the lock-in. Has that been considered? What happens when I decide to stop using TextSecure? Will I need to tell everyone to delete a key from their phone or something, so messages don't come through garbled? Will they not come through at all, because they'll attempt to use the data channel and my phone wont bother even attempting to pick them up anymore?
What if I lose my phone and get my provider to send me a replacement? I guess I wont be able to read the incoming texts anymore? If some auto-negotiation takes place to change my key, then isn't that exposing a trivial MITM? Would I be alerted of such a key change?
I had this happen to me - where someone I was messaging stopped using it without telling me. One message came through as garbled, but then there's an easy way to "end secure session" and new messages go through in plaintext. For switching between textsecure phones, I just re-initiated a key exchange. This was months ago, so it may have changed
A few things we should be looking very critically in secure messaging apps are:
1. How are keys generated? PseudoRandomGenerator() used? What sort? This is one of the key break-in areas into a crypto framework.
2. Software based crypto used? It's prone to channel attacks where another app maybe inspecting the memory.
3. How are keys shared?
4. How are keys stored?
"Security" would just be illusion, a flawed insurance policy if these aspects are not properly catered for. There's a reason why hardware crypto exists.
The weakest link in any security system is the "key". Does not matter how strong the crypto algorithm is as long as key management is not rock solid.
Even as an Android user, I'm anticipating the iPhone release as the idea of a cross-platform iMessage replacement (seamless SMS/IM) that's also secure and open source is very exciting to me.
I'd really like to try their new app, but they only distribute it through Google Play. That excludes an awful lot of their potential users, especially those who most care about privacy.
"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."
Telling users without Google Play to "just build it yourself" is arrogant an unacceptable. I find Moxie's response to this criticism arrogant and condescending. This is a major reason why I'm not using TextSecure, even though I would like to be.
He gave sound reasons why building it yourself is currently the only secure distribution method outside the Play Store.
I didn't find his tone to be arrogant at all. You're conflating arrogance with correctness, and though many people on the internet use both simultaneously, they are two separate things.
You should build it yourself if you actually care about privacy. This is excellent practice, instead of encouraging you to trust some third-party website like their own.
Another good option would be submitting it to the F-Droid [1] repository of open source apps for those of us who prefer not having Google's proprietary pieces of software on our phones.
Cyanogen runs one of the nodes. I'm not sure where Whisper Systems receives their funding from. At one point Twitter was involved with them, though I believe that is no longer the case.
Like all sensible crypto systems it doesn't matter if the server is compromised, encryption is done client-side. The project is open-source, so you can verify this for yourself.
We are also interested in a TextSecure implementation for the desktop!
Right now the protocol includes multi-device support, so the foundation is there for developing desktop and tablet apps that work seamlessly in conjunction with your phone. Our first desktop implementation is likely going to be a browser extension, feel free to jump in and get involved with that if you'd like.
How does multi-device implementation work (for the layman).
Are the messages only delivered to the 'logged in' clients? So if I am logged in on the desktop my message exchanges are also sent to the phone client? But any messages I send/receive from my phone while logged out of my desktop are synced through the server on login?
Why will anyone trust something based/developed in the USA related to security? It's a compromised jurisdiction. For anyone creating security products who wants to be credible will need to be based somewhere that respects privacy.
Every single US citizen is complicit? Man, I would hate to be this jaded. Some of us are fighting against mass surveillance as hard as we possibly can.
This is as silly as saying that all of the people who live in North Korea are brutal dictators.
That's not what xmr claimed; what was said is that the US is a compromised jurisdiction, and of course everyone developing something in the US is subject to that jurisdiction.
It was never implied in xmr's post that every US citizen supports mass surveillance, only that they may be legally forced to participate in it.
I belong to a WhatsApp group for common interests. I was about to recommend to everyone to switch over to TextSecure, but then I realized not everyone has an Android. This app would really benefit from a J2ME version like WhatsApp IMO.
Could somebody explain why it was tied to SMS in the first place? And given that, why it's trying to undo its connection to SMS?
Separately, what's the difference between this and OTR? Is it just trying to just be a better OTR (and I support this endeavor, competing OTR connections over one chat channel creates a hassle). And as such, why is it only on Android, you could just as well write a Pidgin plugin right?
Imagine if all of the major cloud companies' code were suddenly AGPL and released; it does you virtually no good without massive amounts of infrastructure and data. The GPL and its ilk were conceived in a different era of computing. Most people couldn't even afford the ability to run Google's internal applications even if they were released with full source.
There is a distinction these days between software and services provided with that software; indeed there is a lot of value and functionality added in that layer that the GPL virus people would love to get their hands on.
Unfortunately the "infrastructure and configuration is required to make it work" value being locked up can't be solved with a license - so it can't actually deliver the usual upside of the GPL. At the same time, it _does_ deliver the downside in the disincentive to actually add that value (as then you can't use it as a competitive advantage).
Don't wave the AGPL around as a feature; it's shameful.
I have been able to compile it myself, so I could install it on my tablet.
You can register an Account using any phone number.
Just wait until the SMS verification fails, you then have the option to request an automated call, and get a verification code that way.
I installed this and the calling app Redphone. Installation and integration was quick and seamless, they simply replace the default text/calling applications and have a much better design anyway.
I'm wondering, why NOT use this over the default applications?
As soon as the iOS version is out, everyone in this forum should advertise and really /push/ this to all their friends via FB, twitter, PM -- whatever.
Or just by plain asking them to install it, next time you bump into them in meatspace.
For those of us with a high number of Android users in their circle, we should probably try to advertise sooner, so we can (potentially) make use of the inertia.
Or since most people who did switch after the WhatsApp announcement already switched to Telegram or Threema and are not very likely to switch again, push these vendors to improve (Telegram) or open (Threema) their architectures.
The chat is referring to the padlock icons on messages, which are closed.
The open padlock in the notification bar means that your passphrase is currently cached and anyone that picks up your phone can read your text secure messages. How frequently your phassphrase gets flushed and must be re-entered is a user setting.
Damn. I wish this was native on the blackberry. I could emulate it, but SMS support wouldn't work - and I am not sure if emulating a secure system really is the way to go.
The biggest weakness of this kind of app is it still exposes lots of interesting data for traffic analysis. It's a huge improvement over what we have today, but I'd really like something where you can't see who is talking with whom (when, how frequently, etc.), as well as can't read the content.
Unfortunately doing this with mobile is really hard, due to bandwidth and power. agl's Pond is probably the best effort in the space so far.
Multi-platform support is top priority for any messenger app today. This is my personal experience from working on an enterprise messenger recently. http://peer.im
There are some links in the article. Granted you could've easily missed them since the color is some washed out grey. Moxie should consider making the links a more visible color.
Thanks. Now I tried to follow the links and I still don't understand how they managed to achieve that "The new TextSecure protocol doesn't require a round trip key exchange process."
I'd still like to know how actually their solution protects from MITM.
Fingerprint verification protects against MITM attacks. The application provides a nice interface where two users can scan a QR code to easily compare fingerprints. A hexadecimal fingerprint is also readily accessible.
Prekeys are prerecorded responses to connection initiation: in the alternative world with no prekeys this is what you'd get when you've opened a connection.
This would be because the app is your default messaging app (Android 4.4+). If you want to remove SMS fallback, you need to set another app to act as your default SMS app.
In this case TextSecure has end-to-end encryption, and supposedly even hides metadata when using the push service (which is hosted on Google Push Framework). Feel free to check the source yourself, or take Moxie's word on it, but I think their "track record" is a bit cleaner overall, regardless of the acquisition of WhisperSystems by Twitter.
For starters, Hemlis is not open source. That should stop you in your track right there. If it doesn't, maybe the fact that they actually had to switch to another crypto system for Hemlis after much negative feedback from the community, should tell you more about their experience in this. But even that new one doesn't offer anything resembling forward secrecy. I think Hemlis will be more of a Threema clone, which also isn't open source.
It is released and 100% open source, unlike Hemlis, which is still under development behind closed doors and will be opened "as much as possible" (which tells us nothing about implementations, code quality, privacy features, openness or license).
Hemlis is XMPP+GnuPG based, so (according to TextSecure developers - but most agree) bad for asynchronous communication (XMPP) and without perfect forward secrecy (GnuPG).
Congrats on the new release.