5 ms·

Author here. Happy to answer questions!

daurnimator 7y ago
I've been working on a new scheme for decentralised encrypted (group) messaging bus over at https://ȱ.com/ https://xn--nma.com/ unlike many other schemes, forward secrecy is not a goal: When I invite a friend to a group chat, I want them to be able to obtain historical conversation messages. For your normal end user (at least what I think of as common: see how facebook messenger works, as well as slack, discord and even how many irc chat rooms have public logs), how is this MLS scheme useful?
- daurnimator 7y ago
  Interesting, I actually wrote 'ȱ.com', hacker news seems to expand to punycode.
- ptman 7y ago
  Are you aware of matrix? Their olm encryption scheme is capable of PFS, but it's not used exactly in order to provide history.
  - daurnimator 7y ago
    Yes I'm aware of matrix. A couple of things that I don't like about the matrix protocol are: 1. identity is tied to a server and users are not free to move between servers. 2. servers are assumed to be always online and have low latency.
    - roblabla 7y ago
      1. There is work to fix the identity problem with Identity Servers. See https://matrix.org/faq/#what-is-an-identity-server%3F https://matrix.org/faq/#what-is-an-identity-server%3F 2. I'm not sure what gives this impression? I have a server that is very much on flaky network, and it federates just fine. The point is that servers can go online/offline without breaking anything on the whole network.
    - ptman 7y ago
      There is a proposal for decentralized user accounts: https://github.com/matrix-org/matrix-doc/issues/915 https://github.com/matrix-org/matrix-doc/issues/915
  - namibj 7y ago
    There's also megaolm. Megaolm seems to be scaling better than other production setups, in practice.
- doomrobo 7y ago
  If you don't need PFS you could probably modify MLS to be a bit simpler. Firstly, no need for sender keys. A single group key will do. When you remove someone from the group, you still do the group update and derive a new group key (unless you don't want post-compromise security either, in which case you can throw out the entire tree concept). Now when you add someone to the group, you share with them the entire historical group transcript along with all the previous group keys. Is this roughly what you're looking for?
thinkloop 7y ago
Really nice article. In solution #2, when an encrypted message is received, does the receiver have to lookup the sender's specific key from a list that they maintain? In other words, does every member have a list of every other member's special group keys?
- doomrobo 7y ago
  Yup, everyone has everyone else's sender key. This is more or less equivalent to having a single shared group key, but there are some practical reasons why it's split out. I think one of them is that it makes symmetric key ratcheting (for the purposes of perfect forward secrecy) a little less disastrous in the case of out-of-order or failed message delivery. Not totally sure, though.
caf 7y ago
In terms of the open issue at the end, it seems like the 'obvious' solution is for (in the Zane #11 removal example) Zane #12 to then respond by promoting himself up one level in the tree and then generating new secrets for his own node and all ancestors. In this way you actively cull the blank nodes so you can't end up in the pathological situation. Presumably this isn't done because the additional messages required to do this defeat the gains?
- doomrobo 7y ago
  I don't know exactly why this isn't done. Someone else mentioned this, this was my response https://news.ycombinator.com/item?id=20645457 https://news.ycombinator.com/item?id=20645457 I don't think anyone has to update their keypairs if they get promoted. They would only get promoted if their sibling is blank. In that case, they can just take their parent's keypair and not worry about anyone else having it.
  - caf 7y ago
    The deleted sibling still knows the parent, and all ancestors, so you have to regenerate them to make the deletion actually effective.
Rhinobird 7y ago
Can any of this be beaten into a way to verify group membership? Say you want to prove you are a member of the AMA or IEEE, or Bar? Could you set up a large group for the association and their communications, and then when asked provide verifiable credentials that you are a member? Like a group membership signature?
- namibj 7y ago
  Have the group sign a pubkey of yours. Use said pubkey. Add revocation lists.
l4bytt 7y ago
So, i don't really undestand why on [0] the right node of level two has a key but on [1] it doesn't. [0]: https://trailofbits.files.wordpress.com/2019/08/post_remove_tree.png https://trailofbits.files.wordpress.com/2019/08/post_remove_... [1]: https://trailofbits.files.wordpress.com/2019/08/image1-1.png https://trailofbits.files.wordpress.com/2019/08/image1-1.png

I've been working on a new scheme for decentralised encrypted (group) messaging bus over at https://ȱ.com/ https://xn--nma.com/ unlike many other schemes, forward secrecy is not a goal: When I invite a friend to a group chat, I want them to be able to obtain historical conversation messages. For your normal end user (at least what I think of as common: see how facebook messenger works, as well as slack, discord and even how many irc chat rooms have public logs), how is this MLS scheme useful?

daurnimator 7y ago
Interesting, I actually wrote 'ȱ.com', hacker news seems to expand to punycode.
ptman 7y ago
Are you aware of matrix? Their olm encryption scheme is capable of PFS, but it's not used exactly in order to provide history.
- daurnimator 7y ago
  Yes I'm aware of matrix. A couple of things that I don't like about the matrix protocol are: 1. identity is tied to a server and users are not free to move between servers. 2. servers are assumed to be always online and have low latency.
  - roblabla 7y ago
    1. There is work to fix the identity problem with Identity Servers. See https://matrix.org/faq/#what-is-an-identity-server%3F https://matrix.org/faq/#what-is-an-identity-server%3F 2. I'm not sure what gives this impression? I have a server that is very much on flaky network, and it federates just fine. The point is that servers can go online/offline without breaking anything on the whole network.
  - ptman 7y ago
    There is a proposal for decentralized user accounts: https://github.com/matrix-org/matrix-doc/issues/915 https://github.com/matrix-org/matrix-doc/issues/915
- namibj 7y ago
  There's also megaolm. Megaolm seems to be scaling better than other production setups, in practice.
doomrobo 7y ago
If you don't need PFS you could probably modify MLS to be a bit simpler. Firstly, no need for sender keys. A single group key will do. When you remove someone from the group, you still do the group update and derive a new group key (unless you don't want post-compromise security either, in which case you can throw out the entire tree concept). Now when you add someone to the group, you share with them the entire historical group transcript along with all the previous group keys. Is this roughly what you're looking for?

thinkloop 7y ago

Really nice article. In solution #2, when an encrypted message is received, does the receiver have to lookup the sender's specific key from a list that they maintain? In other words, does every member have a list of every other member's special group keys?

doomrobo 7y ago
Yup, everyone has everyone else's sender key. This is more or less equivalent to having a single shared group key, but there are some practical reasons why it's split out. I think one of them is that it makes symmetric key ratcheting (for the purposes of perfect forward secrecy) a little less disastrous in the case of out-of-order or failed message delivery. Not totally sure, though.

caf 7y ago

In terms of the open issue at the end, it seems like the 'obvious' solution is for (in the Zane #11 removal example) Zane #12 to then respond by promoting himself up one level in the tree and then generating new secrets for his own node and all ancestors. In this way you actively cull the blank nodes so you can't end up in the pathological situation. Presumably this isn't done because the additional messages required to do this defeat the gains?

doomrobo 7y ago
I don't know exactly why this isn't done. Someone else mentioned this, this was my response https://news.ycombinator.com/item?id=20645457 https://news.ycombinator.com/item?id=20645457 I don't think anyone has to update their keypairs if they get promoted. They would only get promoted if their sibling is blank. In that case, they can just take their parent's keypair and not worry about anyone else having it.
- caf 7y ago
  The deleted sibling still knows the parent, and all ancestors, so you have to regenerate them to make the deletion actually effective.

Rhinobird 7y ago

Can any of this be beaten into a way to verify group membership? Say you want to prove you are a member of the AMA or IEEE, or Bar? Could you set up a large group for the association and their communications, and then when asked provide verifiable credentials that you are a member? Like a group membership signature?

namibj 7y ago
Have the group sign a pubkey of yours. Use said pubkey. Add revocation lists.

l4bytt 7y ago

So, i don't really undestand why on [0] the right node of level two has a key but on [1] it doesn't. [0]: https://trailofbits.files.wordpress.com/2019/08/post_remove_tree.png https://trailofbits.files.wordpress.com/2019/08/post_remove_... [1]: https://trailofbits.files.wordpress.com/2019/08/image1-1.png https://trailofbits.files.wordpress.com/2019/08/image1-1.png