summaryrefslogtreecommitdiffstats
path: root/packages/meshbay-common/src/meshbay_common/chatbox.py
diff options
context:
space:
mode:
Diffstat (limited to 'packages/meshbay-common/src/meshbay_common/chatbox.py')
-rw-r--r--packages/meshbay-common/src/meshbay_common/chatbox.py19
1 files changed, 9 insertions, 10 deletions
diff --git a/packages/meshbay-common/src/meshbay_common/chatbox.py b/packages/meshbay-common/src/meshbay_common/chatbox.py
index f3cfc76..740e829 100644
--- a/packages/meshbay-common/src/meshbay_common/chatbox.py
+++ b/packages/meshbay-common/src/meshbay_common/chatbox.py
@@ -4,13 +4,13 @@ Chat message encryption and sender authentication.
Design A of `docs/chat-sender-keys.md`, decided 2026-09-07. What it is, and what
it deliberately is not, in the order the decisions were made:
-**Not a ratchet.** `senderkeys.py` implements Signal-style sender keys and is
-unused by production. With sender keys distributed under the group key and a
-node that serves history to devices which were not present, the node must retain
-and hand out each chain's *earliest* key — and a chain key at iteration *i*
-yields every message key from *i* onward by pure HKDF. Forward secrecy is then
-zero, and the ratchet is computing HKDF over a value every member already holds.
-The property is given up on the record rather than inherited by accident.
+**Not a ratchet, and not sender keys.** With per-sender chains distributed under
+the group key, and a node that serves history to devices which were not present,
+the node must retain and hand out each chain's *earliest* key — and a chain key
+at iteration *i* yields every message key from *i* onward by pure HKDF. Forward
+secrecy is then zero, and the ratchet is computing HKDF over a value every
+member already holds. The property is given up on the record rather than
+inherited by accident.
**A key per group, per epoch, per device.** The node generates an epoch key and
delivers it to members wrapped under the current group key. Each device derives
@@ -18,9 +18,8 @@ its *own* subkey from it, by name, so:
* two *keys* never share a subkey, and — the part that actually matters —
**there is no mutable sending state at all**, so nothing can be advanced
- twice. §15.0b wanted per-device chains because two devices advancing one
- chain produce key and nonce reuse (C1, one level down, and exactly what
- `GroupSenderKeyStore` got wrong). Derivation plus a *random* nonce removes
+ twice. Two devices advancing one chain produce key and nonce reuse, which is
+ the failure this design cannot have; derivation plus a *random* nonce removes
the hazard rather than partitioning it;
Be precise about what that does **not** say, because the obvious stronger