It’s still too soon to tell, but do we finally have an alternative to Signal? I see a lot of folks asking about Wire Messenger. A lot of the same questions and I thought I would help on answering some of these questions. #1 Why is everyone switching and why should I when we have Facebook, Signal, Wickr, WhatsApp, etc. and #2 Is it secure?
If you don’t want to read the long-winded article and aren’t technical – short answer: The UI and experience is awesome, and much more interactive and appealing than Signal. For security, doesn’t require a phone number (Signal does require your phone number) and yes – it is secure for messaging around the security/cryptography and protection of communications. I am cautious on the Video/Audio functionality although Wire has stated they are addressing the security concerns and going to be leveraging the same protections on AV as the messaging.
Now for the long-winded write-up.
Question Number 1: Why is everyone switching and why should I when we have Facebook, Signal, Wickr, WhatsApp, etc?
Currently – most companies that produce messenger or social media sites keep their clients and cryptography secret or at least closed. WhatsApp, Facebook, Wickr, etc. are good examples of this. Why that’s concerning with this model is that governments (such as the U.S. and the NSA) can request from these companies to potentially backdoor infrastructure, code, or cryptography to eavesdrop upon messages and communications which removes privacy and security. The debate around what the government should have access to and what it shouldn’t has been around for ages and not just the U.S. but every government with decent infrastructure and technical capabilities wants the ability to eavesdrop on their people. Oppressive regimes use it as a form of control, others like the U.S. and allies use it as a form of intelligence gathering, terrorism prevention, and surveillance. Not here today to discuss the politics behind all of this. The general opinion and policy from the United States is that they need access to decrypt communications in order to prevent terrorism and monitor adversaries. The counter point to that is decryption of secure communications through cryptography is the foundation for security, privacy, and the betterment of ensuring information is protected.
This is where Signal was born – a text messaging app which open sourced its client and cryptography methods in order to provide safe communications. In the security industry its been pretty much the de-facto for us for quite some time whereas other ones such as WhatsApp, Wickr, Facebook, etc. are not considered secure methods for communication due to the inability to identify if it is being monitored. Signal is awesome, and one of the most trusted secure communication platforms in existence today. The folks over at Whisper Systems are amazing, and we’re huge fans. There are also other alternatives coming out as well with the boom of privacy including Riot and others.
The reason people are giving Wire a chance is because it is built on the same foundation as Signal now. The communication protocols, encryption, and clients are now all open source. Just like Signal. Extensive review still needs to be done (see number 2 on this list) on if it is a solid platform, but it appears to be. One of Signal’s weaknesses is the requirement of having to use your phone number (privacy concern). With Wire you can use either your phone number (if you are comfortable) or just a username and not actually use a phone number.
Why this is important: It gives competition to Signal which traditionally has been the only viable option for people to use up until this point. Wire uses End to End Encryption (E2EE) and built on the same Double Ratchet and Off-the-Record which is the foundation of Wire and Signal.
I’ve used wire now for the past day – and I have to say it is WAY more feature rich with much more capabilities than Signal. Ability to expire and delete messages upon reading (very Wickr-like), Giphy integration (YES, secure Meme-Wars!!!), location setting, chat sessions, and much more. It honestly feels kind of like a secure Slack chat room, video calling (read more on the potential security issues in section 2 with audio/video), and text message platform that is way more interactive than any of the other messaging apps I’ve used. It’s a bit buggy still – noticed some lockups upon adding individuals, but a big perk for open sourcing is theres already pull requests and issues up for it to fix it. Signal’s desktop app has been in beta for years – this has a web version and a desktop version which is a plus.
You don’t have to switch – being a hacker – I like new tech, I like looking at how it works, I like trying something different, and I like trying to break it. You may not be the same and may not want to change, and that’s perfectly fine. This is just something for fun, and a way to do it securely. I’m pretty sure the first 15 seconds I have wire, I was added to a group where people were drawing pictures of top other peoples pictures (we won’t go into what was actually being drawn) and having a good time learning what the tool did. That’s the fun about it, and seems to be a very reliable way to keep in contact, and do it securely.
Having secure options for communication is a must and something that we should have multiple options in choosing. I like Signal – always have and believe in it’s mission for privacy and security. Wire appears to be on that same path, and from a user-experience perspective, Wire is much better.
Question Number 2: Is it Secure?
The verdict is still out but it has a lot of promise. I’ve started doing a code audit of the clients and protocols. All of the source code is available on GitHub and is heavily documented/commented. The big question is cryptography and protection. First – the protocol that is implemented within Wire is called Proteus – and is modeled off of the Signal Protocol (Double Ratchet Algorithm for key management) and Axoltl. This is well documented, and open source. It should be noted that just the clients, cryptography implementations, and protocols were open-sourced – not the server. The cryptography methods for client-sharing, keypair generation, prekeys, and everything else is well documented and considered best practices (minus the audio/video implementation), this is less of a concern and understandable to have the server closed source and does not impede the security of the app based on how the cryptography was implemented and maintained on the clients.
Wire’s entire registration process, APIs, encryption process, key storage, and protocols are well documented here:
End to End Encryption (E2EE) is negotiated between two clients (or more depending on chat session) and uses OTR using ratchet in order to establish communications (ChaCha20, HMAC-SHA256 as MAC, Elliptical curve Diffie-Hellman key exchange, and HKDF in key generation). Key pairs that are generated are stored unique on each device and generated during initial installation – one of the concerns initially was you needed to provide a phone number in order to register however that has been changed and can just use usernames as well without an actual phone number.
The way messaging works is that there is prekeys that are generated and uploaded with a public key. Each prekey can only be used once and only to the intended recipient and for each session that has been established with an individual. When sending messages users still need to compare identity key fingerprints very similar to Signal in order to ensure nothing is being man-in-the-middled although based on the cryptography – this would prove difficult unless someone re-registered or was being hijacked (again similar to Signal).
One weakness I did see is that calling using Wire uses the Opus codec and not the same level of cryptography as the entire app. Apparently this is being addressed and planned to fix soon. I should state – it is still encrypted, verified, and keys matched using SRTP and DTLS. Still not as good as it’s text messaging/asset encryption and a definite weak point. I would recommend staying away from the audio/video until this is addressed.
Application wise, supports TLS 1.2, 1.1, and 1.0. Always negotiates highest encryption to TLS 1.2 for web-based HTTP(s) traffic.
For key protection on the device – this seems to be the biggest weakness but is usually the case. Whenever you have
physical access to a system, anything is pretty possible. For Android and iOS – it’s marked to not export to iCloud or Android Backup for keys. On Android – some files that are downloaded are stored in a cached section on external SD cards – files are encrypted with AES128 – random keys are stored in a separate database. For iOS – normal sandbox protections through iOS (other apps can’t hit it) and local data is stored using NSFileProtectionCompleteUntilFirstUserAuthentication.
Clients are all open source for iOS, Android, Desktop, Wire for Web, Audio/Video components, the Proteus protocol and cryptography, and more.
Repos for Axolotl/Proteus/Cryptobox are all here:
proteus: Axolotl Protocol Implementation in Rust, then cross compiled for iOS and Android
cryptobox: High-level API with persistent storage for proteus
cryptobox-haskell: Haskell bindings to cryptobox
cryptobox-c: C-FFI to cryptobox
hkdf: HKDF implementation (RFC 5869) in Rust, then cross compiled to iOS and Android
Based on the initial review – this looks very promising and something that *could* be secure. I still have a lot of review to do and I am by no means a cryptography expert – just a coder that has used crypto a lot. The practices here are well within what is considered industry standard and code wise appear to be implemented/coded properly. Libraries aren’t rewritten or roll your own crypto and are well documented. Wire is using RFC specifications for things, and so far appears to be very promising.
It’s important to get this right, and make sure it’s done in a cryptographically safe way. If something is not technically accurate here, please let me know, and I will update this page with edits to clarify/correct.
This message was written by David Kennedy – Founder of TrustedSec.
EDIT: @HisKadi on Twitter pointed out a great article from the University of Waterloo which outlines many of the areas in the blog that I pointed out on concern around the statements on SRTP for audio/video: https://crysp.uwaterloo.ca/opinion/wire/.