[RFC] New Model for Post Key Transfer

[neruthes]

Background

• UserGroup Membership Abstraction Model

Basic Procedure

CRS (Chatroom Seed)

Chatroom is a basically implementable feature in GUN, or any other P2P communication infrastructure.

Since initialization, for each UserGroup, Alice will generate CRS from KDF(UserGroupId, R1, "0bf75036-6eff-40b2-9149-46daad0cfbf5") where R1 is a high-entropy random number which should be persistent and synchronized across devices.

CRS is deterministic and persistent. CRS should be synchronized across devices.

If the recipient is considered using Maskbook, CRS is attached with the UserGroup Membership Certificate, but is not included in the certificate.

CRK (Chatroom Key)

Alice will generate a new CRK every week to prevent deleted members from obtaining latest information.

CRK is generated from KDF(CRS, R1, date_YYYYMMDD, "fe656862-95ea-4ff8-8fad-0b974f95d3f9").

For concrete UserGroups, multiple CRKs may be active simultaneously, because multiple administrators of the UserGroup may have their respective CRKs.

The date, which is put into KDF to generate CRK, is always the most recently occurred Monday; if today is Monday, use today. Alice will send a new declaration to the chatroom. The declaration is a JSON object key-value structure; a recipient is identified by the last 3 bits (toString(2)) of the SHA256 of his username, and the content is ECDH_encrypt(new_CRK, TmpKeypair.pri, Bob.pub).

Sharing Post Key

When Alice creates a new post to UserGroup UG, she will send AES.encrypt(P.key, CRK[UG]) to the chatroom CRS[UG].

On-Demand Requesting

If Bob needs a post key which was shared with a CRK which Bob didn't receive in the chatroom CRS, and the post does belong to the UserGroup, Bob may demand the post key in another chatroom SHA512(CRS + "e80a49d0-20ad-45a4-b2c7-bab236187c22") (we call it TCR, in short for Temporal Chat Room), where messages expire fast. This part will need support for message life cycle management in P2P communication infrastructure.

[neruthes]

Critic 001

Reusing CRK in a one-week period for multiple PK makes one-post-one-key strategy less significant. This looks a bit 掩耳盗铃.

[Jack-Works]

If you want to change the share target between posts, one-post-one-key strategy is useful.

[neruthes]

Reliability may be in dire crisis in this model. Will need evaluation from @yisiliu.

Fallback prepared.

[neruthes]

If I recall correctly, the discussions on yesterday concluded that implementing this model is a good idea.

Soon @yisiliu will write his own comment here.

[yisiliu]

We will implement this as an option to optimize the user experience but we will always offer users the right to turn it off.