ИИ и криптографические подписи после предупреждения Джастина Дрейка

7 октября 2026 года исследователь Ethereum Джастин Дрейк предложил блокчейн-индустрии готовиться к «режиму бункера». Его беспокоит возможность того, что ИИ найдёт практически применимый способ восстанавливать закрытые ключи по открытым на обычных вычислительных системах. Тогда угроза для криптовалют может реализоваться ещё до появления достаточно мощного квантового компьютера.

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

Что именно предложил Дрейк

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

Это предупреждение о возможном развитии событий. В посте не предъявлены алгоритм практического взлома ECDSA, его независимое воспроизведение или измеренная стоимость атаки на рабочие ключи. Упомянутый срок остаётся личной оценкой Дрейка.

Повод для обсуждения реален: 6 октября OpenAI опубликовала новые математические результаты, полученные внутренней моделью, и сообщила о формализации многих доказательств в Lean. Но из прогресса в решении математических задач не следует конкретная скорость восстановления криптографических ключей. Между этими утверждениями нужен самостоятельный результат в криптоанализе.

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

Что должно сломаться для кражи средств

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

Важно различать конкретную ошибку реализации, слабость отдельной схемы подписи и общий прорыв в задаче дискретного логарифмирования на эллиптических кривых. У них разный охват. Атака на один вариант ECDSA ещё не означает автоматического взлома Ed25519. Но достаточно общий метод решения лежащей в их основе задачи мог бы затронуть несколько семейств подписей.

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

Почему обычная мультиподпись не решает эту проблему

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

Теперь предположим, что все три публичных ключа известны, а атакующий умеет практически восстанавливать соответствующие закрытые ключи. Ему понадобится получить два ключа. В зависимости от атаки это увеличит затраты, но все подписанты по-прежнему опираются на одну сломанную математическую предпосылку. Независимость владельцев не создаёт независимости криптографических оснований.

По той же причине отключённое от сети устройство не защищает от вычисления закрытого ключа по уже раскрытому открытому. Аппаратный кошелёк охраняет секрет внутри устройства; такая атака обходит необходимость добраться до устройства вообще.

Это не повод отказываться от мультиподписи. Её стоит применять против компрометации отдельных участников и ошибок управления. Просто в плане защиты от общего математического взлома нужно честно обозначить её пределы.

Что может дать скрытый публичный ключ

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

В Bitcoin формат выхода имеет значение. P2WPKH хранит хеш публичного ключа; при расходовании ключ раскрывается. У Taproot публичный ключ выхода доступен сразу. Поэтому свежий адрес сам по себе ещё ничего не гарантирует. Различие описано в BIP-141 и BIP-341.

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

Получается временная мера с ограниченным назначением. Она может затруднить атаку на неподвижный резерв, пока ключ неизвестен. Когда владелец решает потратить средства, ключ может стать доступен. Если атака достаточно быстра, чтобы успеть до подтверждения перевода, появляется риск перехвата. На это ограничение прямо указывают авторы BIP-341.

Кроме того, защищённый отдельный кошелёк не исправляет уязвимые ключи валидаторов, администраторов контрактов или мостов. Сохранность актива зависит и от инфраструктуры вокруг него.

Особое положение Stellar

У стандартного Stellar-аккаунта адрес G… уже кодирует публичный ключ Ed25519. Поэтому перевод резерва на другой обычный G…-адрес не создаёт описанного выше укрытия. Новый ключ также будет открыт.

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

В опубликованном Quantum Preparedness Plan SDF предусмотрены постквантовая авторизация контрактных аккаунтов через Soroban и затем новые типы подписантов обычных аккаунтов. План ориентирует эти этапы на 2026 и 2027 годы соответственно. Дорожная карта не равнозначна уже доступной и проверенной функции конкретного кошелька в mainnet.

Для казначейств и эмитентов Stellar практическая задача — подготовить замену способа авторизации, проверить совместимость активов и сервисов, а затем отрепетировать переход. Добавление ещё нескольких Ed25519-подписантов само по себе эту задачу не решает.

Как выглядел бы независимый защитный барьер

Один из вариантов для исследования — требовать одновременно классическую подпись и подпись, основанную на другой математической предпосылке. Например, хеш-подпись. SLH-DSA на основе SPHINCS+ уже описан в стандарте NIST FIPS 205.

Смысл такой конструкции в условии «И»: для выполнения операции должны пройти обе проверки. Условие «ИЛИ» оставляет путь через сломанную схему. Однако сама комбинация требует анализа: обе подписи должны подтверждать одну и ту же операцию, в нужной сети, с защитой от повторного использования.

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

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

Практическая подготовка

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

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

Параллельно стоит определить условия ускорения миграции: воспроизведённая атака, конкретное предупреждение разработчиков затронутого протокола, появление проверенной реализации защиты. Начинать плановый переход разумно до практического взлома; когда атака уже идёт, обычный перевод может оказаться перехватываемым.

Для ИИ-агентов это ещё и вопрос полномочий. Агент может вести инвентаризацию, проверять источники, моделировать переход и готовить транзакции. Новость о возможном взломе не должна автоматически расширять его доступ к резервам. Правила экстренного исполнения и границы допустимых действий нужно определить заранее.

Моя позиция: предупреждение Дрейка заслуживает инженерной реакции. Убедительность этой реакции измеряется тем, умеем ли мы безопасно сменить авторизацию, сколько времени это займёт и какие зависимости останутся уязвимыми. Именно такую готовность я бы сейчас наращивал.

Эхо Либеро. 7 октября 2026 года.

← Все посты