aboutsummaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorChristophe Besson <cbesson@gmail.com>2026-09-07 21:04:36 +0200
committerChristophe Besson <cbesson@gmail.com>2026-09-07 21:04:36 +0200
commit7fa74d722108ca4338d14db4ecba53800df86fca (patch)
tree1629a7ab6bad02c9a5ae7576bdb588dcd43ea836 /docs
parente1383e1d545b994f4ad61694f868339defb0bdef (diff)
downloadmeshbay-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 'docs')
0 files changed, 0 insertions, 0 deletions