Signal for Android: RedPhone and TextSecure in one app | Hacker News Reader

Signal for Android: RedPhone and TextSecure in one app

whispersystems.org

243 pointspjf153 comments

Signal is pretty awesome, it's by far the best that we have right now:

  • state of the art crypto
  • open source
  • free as in beer
  • Available for Android and iOS

There are a few minor features that are missing but I can live with that. However, there are also a couple of important shortcomings:

  • no decentralization
  • use of the phone number

I hope they can be fixed sooner or later.

But the centralisation and use of the phone number is necessary to make it not shit. Anyway you forgot the important features:

* Nice modern UI

* Integrates with SMS

* Supports group chats

* Uses MMS for group chat if not all members have Signal

* Not really buggy or hard to use

Huge respect for Moxie, but the requirement of a phone number really is a dealkiller.

  1. Phone number requires a service provider
  2. Service provider owns the baseband and root of your phone.
  3. $government makes a "lawful request" of Verizon et. al.
     to install keyloggers/screenshotters on your phone.
  4. Your "secure" commms are compromised.

Signal needs to work on comprehensively rooted devices connected only via wifi for the above threat model to go away.

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.

It's not that we don't find #2 laudable, but optimizing for #1 takes precedence when we're making decisions. It's totally possible for you to install Signal on an iPod touch with a VoIP number, for instance, but that takes more effort than the common case we're designing for.

Any chance of not requiring access to the whole contact list? I think there are pickers that allow selecting one contact - or better yet, one could allow adding contacts inside Signal.

Probably not because they check that against the list of people who have Signal installed so they can send encrypted messages to the people who support it. They talk more about how they try to do this privately in [0].

[0]: https://whispersystems.org/blog/contact-discovery/

I had a problem where one of my contracts uninstalled Textsecure, and went back to the vanilla SMS app. Now all the messages he received from me are garbled. Somehow they need a way to disassociate phones AFTER the app has been uninstalled.

You can ask your contact to use the unregister app here https://whispersystems.org/textsecure/unregister/

Apple offer a similar tool when leaving iOS https://selfsolve.apple.com/deregister-imessage

This is one of the reasons why they don't do encrypted SMS anymore:

https://whispersystems.org/blog/goodbye-encrypted-sms/

Wouldn't that be a huge security flaw? Someone with access to your phone could uninstall the app then read all the messages.

which is silly. that should be fine for people already advertising their contact list for facebook, wasapp, etc. but there should have been a isolated account setup for people not doing so

It is a little inconvenient but I have registered for Signal using Google Voice. Much more easily done on iOS than on Android though.

moxie,

Please consider my suggestions here. https://news.ycombinator.com/item?id=10501636

I would argue that an identifier is just that: an identifier. It does not need to be a number nor does it have to be for an indefinite amount of time.

Lastly, please consider disabling the debug log by default

Plus it still leaves people open to metadata analysis. The phone number has to be verified, meaning a text message is sent from Signal HQ to your device, clearly marking you as a Signal user.

Nitpick: Currently the verification text messages are sent via Twilio.

I'd say only being available on Google Play is an even greater dealkiller. Telegram (which is, to be honest, not quite comparable) is on F-droid, that I like.

TextSecure used to be on F-droid, but Moxie wanted them to take it down, because it was not him signing the packages (a disadvantage to Google Play).

> 2. Service provider owns the baseband and root of your phone.

My service provider doesn't own my baseband. They own the SIM I put in my phone, and that likely gives them a lot of access to my device, but I doubt it can be used to perform key or screen logging. (Nexus 4, bought SIM free)

This is why I still don't own a cellphone in 2015.

I disagree that a phone number is required. You don't have one here, nor on Facebook should you use that. Identity doesn't need to be tied to a phone number and arguably .. shouldn't be.

How is centrali[zs]ation important? Mail works transparently and you don't know a thing about the stack behind a random address, right?

I'd side with the GP: The 'one server, ours' and 'your phone number is your identity' limitations are what I'd like to see go away. Prioritizing the 'no phone number' over 'hosting my own server', as far as I'm concerned.

>use of the phone number is necessary to make it not shit

Why? People who actually care about encrypted communication the most will just see it as unnecessary leakage of private data.

One of the best things about internet based communication is that we don't have to rely on traditional concepts like phones and phone numbers. I should be able to sign up and chat with anyone on any internet capable device, phone or no phone.

Because you need something paid for underneath it to stop spam.

This fantastic post from Mike Hearn, who was on the GMail spam team and now makes P2P decentarlized stuff, explains it all:

https://moderncrypto.org/mail-archive/messaging/2014/000780....

Essentially, every large provider (e.g. Facebook, GMail) of network services ultimately uses phone numbers now as a common thing that can't be infinitely reproduced. They underpin all high quality antispam on large Internet systems.

Hmm? I'm relatively certain Signal removed all support for SMS/MMS and requires all parties to use the Signal app

https://whispersystems.org/blog/goodbye-encrypted-sms/

Incorrect. They removed support for encrypted SMS/MMS. You can still text normies who don't have Signal using it.

This is why I chose to switch to SMSSecure. I've encountered a "bug" where I can be autoconnected to a known wi-fi (at say the library or a coffee shop) that requires authentication. Since my phone sees me as connected to wi-fi, it tries to send my messages via that channel instead of 4G data. Since I haven't authenticated to the wifi (phone never left my pocket), I don't receive any messages.

When I arrive home a few hours later, my phone blows up with a bunch of missed messages.

For me, the big thing that will make signal usable as a chat system is multi-device access. I'm at a computer most of the time, and much rather use my keyboard. Hell I would even hack the iOS client and make it an OSX client once they have multidevice support baked in. The ability to seamlessly move between my phone, tablet & computer is vital, so I use iMessage.

Whisper is working on a chrome version, so I am excited for the eventual multi-device.

Then to make money, maybe Whisper can make Signal: The Slack Edition and sell it for $4/month/user. They will host your WhisperSlack servers, but with client side encryption, never know it's contents! Even with compliance exports.

They do plan to use other identifiers than the phone number but I don't know how high a priority it is. My knowledge about this is probably a year old.

I wonder if they opt-out of Google Now on Tap. Google has made its spying the default on Android 6.0, and developers have to know to opt-out of it, otherwise private Signal communications could be collected by Google.

This is nonsense. Now on Tap only scrapes the screen through explicit user action.

TextSecure also uses the FLAG_SECURE window flag by setting, so NoT among other things is blocked.

It is not opensource.

the client WAS. the server i don't think was ever.

These are the client (GPLv3) and server (AGPLv3) repositories:

https://github.com/WhisperSystems/TextSecure

https://github.com/WhisperSystems/TextSecure-Server

sorry, i briefly followed the discussion on fdroid. from there it appeared that they couldn't build the latest versions from the provided sources.

Wow, tough room! So much negativity. Whisper Systems, thanks for making encryption simple enough that my Mom can use it, and open enough that I can trust it. That is the success story here.

I can't wait to see the number of pull requests to their repositories for all the bugs/features people are demanding!

That's not really how the world works though. People have de facto ownership over projects. A lot of the features are things which the project have repeatedly rejected. Very few people are going to spend time on things they believe are futile. The technology isn't the problem here, it's the leadership of the project.

TextSecure used to be on fDroid, then this happened https://f-droid.org/posts/security-notice-textsecure/. Now it's a GPlay exclusive. I don't have GAPPS so now I can't get it. I'd assume many privacy conscious people don't have GAPPS. I understand the technical hurtles, but it's too big a pill to swallow.

Just use Conversations. It can now use the same protocol and is the best XMPP client there is.

I'm completely baffled that the Textsecure people insist on using the gapps package, which is of course an extreme privacy risk.

> It can now use the same protocol

Conversations uses XMPP, not whatever custom stuff WhisperSystems worked up for Signal. Are you talking about OMEMO[0]? That's their implementation of Axolotl over XMPP. So same crypto, yes, but different protocol.

[0]:http://conversations.im/omemo/

That's what I meant, sorry for the confusion.

See my comment here: https://news.ycombinator.com/item?id=10500188

Thanks for the answer, but if you don't care about this use case, then I think I'll just use a different application that does.

The things I don't like about Signal / Textsecure are:

- Requires Google / Apple services

- No easy way to self host

- Accounts bound to a phone number

- No desktop client ("Being worked on" for months now...)

All these things can be solved for me by using XMPP with Conversations on Android.

So maybe the right thing to do is to stop complaining. Signal / Textsecure is just meant for other people than me.

Thanks for this! Seems to cover most of my bases. Secure, on F-Droid and gappsless. Here's hoping for a mainstream XMPP resurgence. Not holding my breath though. I had played with Jitsi before too, have to see how these compare.

I can understand somebody deciding to focus on the users with Google Play Services, but I find very hard to trust a 'Secure' application which writes sensitive in the logs.

If the app runs in an android version < 4.1, logs are readable by any application.

Assuming that by "GAPPS" you mean the Google Play Store etc., my strategy has been as follows:

- copy all data to a computer

- wipe the phone

- set up a google account with bogus information

- install all the apps i might ever want to use

- delete the account info and remove google stuff

- copy personal data back onto the phone

This is a big hassle, so I only do it once a year or so, but it seems to work ok.

Of course I have no way of verifying that the phone actually deletes my data when I tell it to, or that it actually deletes the Google stuff when I tell it to, or really much of anything about what it is doing or who it is talking to, so I still don't trust it - but I mistrust it slightly less, I suppose, than I would if the google apps were running.

You might be interested in Racoon[1], which is a desktop client (Java) for downloading apps from the Play Store, or into BlankStore [2][3], which is an alternative mobile client.

Both are FOSS projects.

[1] http://www.onyxbits.de/raccoon

[2] https://github.com/mar-v-in/BlankStore

[3] http://forum.xda-developers.com/showthread.php?t=1715375

I didn't see a link of this somewhere, so I'll just drop it: https://github.com/JavaJens/TextSecure

This is a fork of TextSecure/Signal which drops the dependency on GCM and uses WebSockets instead (it seems quite up-to-date with origin as well).

For anyone wanting a pre-build copy, there is a non-official F-Droid repository hosting both the "main" Signal and the WebSocket fork here: https://fdroid.eutopia.cz/

TextSecure requires proprietary Google applications and this is deliberate: http://support.whispersystems.org/customer/portal/articles/2...

SMSSecure is an acceptable alternative (for text messages), available on F-Droid.

It's open source. So could compile on your own.

I'm pretty sure it requires gapps, although I did see a websockets version so not 100%. Also, keeping your own builds up to date is possible, but a hassle. For anyone else doing that https://f-droid.org/repository/browse/?fdid=fr.kwiatkowski.A... is an easy way to ensure your apks are up to date without a repo store.

This event spooked me forever against Textsecure. I've seen moxie's reasoning for moving to Gapps, but I don't know if I (or the the unix world) agree with it. If I had a gun pointed at my head, this tactic (making an insane choice that boils down to "it's encrypted. what could possibly go wrong?") would be my canary of choice. I'd probably mix in some Lennart Poettering, "it's the future, get on board," to make it extra-obvious, though.

https://github.com/microg/android_packages_apps_GmsCore https://github.com/mar-v-in/BlankStore

One of the reasons I didn't install WhatsApp is the sheer quantity of permissions it wants (on Android).

Yes, I realise that this is part of Android's broken security model.

But the Signal app also wants access to practically everything. Device & App History, Identity, Calendar, Contact, Location, SMS, Phone, Photos/Media/Files, Camera, Microphone, WiFi Connection info and Device ID and call info.

Call me paranoid, but making an app with all those permissions seems kind of the obvious place for backdoors and similar.

If there was a 'light' version of the app which only required access the internet, then I'd be much more likely to install and use it. (And maybe if I ended up trusting it, then later install add-ons / the full version later).

I'm not associated with Signal or Moxie (though I've been a silent fanboy for ~15 years-- [[hey Moxie if you're reading this and still are hiring, ping me - contact info is in my profile]]), but I'd inherently trust the application more than an average application or company because: a) Moxie has a track history of having a lot of personal integrity with regards to security. Some might say this is blasphemous but I'd put him up there with Bruce Schieder. b) The whole source is available on GitHub, compile the APK and see if it matches. c) it's incredibly easy to take an apk and disassemble it, to see if there are backdoors to begin with if you are really that cynical.

Don't get me wrong, I'm a tinfoil hatter. I use GPG, run my own MTA for anything even remotely important, use DDG over Google, donate to the EFF and use their HTTPS Everywhere plugin, have all of the Ad-Opt outs enabled that Google/Doubleclick/etc make available but try to obscure, etc. I'd be willing to bet that Google is collecting way more information than Signal is.

But hey, that's why rev-eng is so important. A wiser man than me once said "Don't turn it on, take it apart" ;)

  compile the APK and see if it matches

Are deterministic builds possible with the Android toolchain?

F-Droid is working on this:

https://f-droid.org/wiki/page/Deterministic,_Reproducible_Bu...

Last I looked, no, but the immediate cause of nondeterminism I saw was the zip entry timestamps in the apk. I didn't bother looking further down the chain.

> I'd be willing to bet that Google is collecting way more information than Signal is.

I don't understand this sentences. It's quite obvious that Google is collecting way more information than Signal and almost anyone else. I'm curious, what did you mean?

I suppose he refers to information collected with the Signal app alone. The thing is that all information that is sent via Google is encrypted, so it's not of much use. I only wonder how the connection between two clients is setup, and if Google gets to know which Google user talks to which other Google user.

In terms of privacy tools, I work for a company that makes one aimed for the general internet user (i.e. someone who doesn't know what DNS is). Do you have any comments on our extension? https://redmorph.com

We aimed to put adblock/ublock/donottrack all in one extension and coupled it with vpn and proxy paid services.

If you weren't located in the US (or FIVEEYES) in any way, I'd use you in a heartbeat, and recommend all my friends.

This issue is intrinsic to the security model of Android before Marshmallow.

If an app is going to be able to send a contact, share a location, make a phone call ... all these permissions need to be demanded upfront, which I understand can be scary.

You also need to keep in mind that nobody is going to use "secure messaging" if it's a pain to use. You obviously don't want to be copy pasting contact information in the app for instance.

I'm glad to see that Android is following iOS's permission model where permissions are only asked at run time.

It's exactly why marshmallow is changing the permissions model. All of those permissions are necessary if you want an app that:

* can show a contact's name on a message they sent you * can save public keys and access them * can send/receive messages with multimedia * can uniquely identify your device and you as a user (to generate your private key with unique primitives)

Off the top of my head iIdon't know why it asks for calendar permission, but we could inspect the source...

The point is, if you're trying to make a mass market app, you have to offer competitive features... And that requires a lot of permissions.

No idea about device history. Identity to know your number. Contacts for contact discovery (using a privacy protecting protocol). Location for location sharing. SMS because you can send SMS with it. Phone because it can call from it. Media and camera because you can share media. Microphone for calls. WiFi connection for a bit more stable connectivity. Etc...

They want, and are getting, normal users to install the app.

For instance:

https://twitter.com/mattblaze/status/658673892685447168

Access to the microphone is sort of justified for a voice app, quite a bit of the others are needed for "full featured" messaging.

In Android Marshmallow you can deny / disable any of those permissions. And apps compatible with API Level 23 won't ask for those permissions from the start.

>Yes, I realise that this is part of Android's broken security model.

Well, with Marshmallow, they have no excuse. The permission model is now very similar to iOS's one and any app can start with 0 critical permissions (basically anything related to personal info) and ask the permissions at runtime.

For either Android or iOS, you still have to trust that an app won't abuse the permissions you give it though.

I just installed Signal, and the list of permissions is endless!

regarding to excessive amount of required permissions, and the fact that contact == phone number, for now i am preferring ChatSecure.

This is great news, and thanks to everyone involved. I've been using TextSecure for a while, and it's really "pretty good security made easy". Yes it is not perfect for the super privacy-conscious (depends on Google Play services and all that) and a fork with these features might be useful, but if I understand the motivation correctly, the main goal is to make good crypto accessible to the masses.

I do have a personal gripe with that, though. I'm hoping a "high up" might read it so I am posting it here. The only people in my contact list who use the app are crypto nerds. It's really hard to get traction. I thought that the TextSecure people had a great idea to solve this chicken and egg problem; a unified messaging app that would handle your sms, and send secure messages wherever possible. One feature that I find is missing though, is the ability to semd broadcast (unencrypted) sms texts. In my experience (Europe, people around 30) this is used a lot, and a drop-in replacement for the built-in messenger would need to have this.

Actually, I would like to see this happen so much that I would be willing to do the work, if someone is willing to provide the handholding...

Guys, cut with the negativity. I'm a crypto nerd as well, and with my other truly paranoid friends we use Chatsecure which does not require your number, is compatible with Tor, etc. However, my mom uses Signal, my father yesterday called me via Signal and he's fuckin' 67 years old. That is truly amazing and I admire Moxie et.al for the work they do.

Do you seem to forget that it is encryption for the masses. Not only for the few tin foils like myself. And even if it uses GCM, it's still an great, since i could never persuade my non-paranoid friends to contact me only via Chatsecure. They would say - "why the fuck can't you be like a normal person and use whatsapp or fb messenger?".

I really want to start using TextSecure (or Signal now I guess), but the only thing holding me back is it depends on Google Play Services. I love what they're doing and can understand the decision, but still thinks it sucks a bit that the best option for secure communications is so tied into Google.

It seems like you don't want to install Google Play Services on your device. My sense is that this isn't because you find the communication over GCM to be inherently offensive (it's just a tickle, after all), but because you don't want to run proprietary software.

There's a very small number of people who find this to be very important, and my experience has been that the strategy is to loudly complain whenever anything depends on play services. Just tactically speaking, I don't think this is going to work in the end, in the same sense that simply refusing to have a mobile phone won't work anymore -- slowly, the circumstances around this technology will make it impossible to refuse.

What I don't understand is why nobody just writes an API-compatible open source implementation of play services. Even if it only supported GCM and nothing else, that'd unlock an enormous swath of apps, and would only require writing a basic implementation of the GCM network protocol.

I'd love to know more if I'm misunderstanding the challenges around doing that. Right now it's part of the reason that I don't pay much attention to that crowd -- everyone seems very willing to complain, but nobody seems willing to do what seems like pretty straightforward work to solve their own problem.

There you go:

https://github.com/microg/android_packages_apps_GmsCore

An open-source replacement of Google services. You can use Signal with this.

I wrote a little guide on how to set it up: http://o9i.de/2015/10/23/howto-gmscore.html

Has been working reasonably well for ~10 days now. Note that I'm on Android 4.2, so I might have missed something with regard to newer Android versions.

just debunking the bogus "you are a nerd that has a pet peeve against google services". this affect lots of users overseas or in poorer markets than san francisco.

amazon phones don't ship with google service. cheap samsung models (most dual sim ones) sold overseas don't ship with it either. the cheap chinese phones don't have any google service. ...and those are only the ones i saw. i'm sure india/africa/europe have even more cases.

Close, it's less about propriety software and more about centralisation of services. I definitely tend towards open-source but it's not a dealbreaker, I just don't want to live in a world where my life is completely tied to Google. As good as a lot of their apps are, I hate the idea of the "ecosystem" that these companies are building.

I just want a messaging app that messages and doesn't imply a bunch of other services from another company. I'm aware that's easier said than done, I just hope the end-game of instant messaging isn't "Apple or Google?". To continue your comparison with mobile phones, you can have a SIM from any network and still communicate with people.

I'm going to try GcmCore that's been posted in this thread, it sounds interesting.

To be completely honest, it's not a die-hard opinion and will no doubt change a bit in the future. Technology is progressing and changing so fast, I don't want to go with the flow without questioning directions it's going in.

I know this is a niche choice, I don't expect anybody to cater to it specifically, I'm just happier putting together smaller apps that do what I want instead of installing an entire ecosystem. Hope that all makes sense.

EDIT: Just realised after pressing send that the difference in my mobile phone analogy is the customer obviously pays to use it, maybe I'd be happier with paying for the network, I don't know. Doubt there's a market for that though!

I'm not an Android developer so I hope my mental picture of what GCM does isn't off.

> My sense is that this isn't because you find the communication over GCM to be inherently offensive (it's just a tickle, after all),

Using GCM still means that Google could suddenly stop to relay the messages for some users, right? (Say, those who seem to be using a non-official reimplementation of GCM...). Then the service would suddenly stop working for these users. So I'd still rather be able to avoid relying on the GCM backend at all, if that's possible.

> What I don't understand is why nobody just writes an API-compatible open source implementation of play services

Couldn't the Play Services API change without warning? It is sensibly designed so another implementation wouldn't be too hackish?

People shouldn't have to reimplement such things by mimicking Google's API. In principle, there should be a documented and stable standard, not hacky reimplementations.

I agree, though, that probably the way to go would be to first build a different messaging system like this (maybe using XMPP as a backend?).

It's mostly because there aren't any real alternatives. Building a world wide push messaging network is really hard (you have to deal with carriers a lot and convince them not to close your long running connections after 5 minutes). That said, the servers support websocket connections as well. I don't know the current state of client support. Also, a Chrome/Chromium extension is in the works.

Making push notifications work well is hard, so it's better to just use what's available. There are alternatives, but the alternatives aren't free at all. See: https://pushy.me/

Just send heartbeats and reconnect if needed?

Only real problems I see are hosting costs and preventing misuse, plus some minor coding work.

See here for a version that uses websockets instead of Google services. It's usable on Blackberry OS 10 so should be usable on other non-google devices.

http://forums.crackberry.com/android-apps-amazon-store-apk-f...

What does it send via googleplay other than "please connect to the server now"?

it does require to have the google play services installed in the first place. so for those who i.e. run cyanogenmod without the google play services installed, it's unfortunately not possible to use Signal/TextSecure.

microg's GmsCore (an unprivileged open source reimplementation of Google Play Services) can do Google Cloud Messaging and should work for Signal.

This looks interesting.

Thanks!

It sends messages through Google's messaging framework. Of course the messages are end to end encrypted, so there's no security risk. It's just really hard to set up a global push messaging framework unless you have the clout of, say, Google.

I believe it doesn't actually send the message content through GCM anymore, but just notifies the client that a new message is available and tells it to connect to Open Whisper Systems' server for the content.

Does it actually use Google Play Services during normal operation or does it just depend on the Play Store for installation?

Great! I've been using Signal for iOS and while it's not yet comparable to WhatsApp feature-wise, it's for sure good enough to use.

I find it very difficult to get people to switch from the walled gardens of iOS messaging and WhatsApp (WhatsApp dominates the Dutch market for interesting historical reasons). I've been able to get a handful of privacy conscious friends to switch to Signal/TextSecure, hopefully the cross-platform branding makes this a bit easier.

> switch from the walled gardens of iOS messaging and WhatsAp

Doesn't Signal require my phone number? Isn't it dependent on the Whisper servers? Why isn't it a walled garden then?

>Why isn't it a walled garden then?

Because the client and server are both OSS?

https://github.com/WhisperSystems/TextSecure

https://github.com/WhisperSystems/TextSecure-Server

Can I download the the Signal client from any store and then point it to my own server instead of Whisper's?

Did anybody try to run his own server? Can such setup really work?

You can run your own server, but there's no federation.

The reason for that I imagine is that they want a privacy preserving automatic lookup method (a single server can confirm phone numbers and allow privacy preserving contact list comparisons for its own clients), and aren't convinced of using a model where the public key is the identifier instead of your phone number.

Have you actually tried it, or do you know somebody who have tried? Is the client really fully independent on Whisper servers? Can it work without the mobile connection, just with WiFi?

Does the voice communication work?

I'm asking all this because it seems that the server code was earlier in "you can look but it's not enough to run it" state?

I've run the server source as a private textsecure chat app. You can run your own without the proprietary gapps framework app too by mimicking what GCM does on your own back end, and it works with wifi if you change the identifiers to email/nicks instead of phone numbers, but this was for a small number of coworkers nothing of massive scale. This was for business communication from China since at that time TS wasn't working very well behind the GFC but they added another server around that time (I assume, all connections got better) so we abandoned our hacked fork for regular TS/Signal.

I have read of people on the mailing list who appear to have the server running.

There used to be some documentation about running it, but it was removed from the repo (presumably because they didn't want to dedicate resources to supporting it, but that's just a guess).

I believe it was always designed to allow for federation but I haven't heard anything about that for a long time now.

Is the RedPhone server component open source?

I have been using Signal (and TextSecure before that) for a while. The two features that would make me use it more would be:

1. Web client. (I send most of my texts from my laptop, which means I use Hangouts)

2. Search messages on the client.

Thanks for a great product and keep up the good work.

A browser extension for Chrome/Chromium is being worked on! You can track it at https://github.com/WhisperSystems/TextSecure-Browser

Seems like it would be a natural fit for Firefox over Chrome, but I understand the market share is larger with the latter.

Looking forward to it!

Why is a browser extension needed in this case? Does not the browser expose a source of randomness that would be enough to write the rest of the crypto in JS and use that?

To prevent MITM against a web page.

That's excellent. Installing and using GPG (or GPGTools or GPG Keychain or whatever it's name is) on OS X is awful.

Something that's still OSS and cares about UX (like Signal on iOS) would be fantastic.

> That's excellent. Installing and using GPG (or GPGTools or GPG Keychain or whatever it's name is) on OS X is awful.

I don't understand what's so difficult here. The biggest problem is understanding how PGP works, and having to type a password now and then. I use it all the time, to sign - not encrypt - my mail.

Finding the app (not the source code), finding out what three names mean (as already discussed), finding which app to launch, realising it only works with Apple Mail and the shell are all parts of the current experience.

Another study on a different client, but same thing: http://www.scmagazineuk.com/modern-pgp-is-unusable-according...

OpenKeychain ported to computers, maybe?

As was mentioned on another HN thread, why the ridiculous name? "Signal" is an already widely used term when talking about mobile communications. With cell phones in particular.

"I'm trying to get signal on my phone" or "I'm trying to get Signal on my phone". Great(!)

It was originally going to be called "Whisper" (by Open Whisper Systems) ==> https://whispersystems.org/blog/a-whisper/

The name was changed after Whisper was launched https://whisper.sh/

Can you suggest a better name?

Naming conflicts are a major problem - legal trademark implications, branding issues, searchability, etc etc. A name collision with someone, especially in a remotely similar industry, is problematic.

I'm not sure, there are tons of professional marketing/branding/PR firms who do this really well. TextSecure et al were acquired, IIRC. If the parent company has 50k to throw around, approaching W+K might be a good investment.

Edit: Mea culpa. It was WhisperSystems not OpenWhisperSystems which was acquired, both of which were founded by Marlinspike. This, incidentally, proves my point that naming similarities (WS vs OpenWS) within a similar domain (both mentally associated as "moxie" projects in my mind, in this case) can lead to problems.

> TextSecure et al were acquired, IIRC. If the parent company has 50k to throw around, approaching W+K might be a good investment.

No, moxie's previous company (Whisper Systems) was acquired by Twitter (iirc), Open Whisper Systems is a different project. See https://en.m.wikipedia.org/wiki/Open_Whisper_Systems and https://en.m.wikipedia.org/wiki/Whisper_Systems

Only if you talk about it in English which is a fraction of the potential market.

English: signal

Bosnian (Latin): signala

Bulgarian: сигнал

Catalan: senyal

Croatian: signala

Czech: signál

Danish: signal

Dutch: signaal

Estonian: signaali

Finnish: signaali

French: signal

German: Signal

Indonesian: sinyal

Italian: segnale

Latvian: signāls

Lithuanian: signalas

Yucatec Maya: señal

Norwegian: signalet

Querétaro Otomi: señal

Polish: sygnał

Portuguese: sinal

Russian: сигнал

Serbian (Latin): signal

Slovak: signál

Slovenian: signala

Spanish: señal

Swedish: signal

Ukrainian: сигнал

Welsh: signal

That the literal translations of the word 'signal'. At least in Germany that is not used for talking about a phone signal. It's 'empfang' (reception) instead. I am sure other languages differ as well?

Is Signal for Android open source like other things coming out of open whisper? I didn't see it on their github page [0]

[0] https://github.com/WhisperSystems

Signal for Android is effectively TextSecure v3+, with a new label. So it's TextSecure repo that holds Signal's code.

It is still called TextSecure on there.

What happened to short authentication strings? The SAS protocol is nicely documented in the Silent Circle Instant Messaging Protocol paper [1], but when I go to "Verify identity" in the app I'm asked to verify an obnoxiously long pair of hexadecimal strings.

The phone call feature supports it (with a curious lack of documentation), but it would be easy to imagine a UI that allowed verification without making a phone call and without allowing users to screw it up: one phone shows the SAS string, the other phone asks you to type it in, and neither phone allows IMs to be sent while doing this.

Axolotl (the crypto protocol used by Signal/TextSecure) never used SAS. The calling feature uses ZRTP, which does do SAS.

I'm really hoping for some intersection of Signal, Ricochet.im and Burner.

* Signal for the security piece.

* Ricochet.im for the Tor (optional?) and anonymous endpoint

* Burner for the idea that we can have lots of throwaway identities (if so desired).

Supporting android 2.3 is the equivalent of supporting Windows XP at this point. Why do it? Those Android 2.3 devices will be vulnerable as hell anyway, and I imagine it just makes it hard to support them, too, taking precious time from working on new features or cryptography. IMO, you should support only Android 4.1+ and up.

Also, I'm confused as to why Signal still asks to be my "default SMS app" when I thought the code to encrypt SMS texts was removed from TextSecure? Why would I still want my SMS's handled by Signal?

Because you want to store them on your phone encrypted, so that no one else can read them without knowing your passphrase?

Sure, the fact they're transmitted to your carrier in a 100% readable form removes most of the benefit of this, but it can still stop prying eyes from reading your texts.

Also, it's trying to be like iMessage. You have a single messenger, where you default to unsecure SMS for those contacts that don't have Signal, but default to secure messaging for those that do, all in the one app without you having to think about it.

I'm glad it's not called RedPhone for Android users, they may get it confused with YouRed I mean YouTubeRed I mean RedTube or whatever it's called now. In all seriousness though - what was (is) with the trend of apps with Red in the name? Red to me gives the idea of danger or something that's stopped / blocked.

There's a long history of calling a secure phone a red phone, like the connection between Moscow and Washington during the Cold War.

In the cheesy TV show from the 60s, Batman and the police commissioner had literal red phones that they used to talk to each other.

Ah! That's quite interesting and now that you say it I of course remember seeing red phones in films in such situations. Thank you for taking he time to reply.

Any ETA for the desktop version?

As long as it still requires Google Play I'll still consider it snake oil.

It uses Google Cloud Messaging. There needs to be a server in between and I believe GCM is free. Consider a situation where Bobs phone is switched off. Alice sends a message and turns off their phone. Now, Bob turns in their phone. How do we get the message Alice sent to Bob?

Give me some open source code that I can run on my own server to manage the notifications for me and for my friends, and allow me to tell the client app on my phone to use it.

That's way better than forcing me to rely on a specific Google server and protocol, which further requires proprietary software on the client.

See my comment here: https://news.ycombinator.com/item?id=10500188

In addition to what @newjersey said, you also need to handle push notifications, which in the context of a mobile phone aren't cheap at all. This is because you need infrastructure and because keeping connections open drains your battery and making it work well is wasted developer effort. This is why it is better to use whatever is available, like GCM on Android, APNS on iOS, or maybe Pushy (see pushy.me) or whatever Amazon does if you want distribution on alternative stores.

I just updated, after which I checked the settings. I noticed that auto-downloading in MMS text messages was enabled (moxie stated for a prior version that it was not, at that time), whereupon I changed the settings to disable. I may well be misinterpreting what I was seeing, but better safe than sorry.

(I'm stuck on Android 5.1 (not 5.1.1) on a Verizon phone. I was thinking of the ongoing Stagefright problems.)

If they would add support for sending pdf and doc files and any other file and release a desktop client it would be an unbeatable messenger.

Unfortunately when I used Redphone previously the call quality is pretty bad. The volume of the call would get screwed up and I know it's not to do with the signals (lol) because I would hang up and call the person back without redphone and it would work perfectly.

Redphone and Signal are all backdoor applications with bugs and exploits that i have found. Even the server is backdoor. Nobody in the security scene could use this, except a kid.

Does the calling functionality support any wideband codecs? I've tried RedPhone in the past, but the audio quality left a lot to be desired.

https://www.reddit.com/r/netsec/comments/3rc9br/psa_signal_f...

There seem to be concerns about the security of it.

Seems like the persistence for automatic VoIP authentication confirmation is currently disabled. Meaning you need to confirm our again each time. But have they confirmed this is in the release, not just in a development branch?

They have been encouraging people to read the two words on the screen on the start of every conversation forever, so I'm not really worried. Hopefully it will get back in, though.

Do they have ZRTP in the baseband of normal GSM call?

This is what I have been waiting for.

How would that work? ZRTP defines crypto for RTP. GSM does not use RTP.

It would probably make more sense to define something similar to ZRTP that does all signalling in-band through the audio channel.

No one has that

PrivateWave claim they have.

No they don't. It's not mentioned anywhere on their website.

Who am I to argue. You could use a standard modem software to create a data channel over voice.

https://web.archive.org/web/20150303132755/http://www.privat...

ZRTP/S

ZRTP/S is an extension to ZRTP protocol. It is designed to make ZRTP-secured calls work across Circuit Switched communication channels such as the traditional telephony networks (GSM, CDMA, PSTN, ISDN, etc) where internet protocol is not available.

On these telecommunication technologies peers can have a sort of “serial connection” through which they send and receive raw digital data.

The communication channel is so narrowband (9.6kbit/s) that it is not possible to run IP (internet protocol over IP) over it.

So, PrivateWave and Philip Zimmermann jointly designed and implemented ZRTP/S. It is a transport and security protocol for Voice over Circuit Switched channel, carefully adapted to be extremely narrowband and minimalistic.

After a year of researching and development, PrivateWave created a library, libzrtps. The library allowed PrivateWave to release the 1st version of PrivateGSM product - PrivateGSM CSD. It allows users to communicate securely in a point-to-point fashion with the ZRTP end-to-end encryption protocol and with a bandwidth as small as 5400bit/s.

Full specification of ZRTP/S and Source Code will be soon published. Anyone willing to create his own project, improve and eventually establish interoperability between Circuit Switched secure telephony (ZRTP/S over GSM) and Packet Switch secure telephony (ZRTP over IP) can benefit from the publications.

Interoperability represents one of the design goals of the ZRTP/S protocol.

Their android app description says they need an IP enabled network. GSM is not it. They may have it in their lab, but it's not in a real life useful product. Because it is not possible.

Look up the hardware device JackPair

Why not on my Nexus 7?

If you use a Nexus 7, you probably have a Google account, so you could use a Google Voice number to register.

Google Play doesn't make it available to the Nexus 7 (at least, I don't see it on mine).

It uses an SMS to register your phone number.

You can send the verification call/text to any old phone and type it in on the Signal device.

Reply on news.ycombinator.com