4 ms·

We are actually trying to make open protocol in https://actor.im https://actor.im with federation with https://matrix.org https://matrix.org. It seems that only

by ex3ndr 11y ago

We are actually trying to make open protocol in https://actor.im https://actor.im with federation with https://matrix.org https://matrix.org. It seems that only Actor and Matrix understand importance of federation.

scrollaway 11y ago
Yeah, I heard about it. It looks very promising, good luck.
lewisl9029 11y ago
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?
- ex3ndr 11y ago
  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.
  - lewisl9029 11y ago
    The possible integration with ZeroDB definitely sounds interesting! Really hoping that works out for you guys.
- Arathorn 11y ago
  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 http://matrix.org/git/olm). Progress can be tracked at https://matrix.org/jira/browse/SPEC-162 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).
  - lewisl9029 11y ago
    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! =)
    - zanny 11y ago
      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.
- ar0 11y ago
  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 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/ 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 https://matrix.org/jira/browse/SPEC-162).
  - lewisl9029 11y ago
    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.
    - Arathorn 11y ago
      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%20Entropique.pdf 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 :)
      - lewisl9029 11y ago
dorfsmay 11y ago
There's been some effort towards integration between SIP and XMPP: https://tools.ietf.org/html/rfc7247 https://tools.ietf.org/html/rfc7247
e12e 11y ago
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 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 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?
- ex3ndr 11y ago
  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
  - e12e 11y ago
chei0aiV 11y ago
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/ http://telepathy.freedesktop.org/
hobarrera 11y ago
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?

by ex3ndr 11y ago

scrollaway 11y ago

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

lewisl9029 11y ago

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?

ex3ndr 11y ago
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.
- lewisl9029 11y ago
  The possible integration with ZeroDB definitely sounds interesting! Really hoping that works out for you guys.
Arathorn 11y ago
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 http://matrix.org/git/olm). Progress can be tracked at https://matrix.org/jira/browse/SPEC-162 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).
- lewisl9029 11y ago
  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! =)
  - zanny 11y ago
    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.
ar0 11y ago
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 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/ 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 https://matrix.org/jira/browse/SPEC-162).
- lewisl9029 11y ago
  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.
  - Arathorn 11y ago
    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%20Entropique.pdf 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 :)
    - lewisl9029 11y ago

dorfsmay 11y ago

There's been some effort towards integration between SIP and XMPP: https://tools.ietf.org/html/rfc7247 https://tools.ietf.org/html/rfc7247

e12e 11y ago

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

ex3ndr 11y ago
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
- e12e 11y ago

chei0aiV 11y ago

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/ http://telepathy.freedesktop.org/

hobarrera 11y ago

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?