News for hackers. Stuff that matters.
Re:A Formal Security Analysis of the Signal Messaging Protocol by moyta on Tuesday November 08, 2016 @07:06AM (#12899552)
Its great that the underlying Signal protocol is secure, my major worry is how do we get more people to use it, and how do we make it more reliable?

As it stands right now, Signal is used exclusively by the moderately technically inclined, with a little over 1 million users. In a perfect world, it would be bigger than Whatsapp, which uses libsignal but has many metadata related issues, and also misses many older demographics in the US. Additionally, server reliability has been something like 710hrs out of 720hrs usually every month, with an outage just this last Saturday from 19:51 to 22:08 PST for everything but ZRTP calls.

I know Moxie will likely never allow interoperability with his servers after the cluster that was CyanogenMod WhisperPush interop, but we need something to allow for self hosting or alternative hosting, Signal's servers are not bulletproof and a local server in remote areas can be invaluble, essentially XMPP with Conversations is all we have in this arena right now.

Re:A Formal Security Analysis of the Signal Messaging Protocol by moxie on Tuesday November 08, 2016 @11:23AM (#12901483)
Hmm, I'm not sure where you got these numbers, but none of them are correct. Ten hours of downtime a month? We measure this pretty obsessively, and haven't had that much downtime in a three year period.

I appreciate the sentiment for what you're saying, but our direct user growth has surprised even us (again, not sure where you're getting your numbers), and Signal Protocol is now on over two billion devices.

If your major concerns are reliability and user growth, I think federated protocols are likely to exacerbate rather than improve those conditions -- as we've seen with XMPP historically. However, I would love it if you proved me wrong. Signal can be deployed in a federated environment today, let me know if you need any help setting it up.

Re:A Formal Security Analysis of the Signal Messaging Protocol by moyta on Tuesday November 08, 2016 @07:35PM (#12905235)
This is what I've observed on T-Mobile, Centurylink and Comcast over the past month across two phones, it does allow me to backdate messages and send them later at least, so not a total loss.

In regards to federation for Signal, what are you looking for in terms of technical competence and skills? I'm already intimately familiar with running servers, VOIP, SMS delivery, etc so I've got a good grip on things, and I'd like to tie in our existing PBXes with Signal whereby ZRTP calls go straight to endpoints, perhaps we can force the issue with Grandstream and get them to add ZRTP support on device for their GXP2140 & GXP2170 phones.

Re:A Formal Security Analysis of the Signal Messaging Protocol by webmaven on Tuesday November 08, 2016 @06:12PM (#12904799)
How many direct users does Signal-the-app have?

If you can further narrow that to active users per $TIMEPERIOD (for example, MAU), that would be great.

Re:A Formal Security Analysis of the Signal Messaging Protocol by widforss on Tuesday November 08, 2016 @07:42AM (#12899736)
I find it's really easy to get people to use it. I tell them to install it and then use it as my primary communication channel with them. As I do this with more and more of my contacts some of them will have each others numbers and will automatically be able to talk to each other via Signal.
Re:A Formal Security Analysis of the Signal Messaging Protocol by hambofus on Tuesday November 08, 2016 @09:18AM (#12900363)
I have no problem to get people to use it, the problem is to get people to keep using it.

For example some time ago when Signal was still called TextSecure, we converted all our group chats for a friend group of technically minded people to TextSecure. We all agreed that encryption is important and worth some minor discomforts. We switched back to Facebook (which we all dislike) within a month because TextSecure didn't have consistent message ordering in group chats, making some conversations impossible to understand for those unfortunate enough to receive messages in a bad order.

Re:A Formal Security Analysis of the Signal Messaging Protocol by moyta on Tuesday November 08, 2016 @09:28AM (#12900446)
This is mostly fixed as of a few months ago, the desktop client also makes it as convenient as Facebook.
Re:A Formal Security Analysis of the Signal Messaging Protocol by m-p-3 on Tuesday November 08, 2016 @10:03AM (#12900745)
The problem is that they chose to make it a Chrome Apps, which will eventually be dropped from all plateforms but ChromeOS.
Re:A Formal Security Analysis of the Signal Messaging Protocol by angry_octet on Tuesday November 08, 2016 @06:01PM (#12904725)
You can't really complain about the choice of the best option at the time, just because it's owner subsequently killed it. I think it was madness and internal Google politics (because it competes with Android Dalvik JVM apps ) that killed it, not technical problems.
Re:A Formal Security Analysis of the Signal Messaging Protocol by moyta on Tuesday November 08, 2016 @10:43AM (#12901099)
True, I assume they'll just ride that till the bitter end and then unhappily move to using nwjs instead of Chrome, and distribute it from their website instead (even though they seem highly opposed to that).
Re:A Formal Security Analysis of the Signal Messaging Protocol by m-p-3 on Tuesday November 08, 2016 @01:36PM (#12902742)
I wouldn't mind if they decided to make an Electron app instead.
Re:A Formal Security Analysis of the Signal Messaging Protocol by striking on Tuesday November 08, 2016 @02:06PM (#12903004)
I would, I really dislike Electron. Even Chrome Apps are a pain. I would be much happier with a native implementation.
Re:A Formal Security Analysis of the Signal Messaging Protocol by admax88q on Tuesday November 08, 2016 @07:29PM (#12905209)
Or a fucking website
Re:A Formal Security Analysis of the Signal Messaging Protocol by MichaelGG on Tuesday November 08, 2016 @08:05AM (#12899858)
Yeah, same here. Except then messages arrive out of order, duplicate, for another session, "bad encrypted message", or simply take minutes to deliver. I don't understand why duplicates are even possible.

So while I'm able to get people to try it out or use it for "sensitive" stuff, these issues really hurt usage and I'll just end up reverting to SMS once a day at least.

Edit: I don't want to sound to be complaining too much. I love Signal and try to convert people. Just hard when basics mess up. And it's also frustrating because on the surface some of this stuff doesn't make sense.

Re:A Formal Security Analysis of the Signal Messaging Protocol by moyta on Tuesday November 08, 2016 @08:21AM (#12899967)
I experienced this with TextSecure over a year ago, but since then it has been smooth sailing outside of minor outages (10hrs a month), since the outages are less than the regional outages we've been experiencing on AT&T and T-Mobile for SMS as of late (20 to 30hrs a month). Calling has also improved quite a bit, for Signal enabled contacts I've been using it exclusively for the past 9 months, I can be driving for an hour without call quality issues and maintain a stable call reliably.
Re:A Formal Security Analysis of the Signal Messaging Protocol by JshWright on Tuesday November 08, 2016 @08:45AM (#12900140)
Is the codec choice any better? The last time I tried to use it the audio quality was awful.
Re:A Formal Security Analysis of the Signal Messaging Protocol by haffenloher on Tuesday November 08, 2016 @09:21AM (#12900387)
Audio quality has been good enough for me, but there's definitely room for improvement as they're still using Speex (if I'm not mistaken).
Re:A Formal Security Analysis of the Signal Messaging Protocol by moyta on Tuesday November 08, 2016 @09:31AM (#12900468)
If they'd use Opus I'd really appreciate it, hell, if I could even get interop, I have hacked together an app to pass the ZRTP codeword to my deskphone when Freeswitch terminates it and reencodes it as SRTP/TLS for it, since no deskphone vendor supports ZRTP.

Would make those that insist on ZRTP in my life a lot more convenient to have extended convos with.

Re:A Formal Security Analysis of the Signal Messaging Protocol by lorenzhs on Tuesday November 08, 2016 @09:13AM (#12900328)
I use it for calling when abroad, and so far the audio quality has been quite good. I don't know if it was worse in the past, but maybe just give it another try?
Re:A Formal Security Analysis of the Signal Messaging Protocol by newman314 on Wednesday November 09, 2016 @10:56AM (#12911110)
My major problem is when a contact stops using Signal for some reason (new phone etc.).

My messages go into the ether without any indication that they are not being received.

Re:A Formal Security Analysis of the Signal Messaging Protocol by MichaelGG on Wednesday November 09, 2016 @01:31PM (#12913139)
You should just get single-check meaning server received it but not the other user's device.
Re:A Formal Security Analysis of the Signal Messaging Protocol by nickpsecurity on Tuesday November 08, 2016 @11:21AM (#12901464)
That's the kind of stuff I was getting on TextSecure and RedPhone. Many people refused to use it after it happened enough. Just the tech types that are hardcore about privacy.
Re:A Formal Security Analysis of the Signal Messaging Protocol by mtgx on Tuesday November 08, 2016 @10:05AM (#12900758)
In other words, the Chrome evangelist strategy (or Firefox evangelist strategy prior to that): Let me install this app for you - trust me, it's much better!"
Re:A Formal Security Analysis of the Signal Messaging Protocol by kombucha2 on Tuesday November 08, 2016 @11:53AM (#12901789)
way easier than others...wickr etc
Re:A Formal Security Analysis of the Signal Messaging Protocol by Y-bar on Tuesday November 08, 2016 @08:45AM (#12900139)
One hurdle for me (at least) is the lack of export/import/backup. I got a new phone recently and discovered that there was no way to restore message conversations onto the new phone.

This might not be a deal-breaker for some, maybe even a very nice feature for some, but for me it made me go back to other services.

Github issue: https://github.com/WhisperSystems/Signal-iOS/issues/967

Re:A Formal Security Analysis of the Signal Messaging Protocol by moyta on Tuesday November 08, 2016 @10:38AM (#12901055)
At one point Signal had working backup & restore on Android, whereby you could keep your private keys and seamlessly move between phones, but they did away with that since a few users encountered bugs.

I really wish they hadn't axed it, it was a lot easier to use it than do an adb backup of the app & data.

Looking at that GitHub issue, Moxie appears to have popped in for half a second out of annoyance, then the main repo maintainer michaelkirk went and locked & limited the issue to just contributors.

Re:A Formal Security Analysis of the Signal Messaging Protocol by lorenzhs on Tuesday November 08, 2016 @11:39AM (#12901645)
The problem with backup & restore in Android was that it didn't work reliably. I know first-hand. If the feature isn't there, people won't rely on it, as they may do when it's there but doesn't work.

The thing with locking issues is that Signal issues get so much noise that the content will drown in it. I dislike not being able to add on-topic comments, too, but I understand how they got where they are.

Re:A Formal Security Analysis of the Signal Messaging Protocol by Y-bar on Wednesday November 09, 2016 @06:01AM (#12909170)
I'm ignorant on how backups works on Android, but I have never met an iOS app where data has not been properly backed up and restored. Supposedly this works fine: https://developer.apple.com/library/content/documentation/iP...
Re:A Formal Security Analysis of the Signal Messaging Protocol by lorenzhs on Wednesday November 09, 2016 @10:43AM (#12910974)
It was a feature in the app to export an encrypted backup to external storage (encrypted with a passphrase of your choice), independent of OS-provided functions. It basically serialised and unserialised its own database.
Re:A Formal Security Analysis of the Signal Messaging Protocol by h4waii on Tuesday November 08, 2016 @10:03AM (#12900748)
Just to clarify, this is iOS only.

On Android, the client can export plaintext messages to storage, or you can use something like Titanium Backup, which wraps up the app installer AND data directories in a tarball and can restore it across other many different versions of Android.

Re:A Formal Security Analysis of the Signal Messaging Protocol by rosshays on Tuesday November 08, 2016 @09:59AM (#12900708)
The lack of some good history mechanism is what has always kept me away from this kind of software. But I don't know how we could possibly get the kind of messenger I would dream of (secure/encrypted, history backup to cloud, and web app for messaging).
Re:A Formal Security Analysis of the Signal Messaging Protocol by Veratyr on Tuesday November 08, 2016 @02:11PM (#12903042)
> essentially XMPP with Conversations is all we have in this arena right now

There's also Matrix (matrix.org). Took me about half an hour to set up a homeserver, has federation and TLS for now but full end to end encryption is already in beta (since I'm using my own homeserver I'm fine with just TLS) and Riot, the biggest client, is easy to set up and use. My wife is rather opposed to new things and isn't amazing with technology but she's happy enough with it.

Conversations on the other hand was a pain to set up self hosted (more Prosody/eJabberd's fault though) and had silent message send/receive failures.

Re:A Formal Security Analysis of the Signal Messaging Protocol by Adverblessly on Tuesday November 08, 2016 @11:54AM (#12901793)
> how do we get more people to use it?

For me the missing link is a good, native Linux client. Signal would have "got" me the last time I was shopping around for a communication app if it had that. Then again, I probably represent maybe 0.01% of the audience you are trying to reach...

Re:A Formal Security Analysis of the Signal Messaging Protocol by HurrdurrHodor on Tuesday November 08, 2016 @07:43AM (#12899745)
Note that while they do not retain or analyze it Signal offers no metadata protection either.
Re:A Formal Security Analysis of the Signal Messaging Protocol by moyta on Tuesday November 08, 2016 @08:17AM (#12899944)
Exactly why I like XMPP, it allows me to protect my metadata from leakage, if I could get normies to use it for more than a few weeks.
Re:A Formal Security Analysis of the Signal Messaging Protocol by haffenloher on Tuesday November 08, 2016 @09:18AM (#12900360)
> Exactly why I like XMPP, it allows me to protect my metadata from leakage

I read this frequently, but I'm still not sure how this is supposed to work - would you care to explain?

Re:A Formal Security Analysis of the Signal Messaging Protocol by moyta on Tuesday November 08, 2016 @09:34AM (#12900506)
Say I run the server under my control, and I talk to other people on and off my server via XMPP. What is occuring is my laptop, phone & tablet are connecting back to my XMPP server, which then connects to those clients, thus not leaking my IP address, OS, etc. Additionally, I can tunnel this all over CJDNS or OpenVPN and nooone will be the wiser that I am even using XMPP.

Comparatively, as it stands now Google is getting a bunch of metadata on Signal users, such as when messages are sent and received and from which device, IP addresses, OS info, etc.

Re:A Formal Security Analysis of the Signal Messaging Protocol by moxie on Tuesday November 08, 2016 @11:46AM (#12901715)
> Say I run the server under my control, and I talk to other people on and off my server via XMPP. What is occuring is my laptop, phone & tablet are connecting back to my XMPP server, which then connects to those clients, thus not leaking my IP address, OS, etc.

Here it seems that you're defining "metadata" as your IP address (and OS?). That's kind of a non-standard definition of "metadata" in this space -- most people approach the topic more concerned about who is communicating with who.

Email is federated, and I run my own mail server, but almost every single email I send or receive has GMail at the other end of it -- so running my own server does not provide me with any meaningful metadata protection, even though it is a federated protocol. The idea that everyone in the world is going to run their own mail server (or messaging server, or whatever) has not born out in practice, even in environments that natively support federation.

I think serious metadata protection is going to require new protocols and new techniques, so we're much more likely to see major progress in centralized rather than distributed environments (in the same way that Signal Protocol is now on over two billion devices, but we're unlikely to ever see even basic large scale email end to end encryption).

If all you want to do is hide your IP address, it sounds like you should just use Tor or a VPN.

> Comparatively, as it stands now Google is getting a bunch of metadata on Signal users, such as when messages are sent and received and from which device, IP addresses, OS info, etc.

This is not true. You're referring to GCM? The only thing GCM does is wake up a device to connect to the Signal server when the app is running in the background, nothing is actually transmitted over GCM.

Re:A Formal Security Analysis of the Signal Messaging Protocol by anc84 on Tuesday November 08, 2016 @03:12PM (#12903529)
> The only thing GCM does is wake up a device to connect to the Signal server when the app is running in the background, nothing is actually transmitted over GCM.

I consider myself an educated Signal user and I had no idea about that. Preach it, shout it, this is great for everyone who thought "GCM == messages"!

Re:A Formal Security Analysis of the Signal Messaging Protocol by padraic7a on Tuesday November 08, 2016 @10:33AM (#12901002)
I can't see that allowing for self-hosting / federation will do anything to drive adoption.

If that was the case then Conversations would be bigger than Signal, but it just isn't

Improving server reliability is a separate thing.

Re:A Formal Security Analysis of the Signal Messaging Protocol by moyta on Tuesday November 08, 2016 @11:04AM (#12901301)
It could be like email, except with libsignal as its base. Federation definitely drove email to be as big as it is today, and it has made server reliability a non-issue (your server holds the message until the other server is online).

XMPP itself is huge, GCM is essentially just a frontend for it. Conversations is smaller than Signal in part due to Signal being around since 2011, and Conversations being created in 2014, and also Signal gaining many high profile endorsements, from Snowden to Hillary. Still, Signal is microscopic compared to Whatsapp.

Re:A Formal Security Analysis of the Signal Messaging Protocol by vog on Tuesday November 08, 2016 @08:07AM (#12899873)
> essentially XMPP with Conversations is all we have in this arena right now.

Maybe this isn't too bad. How does modern XMPP compare with Signal's protocol?

Since Signal refuses to learn from XMPP (especially the federated part), maybe the solution is to make XMPP learn from Signal. Then, Signal's failure to become federated would have been an important step to make XMPP finally useful for secure messaging.

Re:A Formal Security Analysis of the Signal Messaging Protocol by moyta on Tuesday November 08, 2016 @08:14AM (#12899926)
Its not too bad, XMPP is very easy with a good client like Conversations. That being said it is not for normies, over the course of a year Signal will be used and appreciated by normies, normies using Conversations meanwhile will go perma offline after a few weeks from what I've seen.

Conversations is essentially Signal but for XMPP, the problem is it doesn't blend in normal SMS and additional value adds to sweeten the pot for normies and keep them using it.