mayatnikovandClaude Fable 5
ae55c846aa
Закрыты все открытые вопросы проектирования. Пароль не покидает клиент (два ключа из мастера), TOFU для публичных ключей, устройства и конверт, атомарный rekey комнат, регистрация и контакты, схема SQLite и драйвер без cgo, сессии и CSRF, деплой через nginx+systemd, правила пушей, айдентика «Скобы» на системном mono. Иконки PWA в web/icons. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015DbCjVfTFq4ZFG8juD45YJ
5.1 KiB
5.1 KiB
ADR-018: Комнаты — владелец, состав и атомарный rekey
Контекст
ADR-007 задаёт принцип: симметричный ключ комнаты, раздача на публичные ключи, rekey при смене состава. Не определено: кто меняет состав, как ключ попадает на новое устройство участника, что происходит при гонке двух rekey и при выходе участника.
Решение
- Комнату создаёт любой пользователь и становится её владельцем. Владелец добавляет и удаляет участников по нику, может удалить комнату. Любой участник может выйти. Приглашений по ссылке нет. Имя комнаты — до 64 символов, открытый текст на сервере: это метаданные.
- Ключ комнаты — 32 случайных байта с идентификатором
keyId(16 случайных байт, base64url). Идентификатор случайный, а не порядковый: гонка двух одновременных rekey даёт два разных ключа, оба доходят до всех, конфликта номеров нет. Текущий ключ — последний полученный в порядке сервера; сообщения несутkeyId, клиент держит все ключи комнаты и расшифровывает любым известным. - Ключ участнику заворачивается на ECDH между распространителем и участником:
HKDF(ECDH(priv_D, pub_M), info="bare-roomkey-v1|roomId|keyId") → AES-GCM. Распространитель заворачивает ключ и себе — для собственных других устройств. - Завёрнутые ключи сервер хранит постоянно, не в транзитной очереди: таблица
room_keys, по одной записи на участника и ключ, последние два ключа комнаты. Новое устройство участника получает текущий ключ вместе со списком комнат. Это уточняет ADR-008: к «метаданным комнат» относятся и завёрнутые ключи — шифротекст, серверу бесполезный. - Смена состава и rekey — один запрос
POST /api/rooms/{id}/members {add, remove, keyId, keys}. Клиент-владелец сначала получает публичные ключи итогового состава (с проверкой TOFU, ADR-016), генерирует ключ, заворачивает каждому, затем отправляет. Сервер проверяет, что множествоkeys[].toравно итоговому составу, и применяет всё в одной транзакции. Состав без ключа или ключ без состава невозможны. - Выход участника: сервер удаляет его из состава и его ключи, шлёт остальным событие
roomсneedsRekey: true. Клиент владельца, получив его, выполняет rekey тем же запросом с пустымиadd/remove. Пока владелец офлайн, комната живёт на старом ключе — вышедший его и так знает; новых сообщений сервер ему не доставляет. - Выход владельца передаёт владение участнику с самым ранним
joined_at. Выход последнего участника удаляет комнату.
Следствия
- Серверу ключи недоступны по-прежнему: он хранит и раздаёт только шифротекст.
- Владелец — единственная роль. Администраторов, модераторов и прав на уровне сообщений нет.
- Новый участник не читает прошлое: его не существует на сервере. Сообщение, отправленное на старом ключе одновременно с rekey, новое устройство прочитать не сможет — показывается как нерасшифрованное. Редкий и честный случай.
- Если член комнаты сговорился с сервером, он может остаться читателем после выхода до rekey. В модели угроз сервер и участник по отдельности не защищаемые стороны; их сговор — тем более.