It was announced in a lightning talk following that session
2,245 karma · joined October 17, 2012
Website: https://mrosenberg.pub Github: https://github.com/rozbb Keybase: https://keybase.io/mrosenberg Email: michael (@) mrosenberg (.) pub
[ my public key: https://keybase.io/mrosenberg; my proof: https://keybase.io/mrosenberg/sigs/dR6U3ijr9MYZyBe0ueW6L90pU8Adb817jaeWietnOH4 ]
WT.Social was previously WikiTribune, founded in Aug 2017 by a cofounder of Wikipedia. WikiTribune was a "news wiki where volunteers wrote and curated articles about widely publicised news by proofreading, fact-checking, suggesting possible changes, and adding sources from other, usually long established outlets...Until October 2018, WikiTribune employed journalists with established backgrounds in the profession who researched, syndicated, and reported news...After that volunteers could publish articles without having them checked by professionals."
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.
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.
A question: if someone leaves the group, how do you determine the new group key?
If there is some one-way function f that determines the new group key, then the removed person can derive the new key K' = f(K), where K is the current key. That means that if they get ahold of the transcript of the group after they leave, they can decrypt everything.
So K' must be derived by some non-deterministic process. There's a group of people who need to arrive at the same value, and they need to use randomness. Whose randomness do they use? A simple answer is "the remover." That is, have the remover include a randomly generated K' in their Remove message to the rest of the group. This doesn't work though, because the removed person can still decrypt the Remove message and get K' just like everyone else.
A viable solution is to randomly generate K' and then encrypt it for everyone _except_ the removed party. But once you're here, you run into the problem of pairwise keys, and your runtime sucks.
This last step is basically where the article starts. Thank you for asking this question!
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?
One thing that I left out of the post is that the MLS ratchet tree has something called a "tree hash". Every node carries a hash digest, which is the hash of its two children. The root node's hash is used to derive a bunch of group-specific values, so it's important to keep this hash up to date. If you promote every member to their parent, this would require about N log(N) total hash operations, since every path from a leaf to the root would have to have its hashes recalculated.
N log(N) hashes seems like a small price to pay for optimizing a structure that determines how many ECDH operations you end up doing. I'll ask other MLS people about this and see if I'm missing something.
1. Is D a binary random variable? If so, what exactly does it mean to say beta*D + beta_0 is an approximation for log odds? Doesn't this formula only take on 2 possible values?
2. Could you provide intuition for why a linear function of D would be a good approximation for the log odds mentioned?