private groups | 2020-06-18

https://github.com/ssbc/private-group-spec/blob/master/vectors/unbox2.json

• keks: drop the initial unboxed message
  • mix:

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