---
# System prepended metadata

title: private groups | 2020-06-18

---

# 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


