diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-09-07 21:04:36 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-09-07 21:04:36 +0200 |
| commit | 7fa74d722108ca4338d14db4ecba53800df86fca (patch) | |
| tree | 1629a7ab6bad02c9a5ae7576bdb588dcd43ea836 /packages/meshbay-hub | |
| parent | e1383e1d545b994f4ad61694f868339defb0bdef (diff) | |
| download | meshbay-7fa74d722108ca4338d14db4ecba53800df86fca.tar.gz | |
docs(chat): correct the claim that two devices never share a key
`chatbox.py` said per-device subkey derivation means "two devices never share
an AES key". That is false in the deployment that exists, and stating it hid
the reason the design is actually safe.
Two clients of one account on one node normally hold the **same** identity key:
a second browser fetches the keypair bundle from the node and recovers the
existing key rather than minting a new one, and so does a fresh Electron
install. Device linking — a distinct key, countersigned — is the exception, not
the rule, which is why nobody is ever asked to pin anything when they open a
second browser. So two clients routinely share a device key and therefore its
chat subkey.
What makes that safe is the nonce, not the derivation: 96 random bits, never a
counter. Two independent senders under one key collide only on the birthday
bound, unreachable at chat volume; two independent senders advancing one
*counter* collide immediately, which is precisely what C1 and §15.0b are about.
The true property is "no mutable sending state at all" — the hazard removed
rather than partitioned — and the design therefore degrades correctly into the
deployment as it is, where a chain-based one would have failed silently on the
day someone opened a second tab.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TZZxYjz8YeWRz13xDi8LJr
Diffstat (limited to 'packages/meshbay-hub')
0 files changed, 0 insertions, 0 deletions