Команда zkSecurity применила своего ИИ-аудитора zkao к экспериментальной криптобиблиотеке Cloudflare CIRCL и нашла семь реальных багов. Все семь уже исправлены. zkao — это агент, который непрерывно просматривает код в поисках уязвимостей, которые способен найти ИИ. Люди из команды всё ещё проверяют каждую находку, но zkao постепенно берёт часть этой валидации на себя.
Первый баг жил в реализации пороговой RSA (tss/rsa). Полином вычислялся через float64, у которого 53-битная мантисса. Как только $x^i$ превышало $2^{53}$, результат молча округлялся. Для 100 игроков это ломало вычисление ключевых долей. Починили заменой на схему Горнера с big.Int.
Второй — подделка DLEQ-доказательства в zk/qndleq. Параметр безопасности SecParam лежал внутри структуры Proof и был подконтролен атакующему. Если выставить SecParam = 1, challenge сводился к одному биту — монетке. Вместо этого SecParam теперь передаётся в Verify явно.
Третий баг — в VerifyAggregate BLS. Функция не проверяла, что все сообщения различны. Это классическая rogue key attack: злоумышленник мог подделать агрегированную подпись, зарегистрировав специальный ключ. ИИ оценил уязвимость как среднюю, хотя это известная критическая проблема. Разработчики подтвердили её как High. Теперь функция сама отклоняет повторяющиеся сообщения.
Четвёртый баг — самый хитрый, тоже в DLEQ. Атакующий берёт честное доказательство и подменяет в нём один элемент на отрицательный (-gx). Из-за того, что хеш считается через FillBytes, который отбрасывает знак, и того, что при чётном challenge $(-1)^c = 1$, верификатор принимает подделку. Срабатывало примерно в половине случаев. Исправили проверкой, что все входы находятся в диапазоне $0 < x < N$.
Пятый — ловушка языка Go в HPKE. В switchе использовали битовое ИЛИ (modePSK | modeAuthPSK). Это не два отдельных case, а один со значением 0x03. Ветка для modePSK (0x01) просто не выполнялась, и вызов SetupPSK с пустым PSK проходил молча. Починили заменой | на запятую.
Шестой — двойная проблема в tss/rsa. Коэффициенты Лагранжа считались в int64: при ~21 игроке происходило переполнение, а ещё было целочисленное деление до умножения на delta, что ломало точность. Всё перевели на big.Int и поменяли порядок операций.
Седьмой баг нашёл сам zkao. В CP-ABE (abe/cpabe/tkn20) случайное значение для AND-гейта вычислялось, но сразу перезаписывалось, так что один ребёнок получал весь секрет, а второй — ноль. Из-за того, что любой ключ имел доступ к одному из листьев корневого AND, это ломало контроль доступа целиком. Починили одной строкой.
Выводы команды: ИИ плохо оценивает серьёзность, часто завышая её, но может и опасно занизить (как с BLS). Пары моделей нестабильны: на одном датасете Claude Opus 4.6 находил больше, а через пару недель роли поменялись. ИИ склонен собирать находки рядом, не соединяя их в цепочку для более опасной атаки. Сейчас главное узкое место — ручной триаж сотен кандидатов, так как команда не хочет спамить разработчиков непроверенными отчётами.