We are actually trying to make open protocol in https://actor.im with federation with https://matrix.org. It seems that only Actor and Matrix understand importance of federation.
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?
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
[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).
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.
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?
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).
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.
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 :)
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.
I'm hoping it's still on some sort of roadmap.
Also we had Tor-enabled client, but Tor is not suitable for mobile apps.
How do other servers know how to reach me?