is group_id ".cloaked" generic?

[dominictarr]

earlier on a call, we talked about making a generic way to refer to a encrypted message, that didn't reveal which message it was about, to someone who couldn't decrypt that message.

@mixmix said that .cloaked does that, but in the readme it refers to a group_key but of course, that wouldn't be generic -- unless, the group_key is just the body_key for the initial message.

in the document describing creating a group, it's not actually specific enough to say how to encrypt it. https://github.com/ssbc/private-groups-spec/tree/master/group/init

to make cloaked references properly generic, it ought to just create the message, then take the body_key from that message (important: which gives access to the content but not the header) then you have a generic cloaked reference.

[cryptix]

in the readme

They are all readme‘s in this repo... 😅 just to be clear, are you referring to the group id spec?

[mixmix]

Can you explain what you mean by :

but of course, that wouldn't be generic

What would be helpful is if you write pseudocode for what you mean. I don't have enough understanding of what the problem is / what your proposal is to be able to know what I would code, or what risk we're mitigating?

e.g.

var info = ["ssb-derive-cloaked-msg-id", init_msg_id]
var group_id = HKDF.Expand(init_msg_body_key, encode(info), 32)

---

happy to add code showing how initial message is boxed. That seems like a different issue

[mixmix]

We discussed this on call, decided to define how "cloaked_id"s more generally in the envelope-spec (derived from msg_id + read_key), then define group_id as a particular case of this in this spec.

however because we decided to lock TFK codes into the envelope-spec (so that it can potentially be used to interoperate across platforms) ... then this above definition is kinda unclear:

• (A) which sort of messages are we writing this spec for?
  • type 1, format 0 (ssb/classic message) ?
  • type 1, format 1 (ssb/gabby message) ?
  • both?
• (B) what is the TFK output of this cloaked message id?
  • type 1, format 2 (ssb/cloaked message) ... is what we've presumed
  • what if there's a type 1, format 12 (cabal message say) ... we shouldn't map that to ssb/cloaked

I think this means that the idea of putting this "cloaked-id spec" in envelope-spec is ok **but only if we say it's just for "ssb/classic messages"

[mixmix]

@keks said :

My hunch is that you wouldn't use cloaked messages in the tfk, instead you first look up the real message id and use that. Not 100% sure though, and won't be able to wrap my head around this tonight

[keks]

@mixmix I stand by what I said: In envelope, we shouldn't use cloaked IDs, but the real IDs. We introduced the cloaking to address the information leaked by it, but we just hash it in, so you can't see it from the outside anyway. Using them here does not help.

That said, I think it makes sense to add a cloaked entry to the list of message types, if we want to use it elsewhere.

[mixmix]

I've removed cloaked from the TFK list of official message types until we start to use them elsewhere

[mixmix]

I think this is resolved ...

[keks]

I agree.

This issue was opened when the group id computation was still in this repo: https://github.com/ssbc/private-group-spec/blob/f1df57b848616afdb5281d15e71a874033e6488a/group/group-id/README.md#group-id

Now it's moved into the envelope repo and was made more generic by deriving the id from the read key: https://github.com/ssbc/envelope-spec/tree/5ee71e869b1b1297461cf4b43be83a574d7a624a/cloaked_msg_id

(for future reference)