Live data from Hacker News

Why I won't recommend Signal anymore

sandervenema.ch

261–270 of 350 posts

Re: Why I won't recommend Signal anymore

#261

Like a lot of crypto-puritanism it is rather mixed up. He says he recommended Signal because it was easy to use (more consumer friendly I guess) and secure, then says he wouldn't have gone in the direction of making it easier to use and criticises the things that make it user friendly, like using phone numbers instead of usernames. He says he thinks the protocol is secure, then says he doesn't want it to use GCM beca…

I'm not a cryptographer. I .. am reasonably sure that no one would take me for a hipster. But two issues - or call it 'differences in opinion' - in that article are relevant for me: The inability to use the service without a mobile number and federation. I understand the rationale behind the former ("It's easier"), but I don't understand why it is mandatory. I could've been 1283783127356128531312 on Signal and option…

Wire can use e-mails or phone nunbers for IDs, so you can use the same ID on multiple devices. But the mobile UI is worse than Signal's and it's also it's not federated. The source for the clients is on Github. It does have desktop apps for Windiws and Mac and a web app that works in most modern browsers. It's in many ways better than Skype. You don't have to link it to your phone in order to send messages - just use an e-mail account. It's also run by a Swiss company, so the servers might just be outside of the US.

Re: Why I won't recommend Signal anymore

#262

Earlier quoted context omitted.

I'm not a cryptographer. I .. am reasonably sure that no one would take me for a hipster. But two issues - or call it 'differences in opinion' - in that article are relevant for me: The inability to use the service without a mobile number and federation. I understand the rationale behind the former ("It's easier"), but I don't understand why it is mandatory. I could've been 1283783127356128531312 on Signal and option…

Agree. I'm not a cryptographer and never claimed to be either. -- and I think it would be difficult to mistake me for a hipster. For one, I don't have that snazzy majestic beard.. Anyway, on to the point. :) Yes, the phone number thing is a policy decision by the Signal people. As I write in my article, it's maybe marginally easier to get connected using phone numbers, but I may want to communicate via Signal with so…

Use Wire then. You can either use you e-mail or phone number. Uses Signal OTR protocol and a single sign in for all your devices. The clients are open source.

IMHO Signal is only usable on smartphones. I don't want to link my desktop client with the phone, so I use Wire on the desktop.

Oh and Wire is a Swiss company. I see you run your blog off the .ch TLD.

Re: Why I won't recommend Signal anymore

#263

I highly recommend Conversations (disclaimer: I've worked on it in the past, although I'm not a project "member" per say): https://conversations.im/ It's open source, uses a federated, open protocol, and can do multiple types of encryption including OTR and OMEMO (an XMPP wire format that uses the Axolotl ratched devised for signal). It does not do VoIP, so it would just be for chat (although there is a large bounty…

Curious for next time I evaluate XMPP is there a list of servers recommended by the Conversations team that people could install themselves? My issue with XMPP is that on the same system I have at DigitalOcean where I could run: an IRC server, a Web Server, and a Mumble Server and extra goodies all together in one box, I couldn't effectively run a XMPP server that would stay up (it would crash). I would of kept at XM…

I use ejabberd for a client. Prosody is also nice.

Re: Why I won't recommend Signal anymore

#264
post #251
post #50

Earlier quoted context omitted.

I agree overwhelmingly with what you wrote, except that I want to point out that this isn't "crypto-puritanism". It's just hipsterism. The author isn't a cryptographer, and if you asked a panel of 10 cryptographic engineers what messaging system they'd recommend, 9 of them would say "Signal". The 10th wants you to use something else because they're working on an attack for that "something else", and want their paper…

I think these types of posts are also the inevitable result of people overestimating our organizational capacity based on whatever limited success Signal and Signal Protocol have had. It could be that the author imagines me sitting in a glass skyscraper all day, drinking out of champagne flutes, watching over an enormous engineering team as they add support for animated GIF search as an explicit fuck you to people wi…

Thanks for the clarifications.

> First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names).

This is very good.

> However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack: [federal subpoena]

Good, so Open Whisper Systems has no metadata. Do any third parties retain metadata about Signal messages?

There's also the issue of mobile numbers. I get that more-or-less anonymous numbers are doable. But arguably, most Signal users don't have anonymous numbers. However, maybe this is a non-issue, if the only data available are "the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service". Is that it?

Re: Why I won't recommend Signal anymore

#265
post #251
post #50

Earlier quoted context omitted.

I agree overwhelmingly with what you wrote, except that I want to point out that this isn't "crypto-puritanism". It's just hipsterism. The author isn't a cryptographer, and if you asked a panel of 10 cryptographic engineers what messaging system they'd recommend, 9 of them would say "Signal". The 10th wants you to use something else because they're working on an attack for that "something else", and want their paper…

I think these types of posts are also the inevitable result of people overestimating our organizational capacity based on whatever limited success Signal and Signal Protocol have had. It could be that the author imagines me sitting in a glass skyscraper all day, drinking out of champagne flutes, watching over an enormous engineering team as they add support for animated GIF search as an explicit fuck you to people wi…

> However, I would love it if someone proved me wrong. The Signal clients and server already support federation, so there shouldn't be any technical hurdles stopping the people who are really into federation from using our software to start their own federated network that demonstrates the viability of their ideas.

> If anyone needs help doing that, let me know. I'd be happy to help.

I appreciate that you would say this. I suspected that you actually felt this way despite your pragmatic approach outlined in that blog post. I'm a fan of federation, but I think the developers of federated systems have to take the problems outlined in your blog post very seriously and not defensively.

Re: Why I won't recommend Signal anymore

#266
post #145

Earlier quoted context omitted.

I think the author is mostly right. While Signal might have an excellent protocol, also well audited all this comes with some bad compromises. E.g. you are forced to run GCM, or you share your address book. Both are unacceptable to many people that really need secure end-to-end encryption.

GCM has practically nothing to do with the security/privacy of Signal, but it is the #1 "concern" that people who don't understand cryptographic messaging security feel they must relate about Signal.

Couldn't attacker (NSA) infer times of phonecalls/messages from GCM? This might not seem like much, but it is another piece of metadata...

Re: Why I won't recommend Signal anymore

#267
I haven't actually worked with GCM so please forgive me if this doesn't make any sense. I suggest that, instead of routing all messages through GCM, what if Signal could send a "wake up" message via GCM, and then let the app pull the encrypted messages directly out of Signal's servers? A wake up message would only be sent by the server if the message could not be received by the client via normal means (implying that the device is asleep).

An optional user preference could allow some dummy wake up messages to be sent at random moments during the day, to support plausible deniability, at the cost of slightly worse battery life performance. This would all happen silently and the user would only notice a message notification when the app successfully fetches a new incoming message.

Re: Why I won't recommend Signal anymore

#268
I know the redphone is library is just a binary blob in the github repository:

    https://github.com/WhisperSystems/Signal-Android/tree/master/libs/armeabi
But I always thought that .so was just a compiled version of this C++ source, which in the same github repository:

    https://github.com/WhisperSystems/Signal-Android/tree/master/jni/redphone
I haven't compiled it myself so I can't be 100% sure, but the C++ entry points matches the API the Java code is using. I presume it's written in C++ for speed. There isn't much to the C++ bits. It just pumps data through an encrypted RTP connection - CPU intensive but not particularly complex.

The server code is up there too - in fact it's all up there. AFAICT, Signal is completely open source.

Re: Why I won't recommend Signal anymore

#269
post #222

Earlier quoted context omitted.

I see I haven't replied yet to your first point: here goes. Of course clearly an alternative has to be at least cryptographically secure . I fully agree with you on that. I'm not recommending something that isn't, and certainly am not recommending Telegram or Cryptocat. An alternative needs to be as a bare minimum cryptographically secure. And then on top of that it would be very nice if there was federation, not tie…

But you seem to be hand-waving away the problems Moxie had with federation [1]. Citing xmpp is not a counterexample. Some problems do not have solutions. [1] https://whispersystems.org/blog/the-ecosystem-is-moving/

Whilst some problems are not solvable, it doesn't mean that they are showstoppers. See https://news.ycombinator.com/item?id=12882181 elsewhere in the thread.

Re: Why I won't recommend Signal anymore

#270
post #251
post #50

Earlier quoted context omitted.

I agree overwhelmingly with what you wrote, except that I want to point out that this isn't "crypto-puritanism". It's just hipsterism. The author isn't a cryptographer, and if you asked a panel of 10 cryptographic engineers what messaging system they'd recommend, 9 of them would say "Signal". The 10th wants you to use something else because they're working on an attack for that "something else", and want their paper…

I think these types of posts are also the inevitable result of people overestimating our organizational capacity based on whatever limited success Signal and Signal Protocol have had. It could be that the author imagines me sitting in a glass skyscraper all day, drinking out of champagne flutes, watching over an enormous engineering team as they add support for animated GIF search as an explicit fuck you to people wi…

Push notifications without GCM can be done without losing reliability or ruining battery life, but it's difficult. There are a few apps like Conversations doing it well but it's quite rare. GCM is still technically more efficient since it's reused across multiple apps, but it doesn't really matter especially without a large number of apps doing this.

There's already a built-in warning on modern Android because apps need to request a battery optimization exception just as they would one of the dangerous permissions. Otherwise, GCM is the only way they be woken during Doze / App Standby for push notifications. Apps can't simply poll anymore. It's unfortunate that even an app doing a great job like Conversations gets a warning / prompt about this but there's little that can be done about that beyond the OS whitelisting the keys for known good apps.

Conversations is pretty much the only viable option without GCM. It uses a take on the Signal protocol via XMPP (when supported by the other contact) so you helped to make that happen anyway.

Post reply on HN