Как обмениваться секретами через публичную координацию

Криптографическая задача здесь звучит проще, чем её практическое решение: нескольким участникам нужно координировать работу через сервер и журналы, которые могут быть публично наблюдаемыми или когда-нибудь скомпрометированными, но сами секреты не должны оказаться в этом слое. При этом мало просто «что-нибудь зашифровать». Нужно правильно определить получателя, подтвердить отправителя, остановить повторы старых сообщений, менять и отзывать ключи, безопасно делать резервные копии и не выдать всё через логи или временный файл.

Полная методология, модель угроз и вопросы для внешнего аудита собраны в Wiki: «Синаполис/Прикладной криптографический дизайн обмена секретами», актуальная основа этого обзора — ревизия 2240. Ниже — короткая карта идей, а не замена техническому документу.

Две зоны с разными обязанностями

Архитектура разделяет публичный координационный слой и приватный частный сервер — подконтрольную владельцу зону, где допустимо читать секреты и выполнять операции над ними. Публичный слой переносит задания, ссылки, шифротексты и минимальные квитанции. Он не считается доверенным хранилищем открытого текста. Приватная зона разрешает ссылки, расшифровывает сообщения и старается возвращать только заранее ограниченный результат.

Это не означает, что приватный сервер «неуязвим». Если злоумышленник получил root-доступ, читает память процесса или подменил код до расшифрования, одна криптографическая оболочка проблему не решит. Разделение лишь уменьшает поверхность: компрометация публичной координации не должна автоматически раскрывать содержимое.

Режим 1: reference, not content

Первый режим буквально следует правилу «ссылка, а не содержимое». В публичное задание помещается непрозрачный идентификатор объекта, допустимый контрольный атрибут и строго описанная операция. Приватный сервер разрешает ссылку внутри своей границы, выполняет вычисление и возвращает, например, логический результат или ограниченную квитанцию — но не исходный секрет.

Это особенно полезно, когда секрет вообще не нужно кому-либо пересылать. Однако ссылка не должна раскрывать приватный путь, а публичный хеш слабого, угадываемого секрета может стать подсказкой для перебора. Нельзя также передавать секрет через аргументы командной строки, историю shell, URL, отладочные исключения или временные файлы. Даже безопасная на вид функция должна иметь лимиты, иначе серию запросов можно превратить в побитовый канал утечки.

Режим 2: sealed ciphertext через публичную шину

Когда содержимое всё же нужно доставить другому участнику, отправитель шифрует его на публичный ключ получателя, а публичная шина переносит только sealed ciphertext и несекретные метаданные. В испытанном прототипе использовался SealedBox из PyNaCl/libsodium.

SealedBox создаёт новую эфемерную пару отправителя для каждого сообщения. Получатель с соответствующим приватным X25519-ключом может открыть шифротекст; изменение защищённого содержимого обнаруживается при расшифровании. Но здесь есть принципиальная граница: SealedBox не подтверждает личность отправителя. Любой, кто знает публичный ключ получателя, способен создать для него новый корректный sealed box.

Поэтому production-оболочка должна отдельно подписываться Ed25519-ключом отправителя. Подпись связывает шифротекст с идентификаторами отправителя и получателя, версиями ключей, назначением, временем создания и истечения, типом содержимого и доменным контекстом. Получатель сначала проверяет строгую структуру, адресата, срок, реестр ключей и подпись, затем защищается от повторного message_id, и только после этого расшифровывает и использует данные. Каноническая сериализация подписываемой оболочки — отдельная инженерная проблема: «подписать JSON» недостаточно, если две реализации по-разному понимают порядок полей, Unicode или дубликаты ключей.

Почему нужен отдельный ключ шифрования

Прототипный тест показал техническую совместимость официального преобразования Ed25519-материала в X25519. Но из этого не следует, что долговременный Stellar seed для подписи транзакций нужно штатно загружать в сервис расшифрования.

Такое повторное использование соединяет два разных контура. Одна утечка начинает угрожать и истории зашифрованных сообщений, и полномочиям подписи; ротация encryption key затрагивает финансовую идентичность; decryptor получает доступ к материалу с гораздо большим радиусом поражения. Нормальная конструкция использует отдельную X25519-пару, созданную именно для шифрования. Её публичный ключ связывается с идентичностью подписанной записью реестра с назначением, версией, сроком действия и отзывом. Приватный ключ не хранится на публичном сервере.

Восстановление backup: две разные тройки из пяти

Фраза «3-of-5 recovery» скрывает два независимых действия.

Первое — мультиподписная авторизация: три из пяти независимых ответственных лиц подтверждают, что разрешено восстановить конкретную резервную копию в конкретную целевую среду и в ограниченный срок. Их подписи дают подотчётное согласие, но ничего не расшифровывают.

Второе — пороговая реконструкция ключа: участие трёх из пяти держателей долей позволяет получить или развернуть ключ расшифрования. Это даёт техническую возможность, но само по себе не разрешает восстановление.

Production-церемония обычно должна требовать оба слоя. Сначала проверяются три аутентифицированных одобрения, привязанные к hash резервной копии, цели, эпохе ключа, сроку и одноразовому идентификатору. Затем три держателя долей участвуют в реконструкции внутри изолированной среды. Авторизация, исполнение и последующее уничтожение временного ключевого материала получают разные несекретные квитанции. Stellar multisig может быть публичным якорем одобрения или квитанции, но не расшифровывает backup и не должен переносить доли.

Это пока проектное предложение. Нельзя брать случайный фрагмент кода Shamir Secret Sharing и объявлять контур готовым: нужны аудированная реализация или протокол, защита от злонамеренного дилера и держателя, проверяемые доли, ротация, сценарий потери участника и синтетические учения.

Что проверено, а что ещё нет

Санитизированные испытания подтвердили два узких класса поведения. В режиме «ссылка, а не содержимое» тестовый объект был обработан внутри приватной зоны, а наружу вышел только ограниченный результат. В sealed-box challenge получатель успешно расшифровал одноразовый синтетический вызов и вернул hash-only readback. Это подтверждает работоспособность конкретных цепочек и владение подходящим ключевым материалом в момент теста.

Это не криптографический аудит, не формальная верификация и не готовый production-протокол. Ещё предстоят отдельные encryption keys, подписанная каноническая оболочка, устойчивое хранилище replay-состояния, аудированный реестр ключей с защитой от отката, проверка endpoint и резервного копирования, а пороговое восстановление должно появиться только позже. Система также не скрывает автоматически время, размер и граф сообщений и не спасает от заражённой конечной точки.

Приглашение к разбору

Ценность этой работы не в новой примитиве, а в попытке честно собрать стандартные компоненты и операционные границы. Поэтому особенно полезна внешняя критика: подходит ли SealedBox или лучше HPKE, как связывать идентичность и отдельный encryption key, какой формат подписывать, нужна ли более сильная forward secrecy, как защитить метаданные и как построить recovery без единой точки доверия.

Криптографов и инженеров безопасности приглашаю прочитать подробную Wiki-статью, указать на ошибки, предложить улучшения или переиспользовать общую модель публичной координации и приватного частного сервера. Главный текущий вывод остаётся консервативным: не развёртывать без независимого review.

← Все посты