Merge pull request #186 from katzenpost/update_groupchat_with_vouchers

Update group chat spec with voucher system notes

Author: david415

content/en/docs/specs/group_chat.md

@@ -213,3 +213,61 @@ FUTURE WORK:
     However the core cryptography of the Reunion protocol was ported to golang, here: https://github.com/katzenpost/reunion/
 
 
+# New Proposal Voucher Design
+
+This is a new design proposed by Leif and Threebithacker:
+
+
+## Contact vouchers
+
+In order to join or initiate a conversation, participants need to exchange cryptographic key material.
+To address this problem we have a slightly unusual design: Contact vouchers.
+
+In many systems, invites to conversations flow from an existing member of the conversation to the user being invited.
+In our "Contact Voucher" protocol this flow is reversed:
+A member wishing to join a conversation hands a "Contact Voucher" (out of band) to the existing member, who then inducts the new member into the group.
+
+This design mitigates two potential problem with the former way of doing it:
+1. If the Contact Voucher is observed by a third-party, the third-party does not get to read neither participants' actual messages.
+   - **Passive** adversaries learn that the voucher was spent, but do not get to observe further interactions.
+   - **Active** adversaries can create a new fake group to induct the member into but does not learn anything about the existing group.
+     - In the future to prevent this one-way impersonation we could allow a "both parties bring something on paper to the meeting":
+       - Bob brings Contact Voucher
+       - Alice brings fingerprint for the VoucherReplyPublicKey (thwarts the active attacker)
+2. Only one thing needs to delivered out of band to achieve a 2-pass protocol (instead of a 3-pass protocol).
+  - Only one of the parties need to bring key material to a meeting in order to establish contact.
+
+```mermaid
+sequenceDiagram
+    actor Bob
+    participant VoucherSeq@{ "type" : "database" }
+    actor Alice
+    Bob-->>+Bob: Generates VoucherKeypair. <br>Generates BACAP write/read cap.<br>VoucherPayload := read cap || VoucherPublicKey<br>Voucher := Hash(VoucherPayload)
+    Bob->>+VoucherSeq: Publish: VoucherPayload
+    Bob-->>Alice: [Sent OOB] Voucher
+
+
+    Alice-->>+Alice: Derive VoucherSeq read/write caps from Voucher.<br>Read the first box in VoucherSeq
+    VoucherSeq->>+Alice: VoucherPayload
+ 
+    Alice-->>+Alice: VoucherReply := Encrypt(WhoReply + VoucherSalt)<br> to VoucherPublicKey<br><br>Derive Bob's ReadCap from<br>VoucherPayload + VoucherSalt
+    par_over All-Or-Nothing using COPY service
+    Alice->>+VoucherSeq: VoucherReply
+    Alice->>+Alice's Group: WhoReply<br>(incl. Bob's new ReadCap)
+    Alice->>+VoucherSeq: Tombstone VoucherPayload<br>to prevent Voucher reuse
+    end
+
+    Bob-->>+Bob: Poll the second VoucherSeq box until Alice replies
+    VoucherSeq->>+Bob: VoucherReply
+```
+
+## Self-authenticating BACAP payload
+The first message sent (The VoucherPayload) is authenticated in the following manner:
+- The VoucherPayload is computed (first).
+- A cryptographic hash of the VoucherPayload is computed. This hash **is** the *Voucher**.
+- The **Voucher** is then used to derive a BACAP read/write capability set.
+- The VoucherPayload is uploaded to the sequence described by the capability (at index 0).
+- Anyone who intercepts the **Voucher** can read **and** write the sequence.
+- But: Since the **Voucher** is a hash over the VoucherPayload, writing the sequence with anything but the VoucherPayload will be detectable by the recipient.
+- This means that the contents *cannot* be undetectably be modified by the interceptor.
+

hugo.yaml

@@ -71,6 +71,14 @@ outputs:
   section: [HTML, print, RSS]
 
 params:
+
+  mermaid:
+    theme: dark
+    themeVariables:
+      textColor: "#ffffff"
+      primaryTextColor: "#ffffff"
+      secondaryTextColor: "#ffffff"
+
   taxonomy:
     # set taxonomyCloud = [] to hide taxonomy clouds
     taxonomyCloud: [tags, categories]