Thank you for mentioning actor - I must have missed it the last time various open (federated) solutions were discussed.

It looks like an interesting platform, but I was a bit surprised by what I found at:

https://developer.actor.im/docs/encryption

"MTProto v2 Rev3 enables encryption support to replace or enchanse TLS one." So far so good - here's someone that's built on top of NaCl and built a legacy-free encryption system on top of well tested, known primitives, I thought.

But: "Actor encrypts message with US encryption and then again encrypt with Russian encryption that in result guarantee absolute encryption streight" (sic).

Uh. This sounds like applying a "political" reasoning to layering security: AES might be backdoored by NSA, GOST(?) might be backdoored by the FSB -- but using both, only double-agents will be able to foil our encryption!

While the truth is probably that you're know vulnerable to buffer overflows or other more mundane software errors in the now double-sized encryption code -- and get none of the (potential) benefits of a clean, modern architecture on top of just NaCl?

In addition, it appears you also use curve25591, possibly an implementation derived from NaCl:

https://developer.actor.im/docs/securing-server

"For secure communications Actor Server have to be configured with Curve25519 keys. To generate them, use actor-cli util:"

So that's three codebases worth of bugs, rather than one. Any plan to simplify this part?

Our encryption is based on Java and everywhere we check buffer overflows and possible timing-attacks. Hopefully we use AES and SHA256 that is easy to validate. Also Instead of using N code bases (one for each platform) we reduce it's amount by conversing sources from java to other languages for every platform.

US-based encryption is taken directly from BouncyCastle, time-proven library for Java. Russian implementation can contain bugs, yes, but i can guarantee that there are no timing or overflow attacks possible. Even when we will have broken russian layer, us layer will be safe. Also we are on the way to make everything verified by 3rd parties and seal cryptography parts.

For key exchange we use curve25519. Implementation is taken directly from Signal and this app is trusted by majority.

We

Ok. But why use AES and GOST? AFAIK they're both based on feistel networks? If one were to layer two symmetric encryption schemes today I'd think one would go with something like salsa[ed:chacha] and keccak (in authenticated encryption mode) -- and it would probably still be a bad idea, adding much more complexity than security?

[ed: Oh, and here I go, proving that non-cryptographer should be careful about what they say wrt encryption, apparently AES isn't a feistel cipher? http://crypto.stackexchange.com/questions/10605/why-is-aes-n... ]

> Also Instead of using N code bases (one for each platform) we reduce it's amount by conversing sources from java to other languages for every platform.

It's a pretty strong claim to say that you take three different encryption primitives, implemented by other people in java, and translate them to other languages -- and can also be sure there are no timing attacks? (Or oracles, or resulting errors)?

Surely it would be easier to stick to as few lines and layers as possible if you want it to be easy(er) to audit?

(So simple there's obviously no mistakes, vs so complex there's no obvious mistakes and all that).

I will let you know when we will complete audit of our crypto.

You're not helping your case. You make it sound like you are using bricks without knowing what their strength is.

It's a bit like saying you made a boat out of wood for buoyancy and filled it with sand in case the wood catches fire. Sure, a plank of wood doesn't sink, but too much sand can make it sink, and sand won't be of much help if there is a fire. A wooden boat is better than one filled with sand.

I'm not sure how the fact that the boat was made in Java is relevant, either. If anything, it makes it harder to prove that there is no timing attack, as the JIT could do unexpected things, long after the program has started.

Agreed. One OT nitpick: The fire-quenching properties of sand is actually somewhat different to that of water - eg in case of burning fuel/oil.

I haven't looked into actor much yet, but the last time I looked at Matrix, my main concern was how much implicit trust users needed to place in homeserver providers (messages and user profiles are stored in plaintext). Unless this has changed, I don't find it viable for any app that values user privacy.

Even federated networks eventually gravitate towards a large degree of centralization once the tech becomes mainstream (see email). If any servers are used at all in a privacy-minded app, they need to be zero-knowledge as far as I'm concerned, for actual user data at the very least, if not metadata as well (I realize the latter is an unsolved problem).

How does Actor handle user data and message storage?

Matrix signs all of its messages to avoid homeserver providers tampering with message history. Actual encryption however requires E2E encryption, which is in the wings via our "Olm" Axolotl implementation (http://matrix.org/git/olm). Progress can be tracked at https://matrix.org/jira/browse/SPEC-162. So I don't think you should reject Matrix on trust issues quite yet (although if you're really worried you should certainly wait for E2E to land).

Glad to see there's been progress on this front! The lack of E2E encryption is literally the last thing holding me back from building apps with Matrix. Can't wait to give it a try! =)

Axolotl has a well defined message structure using established crypto functions. All of them, for example, except Curve25519 are in Crypto++. You can probably fairly easily bake your own, albeit I'd use the olm from Matrix and just make theirs work well first.

But isn't the same true for Slack and its "open source competitors" mentioned in the Wired peace?

At least that's how I read Slack's security page (https://slack.com/security-practices) that only talks about "Data Encryption In-Transit" (i.e. server-to-client) and Mattermost's About page (https://about.mattermost.com/) that also talks (only) about encrypted "client-server data transmission".

I do agree that end-to-end encryption is important, but at least Matrix is aware of this and they are working on it (https://matrix.org/jira/browse/SPEC-162).

Not sure if any were mentioned in the piece, but there are plenty of zero knowledge E2E encrypted chat clients out there. None of the ones I'm aware of are also federated like Matrix is though, and I suspect the federated nature of Matrix probably makes E2E encryption a lot more complicated to implement than I can ever imagine.

I definitely appreciate that the Matrix team is aware of and actively working on E2E encryption, but it doesn't change my stance that Matrix is not a feasible building block for privacy-minded apps until that work is complete.

Agreed that E2E is mandatory for privacy. The federated nature of Matrix doesn't make it any harder to implement though - after all, TextSecure/Signal has basic federation too. The one subtlety we have is that we want to give the users the option of selecting between PFS and replayable epochs of history on a per-room basis - the latter making it easier to sync history between devices; the former being for the privacy paranoid.

Now, a more interesting privacy concern is that Matrix doesn't and can't protect metadata currently - see https://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20E... for details. So if you want both encrypted contents as well as obfuscated metadata, go check out Ricochet or Vuvuzela or Pond or something for now :)

Yes metadata is probably going to remain an unsolved problem for Matrix because it's not fully distributed, but I agree with the tradeoff Matrix is making here.

For now, building a great federated chat protocol that allows users to fully control their own data should take priority over just about everything else, because once users are in control of their own data, they're no longer locked to a single platform. So if another protocol comes along that does everything Matrix gets right and adds metadata protection, users can simply export their data and import it to the next great app/protocol (which is hopefully also federated). Until we have a great federated protocol that everybody is using, the friction associated with moving between chat apps/protocols is going to continuously inhibit real innovation in the messaging apps space by favoring apps that stand on the strength of their network effects over apps that stand on their own merits.

On the topic of fully distributed apps, I really like what replikativ is doing in this space:

https://github.com/replikativ/replikativ

It's a CRDT-based data replication library for building fully distributed applications. They envision replikativ being used as an open data exchange whereby users fully control their own data, and can specify any number of applications to have access to that data, instead of the status quo where user data is kept in closed, per-application silos. Their README has a much more comprehensive overview of the library and their vision.

Have you heard much about the Signal server federation? It's been more than a year since it was mentioned (that I've seen) by the Open Whisper Systems folks.

I'm hoping it's still on some sort of roadmap.

I'm not sure it's a huge priority there currently, but we don't have any internal knowledge. We asked to federate Signal with Matrix (which is a concrete possibility given we share the same E2E spec) and were politely turned down, as they'd prefer Signal to be a silo whose security they control rather than risking interop with 3rd parties. Hopefully they will change their mind in future once Matrix's E2E is more proven :)

We have two options - end-to-end (experimental) and only client-to-server encryption. We are looking at ZeroDB to make it end-to-end by default and searchable. We had e2e default encryption but people start to scream after missing their phones and losing all theirs messages :(

Also we had Tor-enabled client, but Tor is not suitable for mobile apps.

The possible integration with ZeroDB definitely sounds interesting! Really hoping that works out for you guys.

There's been some effort towards integration between SIP and XMPP:

https://tools.ietf.org/html/rfc7247

Yeah, I heard about it. It looks very promising, good luck.

It's not quite clear how actor.im federates. The "username" is my email, but how does my email map to the server I used to log in?

How do other servers know how to reach me?

Can you make an open source Telepathy backend so I can use my existing IM client to connect to your network?

http://telepathy.freedesktop.org/