SMSSecure – SMS Encryption for Android
smssecure.org
smssecure.org
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 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.
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.
Reason 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.
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).
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.
Cipher localCipher = Cipher.getInstance("AES/ECB/NoPadding");
EDIT:
private static final SecretKey a = new SecretKeySpec(
new byte[]
{
-91, 63, 7, 80, 88, -58, -47, -28, 55, 126, -126, 27, 67, -64,
97, -46, 5, 44, -14, -94, -103, 96, -57, 33, -108, -104, -122,
125, 49, 29, -25, -27
},
"AES"
);
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...