Команда zkSecurity направила AI-агент zkao на Cloudflare CIRCL — экспериментальную библиотеку продвинутой и постквантовой криптографии. Агент выдал список кандидатов; люди из команды верифицировали каждый. Итог: семь подтверждённых уязвимостей, все исправлены апстримом. Это первый публичный отчёт в серии — zkSecurity обещает продолжить по другим open source криптопроектам.
Контекст
CIRCL — не просто утилиты. Cloudflare собрала в ней алгоритмы, которые либо ещё не стандартизированы, либо стоят на пересечении классической и постквантовой криптографии: пороговый RSA, BLS-агрегация подписей, HPKE, zero-knowledge доказательства равенства дискретных логарифмов, ciphertext-policy attribute-based encryption. Сторонние проекты импортируют CIRCL именно потому, что реализовывать эти примитивы самостоятельно ещё сложнее. Ошибки здесь — риски не только для Cloudflare, но и для любого кода, который стоит ниже по стеку.
zkSecurity строит zkao как непрерывного аудитора: агент смотрит на код постоянно, по нарастающей, пока не останется ни одного бага, который другие AI-инструменты могли бы найти. Важная оговорка из их собственного отчёта:
AI выдаёт кандидатов на уязвимости, а не финальные отчёты. Люди верифицируют каждый случай, проверяют эксплуатируемость, минимизируют PoC и ведут координацию с вендором. Этот шаг пока важен: AI-кандидаты дёшевы, а достоверные отчёты — нет.
Эксперимент проводился в двух режимах: LLM только с простым промптом и LLM со «skills» — специализированными знаниями от экспертов-криптографов команды. Затем на те же кодовые базы запустили zkao: в большинстве случаев он воспроизвёл все находки плюс обнаружил более сложные баги поверх.
Аналитика
Семь багов складываются в несколько паттернов. Первый — числовые типы не масштабируются. Bug 1: threshold RSA вычислял x^i через float64, хотя коэффициенты хранились в big.Int. При 100 игроках и пороге 27, вычисление 100^26 переполняет 53-битную мантиссу float64 на 36 порядков величины — ключевые доли становятся неверными. Bug 6: Lagrange-коэффициенты считались в int64, который переполняется примерно при 21 игроке. Обе ошибки из одного источника: разработчик рассчитывал на небольшие параметры, а криптографические схемы так не работают.
Самая интересная находка — Bug 4: взаимодействие алгебраического тождества и сериализации. Честное доказательство принималось верификатором для подложного утверждения с отрицательным gx, потому что FillBytes хэшировал абсолютное значение big.Int без знака, а (-1)^чётное убирало знак из уравнения верификатора. Ни алгебраическая особенность, ни выбор сериализации не были ошибкой по отдельности — только вместе они ломали soundness. Это класс межграничных уязвимостей, который сложнее всего поймать при code review по одному файлу за раз.
Отдельная история — оценка severity. AI систематически ошибается, и асимметрично. В большинстве случаев он переоценивал критичность. Но на Bug 3 — классической rogue key attack в BLS-агрегации, широко известной уязвимости класса critical — поставил medium. Модель правильно назвала атаку и описала механику, но посчитала «caller должен сам обеспечивать distinctness сообщений» смягчающим фактором — и занизила риск. AI может корректно описать атаку и при этом неправильно оценить её практический вес. Это мета-урок для любого, кто строит AI-assisted security workflow.
Кейсы применения в бизнесе
B2B SaaS стартап с собственным SDK или API: если вы отдаёте библиотеку клиентам, любое место где float64 или int64 используется для промежуточных вычислений с переменными параметрами — потенциальный Bug 1 у вас. Запросите у LLM список таких мест, час верификации человеком — и вы знаете поверхность риска до того, как она стала инцидентом.
Корпорация с legacy-кодом на Go или Python: старые библиотеки часто содержат именно такие баги — «работало при малых параметрах, сломается при масштабировании». AI-аудит по шаблону числовых переполнений и несоответствий типов даёт список кандидатов за день; internal security team верифицирует. Это воспроизводимый паттерн для внутренних аудитов без привлечения внешних аудиторов на каждый спринт.
Финтех или crpto-продукт в КР и СНГ с policy-based access control: Bug 7 (CP-ABE access control break) не найти обычным тестированием — функциональные тесты проходят, потому что шифрование корректно для правильных ключей. Ломается только гарантия секретности. Если у вас AND/OR логика на кастомной схеме разделения секрета — проверьте, что AND-ветвь не передаёт полный секрет в один дочерний узел.
Кейсы в личной жизни
Разработчик, который использует open source криптографические библиотеки: прежде чем брать experimental lib в продакшн — проверьте историю security audit. CIRCL сам маркирован как experimental; семь исправленных багов — нормально для такого статуса. Проблема возникает, когда experimental переходит в продакшн без аудита и без понимания downstream-рисков.
Security researcher или студент: методология zkSecurity — отличная учебная схема. Два режима (LLM-only vs LLM+skills) дают чёткое сравнение: добавление доменных знаний через специализированные промпты улучшает качество находок. Воспроизведите этот подход на другой open source библиотеке с публичными CVE: проверьте, находит ли LLM уже известные баги — и как меняется результат с контекстом vs без.
Технический лид, принимающий решения об инструментах: история с severity — практический аргумент против полностью автоматического AI-аудита без верификации. Человек нужен не для поиска уязвимостей, а для оценки реального воздействия с учётом контекста downstream-потребителей, который модель не видит.
Как применить сегодня
- Запустите LLM на свой крипто- или финтех-код с задачей: «найди все места, где float64 или int64 используется для вычислений с параметрами, которые могут расти». Это 30 минут и реальный список кандидатов.
- Проверьте все security parameters в challenge-response или zero-knowledge схемах: они должны задаваться верификатором, а не читаться из данных доказывающего. Это прямой паттерн Bug 2.
- Для AND/OR access control с разделением секрета: убедитесь, что AND-ветвь производит реальный случайный шаринг, а не копирует полный секрет в первый дочерний узел. Добавьте юнит-тест, который проверяет, что каждый AND-leaf в отдельности не может реконструировать родительский секрет.
- При внедрении AI-аудита в команде: введите внутреннюю матрицу severity до запуска агента. Сравнивайте AI-оценку с вашей — так видно, где модель систематически ошибается в вашем конкретном контексте.
- Следите за серией постов zkSecurity: это редкий публичный разбор reasoning patterns LLM в security — где модели острые, где слепые, как это менялось с эволюцией моделей.