Hacker News new | past | comments | ask | show | jobs | submit | page 2 login
Why I won't recommend Signal anymore (sandervenema.ch)
328 points by maglavaitss on Nov 5, 2016 | hide | past | favorite | 334 comments



If they are only using GCM as a queue (and the messages are themselves encrypted) I don't understand what the problem is.

They could use anyone for that functionality. Even if the messages are given to an "adversary" what can they really get from that? Your phone app contacted the signal servers. That's really it.


They're not even using it as a queue, they're queueing and delivering the messages themselves. GCM messages are empty and are only used to wake up your device.


Redphone component.

I don't know why it's closed source. It's been suggested elsewhere in this thread that it was potentially IP issues they kept it closed for. Is it possible loose US CALEA law interpretation influences the reasoning? Or a gag?

I honestly don't know why they chose to do that but I wanted to comment in to see if a lawyer or someone from the project could hint at the reasoning.



This is the client component. The blog post and your parent were referring to the server component.


I'm working on a completely open secure communications suite based on TweetNaCl. Proof-of-concept prototype is here:

https://github.com/Spark-Innovations/SC4

Working on a better UI at the moment. Could really use help, especially beta testers.


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.


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.


> 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?

Yep, that's exactly how Signal has been doing it for >1.5 years now.


ahh. I just thought otherwise from some of the other comments here. Makes sense. Thank you.


I didn't have to recompile my kernel to use microg...instead I used FakeGApps with Xposed framework. instructions: https://github.com/thermatk/FakeGApps


Signal is to get people from SMS and iMessage -> Signal. This means that cross platform communication becomes secure in transit.

Once Signal and others have really wiped out all the insecure messaging people are doing, then we can start with the identity problem with phone numbers. GCM, Contacts, etc are all related to this "phone number as identity" problem.

RCS is an unfortunate grab in this space, and we need to move fast before RCS is the default, and we're back to insecure messaging.

Email addresses are the best form of "federated identification" but are wildly insecure for communication. Here's to hoping we can get some better ones.


For me I won't recommend it because of the horrible lack of options when you replace your phone (let alone lose it). No encrypted migrate. No backup options. Unencrypted loses content (images).

Plus there's no way to search old messages.


I guess these are all features. For example, how are you going to do a backup that restores when you lose the phone (and thus the private key)? In practice, you would encrypt the backup with a passphrase, and the user would choose "123".

Signal aims to be the most usable secure messenger, not the most usable messenger that also happens to be secure.


The truth which a lot of Moxie fans don't want to admit is he thinks there is nobody better to be entrusted with this project. I don't think this was ever meant to be a community project -- he just opened some parts so he could pretend it is. Also he is a limelight hogging security diva who always wants to be in the news and have people talk about him. If he allowed others to contribute and be recognised, he worries they might overshadow him.


The author offers no better alternative so I think that means the article speaks for itself: there's not much to do but whine. These are problems, sure, but they're minor when you consider that Signal is the most secure and user-friendly messenger we have on the market right now. If something takes its place, then great. Otherwise, we just will continue to use what is secure and actually works.


- Lack of federation

Use a federated secure protocol. Oh wait, there are none. Because if a problem appears you just can't fix it without breaking all federated clients. And then they will whine.

- Dependency on Google Cloud Messaging

Fair enough

- Your contact list is not private

Fair enough

- The RedPhone server is not open-source

While it would be nice that it was Open sourced I can understand them not releasing it (might be for IP issues)

tl,dr: "Signal does not work the way I wanted"


> Use a federated secure protocol. Oh wait, there are none. Because if a problem appears you just can't fix it without breaking all federated clients. And then they will whine.

That's why you have to design your protocol with backwards compatibility and versioning in mind, ala XMPP. I'm not going to pretend its perfect, but it works pretty well 90% of the time. It does mean clients have to implement versioning and feature negotiation and not just blindly assume everything else supports all the features they do; convincing client authors to do this is the tricky part.


There are really two federated protocols, xmpp and matrix. Matrix is pretty young but looks good, they just added e2e encryption.

Check out the Riot client, web, android and ios. The apps are even native.

Plus, you don't have to show your phone nr.


Umm... Tox?


Tox on mobile? Have you actually tried to use it? It drains your battery like crazy.


He didn't ask about that. He asked about a federated/distributed protocol that actually worked. Tox is one.


> Another issue, and a plus for using usernames, is that you may want to use Signal with people you don’t necessarily want to give your phone number to.

So, how do you know that the Edward.Snowden@signal you're communicating with is the same Ed Snowden that we all know about, and not some TLA stooge?


You're missing the point. Neither Phone number of Email address/username solve the problem you're proposing. But an email address/username is a lot more transient than a phone number.

I can change emails/usernames very easily and with little effort, and while burner numbers and applications that help that exist, changing phone numbers is not as easy and thus a significant percentage of users are unlikely to do it regularly. So you have a pseudo real ID that to the end user FEELS like it isn't you, but is a very strong (no pun intended) signal that it is to anyone looking in.

The phone number grants no you special verification of identity over an email address that doesn't involve an external verification mechanism (i.e, talking to the identity in person.)


By making user-names unique...?


funny enough, I was going to try out Signal today but stopped right after seeing the permissions they request: https://pbs.twimg.com/media/CwhFsLzXcAIDcMH.jpg:large


Well, everything is there for a good reason. (Though it escapes me right now why it needs permission to access the calendar.) How are you going to call someone over Signal if Signal can't use the microphone? If in doubt you can always check the source code – it's open source for exactly that reason.


How does Signal compare to Telegram? Would you recommend Telegram as better or worse then Signal.


On Signal, every message uses end-to-end encryption. Signal's servers can't see the messages you are sending, only you and the recipient can read them. Signal's encryption protocol is carefully scrutinized and follows best-practices.

Telegram sends messages in plain-text by default. Telegram servers have access to all plain-text messages that you send.

Telegram's private chats use end-to-end encryption. But they use an encryption protocol that they invented themselves that doesn't follow best-practices. Encryption experts have been critical of Telegram's encryption protocol since it was released. So your private messages might not be so private, either.

If you are doing something sensitive and want to stay out of prison, use Signal.


Actually, always use Signal unless you have contacts on Telegram that refuse to migrate. Consider all communication via Telegram to be on public record.


> Consider all communication via Telegram to be on public record.

Just because the protocol has flaws, doesn't mean everyone can exploit them.

On the other hand it's possible for Google to read every communication because they have root on your phone. So using Telegram [1] with a custom ROM without Google services (e. g. [2]) will make it harder for Google at least. Not easily possible with Signal.

[1] https://f-droid.org/repository/browse/?fdfilter=telegram&fdi... [2] https://copperhead.co/android/


> Telegram sends messages in plain-text by default.

This sounds like everyone has access to those messages. Better: Telegram sends messages client-server encrypted by default and since you can't run your own Telegram servers, this is a problem.


Why is the author asking for GPL?

Wouldn't a ISC/BSD-like license be better for the federation aspect?


If you aren't going to recommend anything else then sit down and shut up frankly. The world is made of compromises and saying I don't like your choices is pointless if it's effectively impossible to choose differently.


I am also very unhappy with the direction Signal has gone, but there's currently no alternative. I'd be interested in contributing to work attempting to replicate it, though.


I have some friends in an encrypted riot room right now. The olm could use a real good audit, but otherwise it is working right now. Federation is working, bridges are working, voice and video are working, it has Android and iOS clients. The only problem is the encryption doesn't apply to the voice / video or shared files yet, but they have made huge progress this last year from basically nothing so far.


+1. I'm super happy with the Matrix / Riot ("riot" is the client) crypto work over the last year.

It's such a relief to have a modern chat system that's FOSS, federates, and offers a liiiiitle more advanced UX than irc...


the Olm audit is done; we're hoping to publish it week of Nov 14 (alongside iOS & Android support).

Encrypted attachments was PRed this week: https://github.com/matrix-org/matrix-react-sdk/pull/533 (for the web; mobile will follow shortly)


Why isn't there an alternative? Signal uses the Axolotl protocol for encryption. There are already several XMPP clients that support the OMEMO protocol which is based on Axolotl (https://conversations.im/omemo/). And for Matrix (a modern alternative to XMPP) there's Olm which is also based on Axolotl.


At the risk of derailing this slightly, I wouldn't call Matrix a "modern alternative" to XMPP. The use cases are almost entirely different; Matrix isn't really suitable for realtime applications like XMPP is (because Matrix is all pull-based, so you have to query the server constantly to try and get messages in a reasonable time; this also means keeping the phone radio in active, high-battery-drain mode [pretty sure that's the technical term]).

Disclaimer: I do a lot of work on XMPP related things and rather like the protocol, so maybe I'm biased. I'm sure there are things for which Matrix is a better fit that I wouldn't use XMPP for too though.


Agreed that Matrix isn't a "modern alternative" to XMPP, but for different reasons. At its core, Matrix is a decentralised object database for conversation history (like NNTP). XMPP is a message passing protocol (like SMTP, but extensible).

Matrix is not "all pull-based" - that's just the baseline implementation. Folks have already implemented push-based transports for Matrix - e.g. COAP or WS.

edit: [Disclaimer: i work on Matrix]


You mean the Signal Protocol. That's its name. Axolotl was a name for a major component of Signal Protocol. Moxie and Trevor Perrin designed the protocol for Signal, and it's under active development. They own the protocol, its direction, and its documentation.

Other projects can adopt parts of the Signal Protocol, and doing that is certainly better than just making stuff up. But Signal owns the protocol, because the experts who own the protocol are attached to Signal.


Yeah, just to clarify: Olm (matrix.org/git/olm) is an entirely independent implementation of the Double Ratchet algorithm (based on Trevor's original public domain spec sketch, which was originally called 'axolotl').

It's not connected to Signal or Signal Protocol or Open Whisper Systems, and subsequently we've added an entirely different new ratchet (Megolm - https://matrix.org/docs/spec/megolm.html) to handle Matrix's specific requirements for E2E.


Crypto engineers tend to like the Axolotl design, which is an unusually serious cryptographic design for a messaging protocol (historically, messaging crypto has been cryptographically slapdash, with the exception of OTR).

But the reason crypto people are so positive about Signal Protocol isn't just that they like the ratchet. It's also that they trust the entire design of the system, not just the ratchet but all the rest of the cryptographic details, and also the oversight of the protocol.

It's kind of the same way that crypto engineers like stream ciphers designed as simple hash cores running in counter mode, but really what they like is stuff that Dan Bernstein designs --- they aren't encouraging you to go design your own hash-core based stream cipher!

So: it's good that these other systems adopting "Axolotl" are at least starting from a cryptographically serious place. But it's a bit jarring to see them reference "Axolotl" as if it answered the question of "why should we trust this cryptography".

A better answer would be to provide the bios of the people who designed and implemented the crypto in these systems.


Well, I hope on Matrix we've not been blindly namedropping axolotl/double-ratchet: instead we've tried to be as transparent as possible (more-so perhaps than OWS) in terms of speccing what we've been doing (https://matrix.org/docs/spec/olm.html, https://matrix.org/docs/spec/megolm.html, http://matrix.org/docs/olm_signing.html, https://matrix.org/speculator/spec/drafts%2Fe2e/client_serve... etc). Thanks to the Open Tech Fund we also got libolm audited by NCC Group - and we've ensured that the audit report will be publicly released (mid-Nov). Hopefully the audit & the code will speak for itself, and certainly speak stronger than bios.


I started NCC Group Cryptography Services. They're great, but I'm telling you, no: the bios are important. A single point in time audit doesn't make something secure.


Well, thanks for starting NCC Group Crypto then :) One can at least extrapolate from an audit - it surely tells you how competent the code is at a point in time, and how rapidly and competently any issues were resolved, and one can assume the same team will progress similarly.

In terms of bios: the folks working on libolm have 10-15 years each of professionally writing decent security-conscious native code, the vast majority of which (pre-Matrix) has been proprietary, with the exception of occasional contributions to things like Wireshark. I don't think they'd have described themselves as specialising in cryptography before embarking on libolm, but the team's learnt a lot along the way and the label might be more appropriate now. Ooi, what would you consider an appropriate bio? (short of being DJB or Moxie? :)


If wishes were fishes we'd all live by the sea.


Any service that owns valuable user data is going to get compromised eventually, whether they do it themselves, or are the victims of an attack. I feel like the only way to not get swept up in the surveillance state is to never put your data on one of these services at all.


The Signal app is stupid. It doesn't work intuitively as WhatsApp. It's incomprehensible that you need a phone number, it's incomprehensible that you can't compile it yourself.


What are your views about VoIP with ZRTP?


Nobody actually exchanges the initial words to avoid mitm. Hence, zrtp is actually no that secure in practice.


That's unrelated (off-topic) to Signal and what the blog post discusses, isn't it?


Though it wasn't explicitly mentioned in the blog post, Signal does support encrypted voice calls, so GP post isn't entirely off topic.


Add a lack of real desktop to this.


*real desktop client


>I’m pretty sure that Google could serve a specially modified update or version of Signal to specific targets for surveillance, and they would be none the wiser that they installed malware on their phones.

I'm not sure he understands how app signing works and why it would be impossible for Google to forge a developer's signature. He also seems to have a problem with GCM and Google in general. Perhaps he should look into writing his own secure chat application.


Why would they have to forge it? They can simply install a version that isn't signed on your system via an update.

Then later replace it with a signed version once they have the data they wanted. You would never know what happened.


Hmm... he mentions the Giphy thing at the beginning of the article, then never again.

The Giphy mention seemed really dangerous to me. Now I don't use Signal but I imagine it's 1) optional and 2) requests are proxified/anonimised through an intermediary (the Signal servers in this case). And why is this dangerous? Because this "don't build cool stuff on this serious app" is what makes people not use the app. It's creating boring, dull apps what stops them from becoming mainstream successes. If we are trying to make the public using secure apps because we believe in privacy, we have to make them appealing.

This is similar to the case of how nobody uses PGP because how horribly bad it is, UX-wise.

That said the rest of points he brings up are good. I just didn't like the Giphy mention, especially taking into account he didn't say anything else about it, he just brought it up.


Hi there! The Giphy thing is what set me off writing the blog post in the first place. Maybe I should've expanded a bit more on that in the article. As far as I can tell, the idea is that requests to the Giphy API gets proxied through Signal.

I don't see anything in moxie's blog post about whether this is optional. If it isn't and it's sending everything you type to the Giphy API then we have a whole new problem.

In the blogpost by moxie, there's the example of typing "Im excited", which then gets sent in multiple API requests to giphy (basically one of 'I', one of 'Im', one for 'Im+' etc.). Now, if this is an action you don't do explicitly (like pressing a button or something, to search for gifs), then it would basically send everything you type in order to continually search for gifs and then offer suggestions? It's not clear from the blogpost. I hope at least that this is not what moxie had in mind.


Giphy only occurs when you click on a button to add an attachment, and you have to click on Giphy, THEN you search for GIFs.


I promise that nobody is going to force you to use the GIF search. For a demo on how this feature works, check out the short video embedded into the blog post. [1]

I second the parent poster's question: "why is this dangerous?"

[1] https://whispersystems.org/blog/images/giphy.webm


It's not clear to me, but I assumed that that only happened if you tapped on a "search for gifs" button, which is something that can happen accidentally, but... that's unlikely.


"Otherwise, we’ll be in danger of ending up in an neo-90s Internet, with walled gardens and pay walls all over the place. You already see this trend happening in journalism."

The internet will never be less walled, more free, and more federated than it was in the 90's. With such a poor understanding of the internet and its history, even if he did make a compelling argument (he doesn't), it'd be hard to take seriously.


You're forgetting about AOL and Compuserve. The Internet itself was federated. Networking really wasn't.


I forgot them on purpose because he's talking about the Internet, not networking, not BBSs (which AOL and Compuserve were just big versions of). AOL and Compuserve eventually made themselves just another part of the Internet, but before that, they were really irrelevant in relation to the Internet's federation. In fact, other than AOL being an ISP and a gateway to the Internet for many, the actual AOL service was completely irrelevant once Internet connections came along.


> The big question now... is what post-Signal tool we want to use. I don’t know the answer to that question yet

Oh.


[flagged]


Even if you knew what you were talking about here, you can't make accusations like this on HN. You've been here for over 3 years now, and should know better.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: