# private groups | 2020-06-18

https://github.com/ssbc/private-group-spec/blob/master/vectors/unbox2.json
- keks: drop the initial unboxed message
- mix: :+1:

## Direct Message

https://github.com/ssbc/private-group-spec/pull/8/files
- keks: in my PR I tfk encode the dh_keys for the DM-key derivation
- mix: but it's a DH key, we don't have a tfk encode for that
- keks: tfk needs DH key type!
- mix: ok!
- so in : https://github.com/ssbc/envelope-spec/blob/master/encoding/tfk.json + md
- type code: 3 (DH)
- format code: 0 (curve25519)
- mix TODO:
- change the DM derivation to use tfk
- make new test vectors

- mix: is it safe to make a shared DM key with yourself
- use-case : if I lose all my stuff, how do I get back into the group?
- keks: aiming for forward security, ideally you couldn't get back in?
- other solutions: what if there's a private group for just you (like Signal note-to-self?)
- could add other devices of yours to this group, so you can get back in

- mix: you could always export your keystore
- keks: yes and it should be encrypted, dark-crystal?

## Envelope spec

https://github.com/ssbc/envelope-spec/tree/master/derive_secret/README.md

TODO: change (for clarity)

function Derive (key, feed_id, prev_msg_id, labels, length) {
  var info = ['envelope', feed_id, prev_msg_id].concat(labels)

  return HKDF.Expand(key, encode(info), length)
}

## Private Group Spec

1. we disallow you from making a shared DM key with yourself
- keks: I think using a "square dh", is fine. it's slightly weaker, but all our models give the adversary so much more power than is realistic here
- mix: but what about fwd security, you could bar now to have easier time later?
- keks: good point
- mix: propose we put this hard rule in place, and see how it is. later we can relax this is needed
- mix: 👍
- keks: 👍

2. there are max 16s slot on a message
- mix: 👍
- keks: 👍

3. if there is a group key
a) there is only 1 group key per
- mix: 👍
- keks:👍
b) the group key is in the first slot
- mix: 👍
- keks:👍👍👍

TODO - make sure these changes are in the spec

## Timeline

keks: Go side of things we've got the envelope code back up to date.
we're gonna meet again for more private groups

mix: lets look at the vectors and see what needs doing:
- envelope-spec
- box1 yes
- box2 - mix: libsodium didn't let me encrypt an empty buffer.
- keks: TODO look at it
- box3 - mix: this blocks against a person not making a unique msgKey
- keks: yeah I see what you mean but not particularly useful IMO
- mix: ok, I'll remove TODO
- cloaked_id1 yes
- derive_secret1 yes
- keks: we should mention those are TFK encrypted
- mix: TODO change this by saying what's TFK to description
- slot1 yeso
- mix: TODO change this by saying what's TFK to description

- unslot1 yeso
- mix: TODO change type to slot

- private-group-spec
- unbox1 yes
- unbox2 TODO drop the plaintext msg
- direct-message-key TODO change because of change of spec with TFK encoding
- groupid1 yes

## TIMELINE

- mix updates READMEs, vectors
- send to keks / cryptix
- keks / cryptix pass the "core" vectors
- we make the READMEs more detailed
- version 1.0.0 of specs is locked in
- envelope-spec
- private-group-spec
- we make the READMEs more accessible

we both agree the docs are a bit messy
- maybe it would be good to think about who's gonna be using it?

we talked about cooking
- does nz have smoked tofu TODO