The New TextSecure: Privacy Beyond SMS
whispersystems.org
whispersystems.org
Congrats on the new release.
While TextSecure still only has 100k+ installs on Android: https://play.google.com/store/apps/details?id=org.thoughtcri...
Despite Telegrams known crypto failures: http://www.reddit.com/r/Android/comments/1yrv46/after_gettin...
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.
We really need to encourage folks to use these genuinely secure messaging apps rather encryption fairy dust like Telegram
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.
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.
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.
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.
Just because you disagree with one datapoint doesn't mean you can't compare them.
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
In either case, TextSecure works, so...
Is a desktop version in the cards?
EDIT: Yes, yes I can't read :D
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.
It's going to be hard going to reflow the already interconnected with this. Wish it wasn't so.
...TextSecure is an SMS replacement. Your contact list is your contact list.
Does nobody you know receive SMS messages?
Of course I can still send unencrypted text messages. Are you trolling me?
Anything that is not public key encrypted must be considered unencrypted.
https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2 https://www.whispersystems.org/blog/advanced-ratcheting/
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.
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.
Doesn't that make them susceptible to a search warrant forcing them to give up the private keys (or equivalent) to TextSecure, ala Lavabit?
I was surprised; seems like a good basic target.
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.
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.
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 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.
https://github.com/WhisperSystems/TextSecure/issues/127
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.
This process would be quite easy to automate.
Not a chance.
And if someone is doing this, we are well past "particularly insidious".
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?
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.
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.
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)
Even in the case of the original app, most people are downloading a pre-compiled binary from the Play store, which has a similar security concern.
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.
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.
Are you basically presenting me with an option next to xmpp/otr?
So in that case I'll stick with xmpp for my use case - self-hosting is just something that I wouldn't want to give up.
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.
Edit: after browsing some feature requests on their Github repo it looks like GV makes it difficult/impossible to do this. Too bad.
If TextSecure could replace this functionality it'd cause me to seriously reconsider GV
[1] - https://itunes.apple.com/us/app/growlvoice-google-voice-clie...
[1] http://www.cyanogenmod.org/blog/whisperpush-secure-messaging...
> - 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.
[1]:https://plus.google.com/u/0/+NikhylSinghal/posts/MjyncJEbzxK
I have been asking for this since 2004.
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?
This was my primary concern, but I looked into it and you can do an out-of-band identity verification.
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.
You can built it yourself.
"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."
>The only secret is to [really] begin.
Nice one Moxie ;)
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.
[1] - https://f-droid.org/
What was it?
https://github.com/WhisperSystems/TextSecure/issues/53
You'll find a more interesting discussion about the reasons for not distributing TextSecure through alternate repositories on issue 127 though.
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.
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?
This is as silly as saying that all of the people who live in North Korea are brutal dictators.
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.
Also a beautiful UI, and I can't wait for the iOS versions.
Good work, Whisper Systems!
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?
So you have to hope that the server you're talking to hosts the code that you're looking at.
Do I think Moxie etc are evil? Not necessarily. But the open source server doesn't help _me_ one bit here, unfortunately.
What could a malicious server do?
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.
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.
So far it seems like it's working.
I'm wondering, why NOT use this over the default applications?
Or just by plain asking them to install it, next time you bump into them in meatspace.
Even better: throw a crypto party.
If so, why is the padlock open? :)
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.
Are there plans to charge? If so, how much and when? If not, why is it free?
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.
[[citation needed]]
Is there an in-depth analysis of what data is exposed with the current protocol?
A likely candidate is the link from "TextSecure V2 protocol".
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.
There is actually an issue on github open about this: https://github.com/WhisperSystems/TextSecure/issues/639
Just my luck!
1 - https://missingm.co/2014/02/fighting-dishfire-the-state-of-m...