The underlying reasons are actually pretty sensible.
Signal (as it will be) can't deliver encryption via SMS on iOS due to platform restrictions. Neither can tablets or computers normally send SMS messages. (To say nothing of metadata risks, although TextSecure cannot address that without a decoupling layer, like Tor, and in any case low-latency low-bandwidth mixnet messaging is very hard versus nation-state adversaries with traffic correlation abilities.)
It's also clear that voice and video can't be delivered well or at all by SMS/MMS, and that MMS in particular is a huge pain in the arse.
However, users who have limited/no data plans are up in arms. Whole bunch of 1-star reviews. Clearly quite a few vocal users (not necessarily users in regions you might expect) liked this feature, used it, seemingly needed it. I know that sometimes when travelling even I'm out of data service, but within SMS service.
So it may be that a fork does make semantic sense here. Signal will eventually deliver cross-platform best-in-class secure messaging, group messaging, voice/video/etc - features which cannot be delivered by SMS - and SMSSecure could deliver encrypted SMS messages for users on the Android platform (only).
Agreed there: if Signal won't do SMS, they shouldn't be catching SMS intents, or they might get invoked when, for example, there's no data. (Of course, there's scope for disagreement here. SMS and particularly MMS are horrible, but sometimes horrible is all you've got.)
I believe the GitHub issue is about catching intents by default. In case people were thinking support for using TS as a SMS app was going away, here's an excerpt from the mailing list that says it's not:
>> [whispersystems] Can we remove the SMS feature completely?
>> Since the secure SMS option is removed. To reduce the confusion, can we remove insecure SMS option too?
> <insert thread of disagreements>
> Re: [whispersystems] Can we remove the SMS feature completely?
> Everyone can rest assured, we have no plans to do this. I'm pretty committed to an integrated messenger.
> - moxie
(For some reason this Apr 1 message is not in the mailinglist archives. Not sure what's up with that.)
The transport makes a big difference. Is it going to stop working as soon as I cross the Canadian border? Is there a per-message fee if I am communicating with someone in another country? Is it going to stop working if my phone is connected to wifi and the router is broken or misconfigured, like it is at the coffee shop down the block from my house?
It's one thing to send an email, another thing to send a text, and another thing to use some proprietary messaging protocol, even if all three can be initiated by poking at the same device in slightly different ways, and I want to know which one I'm using so I can pick the right one for the situation.
I've read almost all of the comments here and I'm so confused... So I'm not going to be able to text my non-TextSecure friends with it anymore? And, if my data connection drops right before I message a TextSecure user, will it get sent plaintext over SMS then?
> in any case low-latency low-bandwidth mixnet messaging is very hard versus nation-state adversaries with traffic correlation abilities
Indeed, The Pynchon Gate[1] paper indicates that intersection attacks can break any mixnet, to include high-latency mixnet.
The authors' solution is high-latency, high-bandwidth private information retrieval. Sadly, I can't see a way to make this work efficiently with mobile devices.
> Neither can tablets or computers normally send SMS messages
TextSecure is android-only, so I fail to see how this is an issue.
Also, (please, correct me if I'm wrong), they also require that you have an SMS-capable line to use it, so I fail to see how that limitation would matter.
I don't know - anyone got time to review the source? - but if they're only doing SMS, they might not need it; after all, SMS is already 'push', and it was only needed for push notifications for the data channel.
> Yes, I did. I also looked for bitbucket, gitlab, Google Code, etc. and found nothing.
No worries then.
I checked out their website - I can't see any links to source code. So in my opinion it's just yet another closed source pretending to be secure messaging service then...
I didn't mind much that TextSecure removed the SMS feature, since I didn't use it anyway, but I think the removal was badly handled. I'm glad someone is catering to the users who used this feature, it gets more eyes on the code and increases the pressure on the Signal team to do things right.
When TextSecure removed SMS encryption there wasn't a clear warning about it in the what's new message, and as far as I can tell there was no deprecation period or warning to users who had been using it. You'd be sending encrypted messages before the update, and unencrypted messages after. For some reason they didn't link to their blog post[1] in the what's new message. It looks to me like they didn't want people to notice that they were removing a feature.
This lessens my trust in the creators and makes me hesitate to update the app since I don't know if they will change or remove features I do use in the future without warning. Hopefully they'll review their process so they don't scare more people over to SMSSecure.
I am an avid TS user. I hate that they stopped SMS because the move is contrary to their stated goal[s]. Taking that as understood, I do not feel they mishandled notification of their stupid decision.
If you didn't use the feature, you might have missed it, but we talked about its removal publicly for over a year. We also made many incremental changes over that year in order to phase it out so that it wasn't a sudden removal. We did all of that, despite the fact that it was used by an incredibly tiny fraction of our total install base. The people who used encrypted SMS are very vocal, but the users we're really targeting never even knew it existed.
I think projects like this one are great. I have no idea if the people behind it know what they're doing or can write secure software, but we've always wanted some place where the people who want to import their GPG key, manually select their underlying block cipher, or support WoT style key signatures can go. Projects like these might be a better fit for those users.
I don't have a link other than their website[1], but the copy there suggests that the goal is to make encrypted communication ubiquitous by making it easy to use. They are targeting the people who would never get gpg set up due to how much of a PITA it is; the people who don't know the difference between AES and 3DES much less CBC and GCM.
As someone who doesn't follow TextSecure or anything else, how does this work? How do my messages get encrypted, yet the people I'm texting don't need to install anything to read them? What am I missing here.
Both parties need to have SMSSecure installed, and a secure session started — a roundtrip of sms to exchange keys, or something (im not an expert so not sure if those are keys, or something else).
Otherwise they will only see a garbage of letters/numbers.
That seems like it would turn off some potential users due to the hassle of switching apps.
I'm ignorant of the process, but is there no way to check that the user has installed SMSSecure first and, if not, fall back to sending unencrypted data? (perhaps that could be toggled via a fail open/closed option)
You can use SMSSecure as your default messaging app. That way you don't have to switch apps. You can even import your SMS from the default messaging app so that you don't loose your history. Bonus: you can then encrypt those SMS locally, but that's optional.
You can toggle the option to send encrypted sms or not, per contact, so if your contact doesn't support SMSSecure, you just send a regular SMS.
The ability to know who's using SMSSecure is interesting and not currently supported (that I know of)
Actually, if you receive a message from someone using SMSSecure, you'll get a prompt asking if you want to upgrade to a secure session. But yes, there is no way to look someone up and check if they're using SMSSecure.
The detection was actually inherited from TextSecure and works by "tagging" shorter messages with some detectable whitespace after the message contents. A bit of a hack, but it's a limitation of the transport.
Yes, anyone who analyzes the messages you send can assume that you are using SMSSecure.
However, compared to the amount of metadata that's already being leaked over SMS[1], adding the fact that you could[2] be using a specific SMS client that has the ability to encrypt messages doesn't seem too bad.
There was an option in a previous version of TextSecure to disable this tagging, but it was deemed unused and axed[3]. For the same reason, I'm loathe to add it back in, but having the option shoved under the "Advanced" menu may not be too bad.
[1] This is something that TextSecure does much better with. SMS messages (even encrypted) still leak metadata on who you're messaging and when.
[2] There's some element of deniability with whitespace tags (granted, not a lot). On the other hand, if you're registered with TextSecure (which can be checked simply by adding a user your contacts and opening the app), there's only one reason you would be there.
SMSSecure's default mode is to send normal, unencrypted SMS messages so people using regular SMS clients can still receive them.
If both users have SMSSecure, they can exchange keys and upgrade to an encrypted session.
Also, there's some amount of autodetection going on. SMSSecure will automatically prompt the user to start a secure session if it detects the recipient is also using SMSSecure.
But yes, if a user tries to start a secure session with someone who doesn't have SMSSecure installed, the recipient will just see a bunch of garbage (limitation of the transport).
I'm one of the developers of this project. If you have any questions, let me know.
To be clear, this project isn't endorsed in any way by Open Whisper Systems. We forked their codebase pre-v2.7.0 and are integrating upstream commits, but that's it.
The idea isn't to compete with TextSecure, it's to provide the encrypted SMS functionality TextSecure used to (with all it's compromises and drawbacks) for people that push-based messaging isn't an option for.
The really hard part about encrypting communications is key distribution and validation (eg: validating that the public key for number 555-1234 actually belongs to Alice).
Key distribution isn't really something we're doing. Each user just keeps their own list of verified identities.
We're using the same system we inherited from TextSecure for encrypted SMS: Trust keys implicitly on first use, while encouraging users to verify them out of band.
The verification is handled by providing a screen that has your identity and what you think the recipient's identity is. If the recipient's identity matches what your app says and vice-versa, then you know you're talking to the right person.
Ideally, the verification would be done in-person or via another secure means of communication. Currently you can verify identities by just reading them out, or via QR code.
52 comments
[ 4.7 ms ] story [ 123 ms ] threadReason for the fork: https://whispersystems.org/blog/goodbye-encrypted-sms/
Signal (as it will be) can't deliver encryption via SMS on iOS due to platform restrictions. Neither can tablets or computers normally send SMS messages. (To say nothing of metadata risks, although TextSecure cannot address that without a decoupling layer, like Tor, and in any case low-latency low-bandwidth mixnet messaging is very hard versus nation-state adversaries with traffic correlation abilities.)
It's also clear that voice and video can't be delivered well or at all by SMS/MMS, and that MMS in particular is a huge pain in the arse.
However, users who have limited/no data plans are up in arms. Whole bunch of 1-star reviews. Clearly quite a few vocal users (not necessarily users in regions you might expect) liked this feature, used it, seemingly needed it. I know that sometimes when travelling even I'm out of data service, but within SMS service.
So it may be that a fork does make semantic sense here. Signal will eventually deliver cross-platform best-in-class secure messaging, group messaging, voice/video/etc - features which cannot be delivered by SMS - and SMSSecure could deliver encrypted SMS messages for users on the Android platform (only).
>> [whispersystems] Can we remove the SMS feature completely?
>> Since the secure SMS option is removed. To reduce the confusion, can we remove insecure SMS option too?
> <insert thread of disagreements>
> Re: [whispersystems] Can we remove the SMS feature completely?
> Everyone can rest assured, we have no plans to do this. I'm pretty committed to an integrated messenger.
> - moxie
(For some reason this Apr 1 message is not in the mailinglist archives. Not sure what's up with that.)
It's one thing to send an email, another thing to send a text, and another thing to use some proprietary messaging protocol, even if all three can be initiated by poking at the same device in slightly different ways, and I want to know which one I'm using so I can pick the right one for the situation.
Indeed, The Pynchon Gate[1] paper indicates that intersection attacks can break any mixnet, to include high-latency mixnet.
The authors' solution is high-latency, high-bandwidth private information retrieval. Sadly, I can't see a way to make this work efficiently with mobile devices.
[1] http://freehaven.net/anonbib/cache/sassaman:wpes2005.pdf
TextSecure is android-only, so I fail to see how this is an issue. Also, (please, correct me if I'm wrong), they also require that you have an SMS-capable line to use it, so I fail to see how that limitation would matter.
https://github.com/WhisperSystems/Flock/blob/master/flock/sr...
https://github.com/WhisperSystems/Flock/blob/master/flock/bu...
https://github.com/WhisperSystems/Flock/blob/master/flock/sr...
https://play.google.com/store/apps/details?id=cz.oksystem.sm...
However, did you know that not all open source stuff is on github???
Yes, I did. I also looked for bitbucket, gitlab, Google Code, etc. and found nothing.
So I just opened it in JD GUI and saw this gem.
Don't use BABEL. It's written by people who don't understand security.EDIT:
Is dat a static key? :ONo worries then.
I checked out their website - I can't see any links to source code. So in my opinion it's just yet another closed source pretending to be secure messaging service then...
When TextSecure removed SMS encryption there wasn't a clear warning about it in the what's new message, and as far as I can tell there was no deprecation period or warning to users who had been using it. You'd be sending encrypted messages before the update, and unencrypted messages after. For some reason they didn't link to their blog post[1] in the what's new message. It looks to me like they didn't want people to notice that they were removing a feature.
This lessens my trust in the creators and makes me hesitate to update the app since I don't know if they will change or remove features I do use in the future without warning. Hopefully they'll review their process so they don't scare more people over to SMSSecure.
[1] https://whispersystems.org/blog/goodbye-encrypted-sms/
I think projects like this one are great. I have no idea if the people behind it know what they're doing or can write secure software, but we've always wanted some place where the people who want to import their GPG key, manually select their underlying block cipher, or support WoT style key signatures can go. Projects like these might be a better fit for those users.
1: https://whispersystems.org/
Otherwise they will only see a garbage of letters/numbers.
> SMSSecure works like any other SMS application. There's nothing to sign up for and no new service your friends need to join.
Made it sound like there's nothing to install. Kind of confusing.
I'm ignorant of the process, but is there no way to check that the user has installed SMSSecure first and, if not, fall back to sending unencrypted data? (perhaps that could be toggled via a fail open/closed option)
You can toggle the option to send encrypted sms or not, per contact, so if your contact doesn't support SMSSecure, you just send a regular SMS.
The ability to know who's using SMSSecure is interesting and not currently supported (that I know of)
The detection was actually inherited from TextSecure and works by "tagging" shorter messages with some detectable whitespace after the message contents. A bit of a hack, but it's a limitation of the transport.
Relevant commit: https://github.com/SMSSecure/SMSSecure/commit/93d94f2b7a9fd6...
However, compared to the amount of metadata that's already being leaked over SMS[1], adding the fact that you could[2] be using a specific SMS client that has the ability to encrypt messages doesn't seem too bad.
There was an option in a previous version of TextSecure to disable this tagging, but it was deemed unused and axed[3]. For the same reason, I'm loathe to add it back in, but having the option shoved under the "Advanced" menu may not be too bad.
[1] This is something that TextSecure does much better with. SMS messages (even encrypted) still leak metadata on who you're messaging and when.
[2] There's some element of deniability with whitespace tags (granted, not a lot). On the other hand, if you're registered with TextSecure (which can be checked simply by adding a user your contacts and opening the app), there's only one reason you would be there.
[3] See https://github.com/WhisperSystems/TextSecure/commit/40eca5e0...
If both users have SMSSecure, they can exchange keys and upgrade to an encrypted session.
Also, there's some amount of autodetection going on. SMSSecure will automatically prompt the user to start a secure session if it detects the recipient is also using SMSSecure.
But yes, if a user tries to start a secure session with someone who doesn't have SMSSecure installed, the recipient will just see a bunch of garbage (limitation of the transport).
To be clear, this project isn't endorsed in any way by Open Whisper Systems. We forked their codebase pre-v2.7.0 and are integrating upstream commits, but that's it.
The idea isn't to compete with TextSecure, it's to provide the encrypted SMS functionality TextSecure used to (with all it's compromises and drawbacks) for people that push-based messaging isn't an option for.
How did you guys attack this problem?
We're using the same system we inherited from TextSecure for encrypted SMS: Trust keys implicitly on first use, while encouraging users to verify them out of band.
The verification is handled by providing a screen that has your identity and what you think the recipient's identity is. If the recipient's identity matches what your app says and vice-versa, then you know you're talking to the right person.
Ideally, the verification would be done in-person or via another secure means of communication. Currently you can verify identities by just reading them out, or via QR code.