Деривация ключей Kaspa Forge изнутри: один сид — все инструменты

Хранилище Kaspa Safe требует горячий ключ и тревожный ключ. Каждая сделка Kaspa Escrow генерирует ключи покупателя и продавца плюс отдельную пару ключей для зашифрованного чата. Кошелёк Desk хранит адреса для получения. По грубым подсчётам — дюжина секретов: по одному на инструмент, по одному на сделку, и со временем их число только растёт.

Kaspa Forge сводит всё это к одному 256-битному мастер-сиду. Каждый приватный ключ, с которым когда-либо работает ваш браузер, детерминированно выводится из этого сида с помощью HMAC-SHA512 с разделением по доменам. Эта статья — про *механику* этого слоя: формула деривации, как домены предотвращают коллизии ключей, как сессия удерживает ключевой материал вне досягаемости сервера и что каждый инструмент делает со своими ключами. (Практический процесс резервного копирования и восстановления — ключ-файл .age и gap-скан — разобран в статье-компаньоне: одна резервная копия, покрывающая будущее.)

Разрастание ключей: проблема самостоятельного хранения с несколькими инструментами

Хранилище Kaspa Safe — это ончейн-ковенант (vault.sil), параметризованный публичными ключами: *горячий* ключ для повседневных выводов и отдельный *тревожный* ключ, способный отменить кражу в процессе в пределах задержки, выбранной владельцем. Два хранилища — скажем, долгосрочное и расходное — это уже минимум четыре ключа.

Добавьте Kaspa Escrow: каждая сделка генерирует собственную пару ключей покупателя или продавца плюс отдельный ключ *чата*, криптографически изолированный от ключа сделки — чтобы раскрытие ключа чата при споре не ставило под угрозу средства. Кошельку Desk нужны собственные адреса для получения.

Если бы каждый инструмент генерировал ключи независимо, каждое новое хранилище или сделка добавляли бы ещё один секрет для экспорта и учёта, а сегодняшняя резервная копия ничего не знала бы о завтрашних ключах. Цель дизайна: один сид, созданный однажды, порождает все ключи — включая ключи хранилищ и сделок, которых ещё не существует.

Деривация: HMAC-SHA512 с доменными строками

В центре — 256-битный мастер-сид, генерируемый в браузере при настройке Desk через Web Crypto API. Сид никогда не покидает клиент; он существует в памяти только пока Desk разблокирован. Функция деривации в WASM-модуле Kaspa Forge (derive.rs) выглядит так:

private_key = HMAC-SHA512(
    key  = master_seed,
    msg  = "kaspaforge/v1/{domain}/{index}"
)[0..32]   // первые 32 байта = секрет secp256k1

HMAC-SHA512 — это хеш с ключом: сид передаётся как секретный ключ, структурированное сообщение — как данные. На выходе 64 байта; первые 32 байта становятся приватным ключом, остальное отбрасывается.

Концептуально это похоже на HD-кошельки BIP-32, но структура более плоская: каждый ключ выводится непосредственно из корня, а не из родительского ключа. Преимущество — ясность: каждая доменная строка — самодостаточный, человекочитаемый «адрес» назначения. Цена — невозможность *публичной* деривации (нельзя вывести дочерний публичный ключ без сида).

Индексы — последовательные целые числа, которые отслеживает профиль Desk. Первое хранилище получает индекс 0, второе — 1 и так далее. Один и тот же сид с одним и тем же сообщением всегда дают один и тот же ключ — в этом весь смысл: выведите заново из сида — и вы восстановите каждый когда-либо созданный ключ.

Разделение доменов: один сид — разные подпространства

Компонент {domain} не даёт ключам одного инструмента быть валидными в другом, даже при совпадении индексов. Референсная реализация использует отдельные доменные строки для каждого контекста:

Суффикс ~token создаёт отдельное подпространство внутри домена: API-токен хранилища криптографически независим от его подписывающих ключей, поэтому утечка токена не компрометирует хранилище.

У ключей чата Kasia есть дополнительное ограничение: схема ECIES, используемая для сквозного шифрования, требует *чётной* Y-координаты публичного ключа. Если попытка деривации даёт нечётную чётность, схема инкрементирует счётчик и выводит ключ заново, пока не получит чётный.

Вся схема закреплена тестами с известными векторами — жёстко зашитыми наборами (сид, домен, индекс) → ожидаемый_секретный_ключ, которым обязана удовлетворять каждая сборка WASM-модуля. Если изменение кода случайно сдвинет деривацию, тесты упадут до релиза. Это важнее, чем кажется: тихое изменение деривации означало бы, что браузер и офлайн-инструменты восстановления вычисляют *разные* ключи из одного сида — и все существующие резервные копии превратились бы в мусор.

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

Деривация выполняется исключительно в браузере. WASM-ядро загружает сид в память, выводит ключи по требованию и подписывает транзакции локально. Ни приватный ключ, ни сид, ни парольная фраза никогда не достигают сервера. Сессию защищают три слоя:

• Boot guard (requireUnlock): каждая страница стартует заблокированной. Холодная загрузка требует ввода парольной фразы профиля прежде, чем станет доступен любой ключевой материал.
• Подтверждение при подписании: вывод из хранилища или релиз средств эскроу вызывает повторный запрос пароля с конкретным контекстом — суммой и получателем, — чтобы вы подтвердили именно то, что подписываете.
• Автоблокировка: 15 минут бездействия блокируют сессию, выведенные ключи покидают память браузера.

Сервер видит только публичные ключи, параметры ковенантов и предподписанные транзакции. Именно это делает Kaspa Forge некастодиальным по построению: смерть сервера не касается ваших средств, потому что сервер никогда не держал ключи.

Как каждый инструмент использует деривацию

Kaspa Safe. Каждое хранилище получает горячую и тревожную пары ключей из домена vault. Скрипт ковенанта (vault.sil) кодирует их публичные ключи как параметры конструктора, и семь путей траты — инициация, отмена, завершение, чек-ин, наследование, миграция — требуют конкретных подписей этими ключами. Альтернативная конфигурация хранит в профиле alarm_card: true вместо выведенного тревожного секрета: тревожный ключ тогда живёт только на физической карте или отдельном устройстве, полностью вне браузера. Профиль также несёт пару ключей фандинг-адреса хранилища и кап fee_budget, ограничивающий сетевую комиссию, которую допускает ковенант.

Kaspa Escrow. Каждая сделка выводит пару ключей покупателя или продавца в домене escrow; десять путей траты контракта (релиз, возврат, взаимный релиз, спор, арбитраж, таймауты) параметризованы этими публичными ключами. Ключ чата сделки приходит из отдельного домена kasia — намеренно: при споре сторона раскрывает ключ чата, чтобы ИИ-медиатор расшифровал переписку и сформировал необязывающую рекомендацию. Сервер проверяет, что раскрыт именно публичный ключ *чата*, а не ключ эскроу, — чтение переписки в принципе не может потратить средства.

Кошелёк Desk. Адреса получения выводятся в подпространстве wallet. Профиль отслеживает текущий адрес и предыдущие (walletOld); при трате Desk суммирует UTXO по всем адресам, подписывая каждый вход соответствующим выведенным ключом в одной P2PK-транзакции — стандартное поведение HD-кошелька, объединённое под тем же сидом, что питает хранилища и эскроу.

Одна резервная копия, одно восстановление — коротко

Поскольку всё выводится из одного сида, история резервного копирования сводится к одному зашифрованному файлу: профиль Desk (сид плюс метаданные хранилищ) шифруется инструментом age под вашей парольной фразой в один переносимый ключ-файл .age, а gap-скан при восстановлении заново находит каждый выведенный ключ — включая хранилища, созданные *после* резервной копии, — перебирая индексы деривации по блокчейну. Если сам Kaspa Forge окажется недоступен, CLI с открытым исходным кодом vaultctl восстановит контроль над хранилищами из расшифрованного профиля на любом узле Kaspa v2+.

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

Компромиссы и честные ограничения

Единая точка отказа на уровне сида. Если злоумышленник получит ваш мастер-сид, скомпрометированы все ключи всех инструментов — хранилища, эскроу, кошелёк, чат. Это фундаментальный компромисс детерминированной деривации: удобство (одна резервная копия) концентрирует риск. Парольная фраза .age защищает утёкший файл, но сам сид — главная драгоценность.

Хранилище браузера — не сейф. Всё подписание происходит в браузерном WASM; интеграции с Ledger или Trezor пока нет. Вредонос с доступом к контексту браузера теоретически может перехватить парольную фразу при разблокировке или прочитать выведенные ключи из памяти разблокированной сессии. 15-минутная автоблокировка сокращает окно экспозиции, но не устраняет его. Для крупных сумм опция тревожной карты выносит тревожный ключ полностью за пределы браузера.

Разделение доменов — конвенция, а не правило консенсуса. Ничто в блокчейне не заставляет ключ с меткой vault/0 использоваться только в контексте хранилища. Префикс kaspaforge/v1/... делает коллизии с другим софтом маловероятными, но это соглашение об именовании, а не криптографическая гарантия — и другие кошельки Kaspa эти пути не распознают. Восстановление поэтому требует собственных инструментов Kaspa Forge (restore в Desk или vaultctl), а не универсального BIP-32-софта.

Нет деривации только по публичному ключу. Поскольку HMAC-SHA512 применяется на корневом уровне, вывод любого дочернего ключа требует секретного сида. Для персонального самостоятельного хранения это не проблема, но watch-only-сценарии, где третья сторона генерирует адреса по одному публичному ключу, исключены.

Версионируемый бета-формат. Профиль Desk сейчас версии 3; будущие версии могут добавить домены деривации или скорректировать схему. Тесты с известными векторами — страховка от тихого дрейфа, но офлайн-инструменты придётся перепубликовывать под новые версии профиля.

Почему это важно для самостоятельного хранения

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

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

---

*Схема деривации — часть открытого WASM-модуля Kaspa Forge: github.com/Kaspaforge/kaspaforge. Статьи-компаньоны: гайд по резервному копированию и восстановлению, клиентские ключи в Desk и как устроено хранилище.*