[personal profile] mjg59
Moxie, the lead developer of the Signal secure communication application, recently blogged on the tradeoffs between providing a supportable federated service and providing a compelling application that gains significant adoption. There's a set of perfectly reasonable arguments around that that I don't want to rehash - regardless of feelings on the benefits of federation in general, there's certainly an increase in engineering cost in providing a stable intra-server protocol that still allows for addition of new features, and the person leading a project gets to make the decision about whether that's a valid tradeoff.

One voiced complaint about Signal on Android is the fact that it depends on the Google Play Services. These are a collection of proprietary functions for integrating with Google-provided services, and Signal depends on them to provide a good out of band notification protocol to allow Signal to be notified when new messages arrive, even if the phone is otherwise in a power saving state. At the time this decision was made, there were no terribly good alternatives for Android. Even now, nobody's really demonstrated a free implementation that supports several million clients and has no negative impact on battery life, so if your aim is to write a secure messaging client that will be adopted by as many people is possible, keeping this dependency is entirely rational.

On the other hand, there are users for whom the decision not to install a Google root of trust on their phone is also entirely rational. I have no especially good reason to believe that Google will ever want to do something inappropriate with my phone or data, but it's certainly possible that they'll be compelled to do so against their will. The set of people who will ever actually face this problem is probably small, but it's probably also the set of people who benefit most from Signal in the first place.

(Even ignoring the dependency on Play Services, people may not find the official client sufficient - it's very difficult to write a single piece of software that satisfies all users, whether that be down to accessibility requirements, OS support or whatever. Slack may be great, but there's still people who choose to use Hipchat)

This shouldn't be a problem. Signal is free software and anybody is free to modify it in any way they want to fit their needs, and as long as they don't break the protocol code in the process it'll carry on working with the existing Signal servers and allow communication with people who run the official client. Unfortunately, Moxie has indicated that he is not happy with forked versions of Signal using the official servers. Since Signal doesn't support federation, that means that users of forked versions will be unable to communicate with users of the official client.

This is awkward. Signal is deservedly popular. It provides strong security without being significantly more complicated than a traditional SMS client. In my social circle there's massively more users of Signal than any other security app. If I transition to a fork of Signal, I'm no longer able to securely communicate with them unless they also install the fork. If the aim is to make secure communication ubiquitous, that's kind of a problem.

Right now the choices I have for communicating with people I know are either convenient and secure but require non-free code (Signal), convenient and free but insecure (SMS) or secure and free but horribly inconvenient (gpg). Is there really no way for us to work as a community to develop something that's all three?
From: [personal profile] mjh75
I just looked at my IRC logs and it would seem that you're in #coreos on freenode, which is a channel which is exposed into Matrix as #freenode_#coreos:matrix.org (thanks to folks like M-hash accessing the channel over Matrix). Whilst you may not have directly communicated with M-hash there, it does mean that you are (very) indirectly utilising Matrix already to communicate with folks.

However, both Hangouts and IRC are obviously not end-to-end encrypted (unless you layer it on top). So if you want the convenience of communicating to bridged users, you necessarily end up exposing plaintext and metadata at the gateway. So I guess this is a scenario where the tryptic of convenience/security/freedom breaks down at the expense of security. I'd still argue that one can still achieve security in a Matrix world without significantly compromising convenience by saying "hey, M-hash, any chance you can use an E2E capable client (e.g. a native matrix client like Vector or WeeChat, or a (currently) hypothetical axolotl-compatible 3rd party client like Signal, WhatsApp, Wire etc should they ever be bridged into Matrix.). You'd then continue the conversation in an encrypted room, and achieve the trifecta :)

In terms of Hangouts: nobody's written a hangouts bridge for Matrix yet; i'm not sure why as it'd be trivial to take one of the 3rd party libraries and hook it up. We're still quite early on in the process of building out bridges ourselves, but contribs from anyone reading this would be enormously welcome!
From: (Anonymous)
Except it'd be trivial to downgrade to plaintext by a state or corporate level adversary; simply intercept the connection and say "no, my client does not have these capabilities".
From: [personal profile] mjh75
E2E admittedly isn't deployed yet on Matrix (https://matrix.org/jira/browse/SPEC-162 has the gory details; we've written the ratchet but not finished the key management & UX stuff yet), so my answer here is somewhat speculative. However, the current design is that Matrix-connected rooms have immutable E2E configuration. It is *not* performed as a capability mechanism p2p between clients.

So, if I want to reliably converse with you with E2E encryption, I'd create a room whose initial event bakes in the requirement to use a given ratchet (Olm), with whatever PFS semantics are desired (e.g. advance the ratchet for every message and discard ephemeral keys => PFS, or perhaps only advance the ratchet on demand, to deliberately allow 'epochs' of history to be replayed on new devices or to new members of the room). If a room has E2E enabled, any plaintext content is ignored by well-behaving clients. The reason for making encryption state of a room immutable is largely to simplify the design.

Therefore an adversary cannot downgrade to plaintext within an existing room, or masquerade a plaintext room as an encrypted one. The most likely attacks are:

a) if a malicious client or bridge is invited to an encrypted room, which then participates in the E2E ratchet but then leaks the data elsewhere (e.g. by bridging to plaintext endpoints or publishing client logs to the web),
b) if a remote client is MITM'd and fingerprint confirmation checks fail. We've not decided yet how to do fingerprint confirmation for the public identity keys, but obviously some kind of OOB check is needed to confirm the identity of who you're talking to.
From: (Anonymous)
haevalencia@gmail.com (Hugo)

What do you think Telegram? ... I think it would fulfill quite well with many of your expectations. In my case, I made me very similar to yours questions and Signal not meet all I needed.

When I installed Telegram already had several of my contacts in it and now I have the majority. For each individual conversation I use secret chats default and even for groups there is only the possibility of chats in the cloud, do not talk issues of great secret with my teams, I also believe that in the future will be implemented something similar due to changes they have made similar applications.

In my work we use a custom client, but that does not stop to communicate with the official client or other forks available (On Android does not depend on Play Services and is optional). Finally, Telegram privacy policies and encryption system for the cloud chats give me confidence, even more than the service Signal (Metadata, location of the servers, etc.)

Cheers
From: (Anonymous)
haevalencia@gmail.com (Hugo)

At least I trust the judgment of the Electronic Frontier Foundation to establish a code audit (external reputable company, 12 months old, security structure, etc) and that gives me the confidence to use the service.

Are you referring to other audit?

Source:
https://www.eff.org/node/82654
https://www.eff.org/deeplinks/2014/11/what-makes-good-security-audit
From: (Anonymous)
There's this pretty lengthy thesis about it.
http://cs.au.dk/~jakjak/master-thesis.pdf

The only mentioned issues are way back into its first months of life, or a SHA1 collision problem assuming you had one of those shiny big mining farms.
Afaik since they added two step auth and they upped key size they are good.
From: (Anonymous)
Telegram has numerous problems. The central one is their homebrew combination of cryptographic primitives with some very dubious choices (sha-1 based key derivation, sha-1+IGE used as a instead of an encrypt-then-MAC or some other standard AEAD mode of operation, weird factoring of integers as a proof of work system inexplicably tied to the crypto protocol, MITM vulnerabilities and a reliance on a trusted server... These choices are arbitrary, and their justification for all of these seems to be "trust us we've got this covered, nobody claimed our prize money yet".
From: (Anonymous)
If you are talking about the SS7 MITM attacks, that something that I think happens with just any messenger out based on SMS checks out there.

Thankfully you can enable password auth at any time.

If you are talking about those possible in a reasonable timeframe SH1 collisions based attacks in secure chats, I think that has been fixed this february by upping key size

As per encrypt-then-MAC they have a faq entry that cite "performance reasons", and still no secure compromise.

Reliance on a trusted server (cloud chats) is quite about *convenience* most of people research.

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Member of the Free Software Foundation board of directors. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags