Проверяем ответы ИИ по шифрованию данных: результаты теста
Вы спрашиваете у ChatGPT, как зашифровать строку на Python. Получаете аккуратный блок кода с импортами, функциями и даже примером вызова. Копируете, вставляете в проект, запускаете — работает.
Я решил проверить это не на уровне «мне кажется», а руками: взял несколько моделей, задал типовые задачи по шифрованию и разбору результатов — и внимательно посмотрел, что именно они предлагают. Результаты оказались неутешительными и одновременно очень полезными для понимания границ доверия к генеративному ИИ в критически важных задачах.
Фундаментальная путаница: хеширование ≠ шифрование
Первое, что бросается в глаза при систематическом тестировании, — модели стабильно смешивают два совершенно разных инструмента. Хеширование — это односторонняя функция: данные входят, отпечаток выходит, обратно путь заказан. Шифрование — двустороннее преобразование: зашифровал, получил ключ, потом расшифровал обратно. Это базовая архитектурная разница, азы.
Но когда вы просите модель «зашифровать данные» и она в ответ выдаёт вам SHA-256 — это не мелкая неточность, а фундаментальная ошибка в понимании задачи. Такой код не защитит ваши данные; он лишь создаст их отпечаток, который невозможно превратить обратно в оригинал. Если вам нужно хранить пароли — хеширование подходит. Если нужно передать кому-то зашифрованное сообщение и потом его прочитать — нет.
Модель предсказывает вероятную последовательность токенов, а не понимает математическую природу криптографического протокола. Это принципиальная разница, которую легко забыть, когда ответ выглядит убедительно.
Почему так происходит? LLM обучается на корпусе текстов, где слово «зашифровать» нередко соседствует с SHA-256 и MD5 — потому что в обучающих данных полно примеров хеширования паролей, а авторы статей и тредов на Stack Overflow порой используют терминологию небрежно. Модель улавливает статистическую связь и воспроизводит её. Ощущение, что она «понимает» разницу, — это наш когнитивный сдвиг, а не её реальная компетенция.
AES-GCM: где нейросети ломают надёжную схему
AES-GCM — один из самых распространённых и проверенных режимов шифрования. Используется повсеместно: от TLS-соединений до мессенджеров. Если попросить модель сгенерировать код для AES-GCM, результат визуально выглядит компетентно: импорт библиотеки, инициализация шифра, вызов encrypt. Проблема прячется в деталях — и конкретно в одном параметре, который модели регулярно игнорируют или генерируют неправильно.
Речь о nonce (он же IV, инициализирующий вектор). Это число, которое должно быть уникальным для каждого сообщения, зашифрованного одним и тем же ключом. «Уникальным» — не значит «красивым» или «длинным». Оно должно быть фактически непредсказуемым и ни в коем случае не повторяться. Один и тот же nonce с одним и тем же ключем — и математические гарантии AES-GCM рассыпаются: злоумышленник получает возможность восстановить части открытого текста.
В тестах модели регулярно предлагают решения с жёстко закодированным nonce — то есть буквально вписывают в код что-то вроде b'\x00' * 12 или фиксированную строку. Это удобно для демонстрации, но катастрофически небезопасно в реальном использовании. Другой частый вариант — генерация nonce через стандартный random из Python, который не является криптографически стойким генератором. Правильный подход — использовать модуль secrets или os.urandom(), но модели часто выбирают путь наименьшего сопротивления.
| Что предлагает ИИ | Что нужно делать | Почему разница критична |
|---|---|---|
Жёстко закодированный nonce (b'\x00'*12) | Генерировать случайный nonce для каждого сообщения | Повторный nonce с тем же ключем раскрывает данные |
import random для генерации | import secrets или os.urandom() | Стандартный random — не криптографический PRNG, его выход предсказуем |
| Nonce не сохраняется рядом с шифротекстом | Передавать nonce открыто вместе с шифротекстом | Без nonce получатель не сможет расшифровать сообщение |
| Использование одного ключа навсегда | Ротация ключей после определённого объёма данных | Один ключ + много сообщений = растущий риск компрометации |
Это не теоретический риск. Если вы встроите такой код в протокол, работающий с реальными средствами или личными данными, последствия будут вполне осязаемыми.
40% кода с уязвимостями: что говорит статистика
Заявления о «ненадёжности ИИ-кода» звучат абстрактно, пока не увидишь цифры. Исследования, проведённые в 2023 году и опубликованные на arXiv, показали: при тестировании ответов моделей (включая GPT-4) на задачи по генерации криптографического кода от 30 до 40% предложенных решений содержали уязвимости, классифицируемые как критические по стандартам OWASP.
OWASP Top 10 — это не абстрактная академическая классификация. Это индустриальный стандарт, по которому проверяют реальные приложения, и «критическая» оценка означает, что уязвимость может привести к компрометации данных, потере средств или полному обходу механизма защиты. Когда треть или даже больше ответов ИИ попадают в эту категорию, речь идёт не о курьёзе, а о системной проблеме.
Конкретные типы ошибок, которые всплывают наиболее часто:
1. Использование небезопасных генераторов случайных чисел. Модели предлагают random.randint() там, где нужен secrets.token_bytes(). Это как использовать дешёвый замок для сейфа — формально заперто, по факту — нет.
2. Хардкод ключей и секретов. Код с вписанным напрямую ключом выглядит удобно для демо, но в реальном проекте это открытая дверь. Модели редко напоминают о необходимости использования переменных окружения или менеджеров секретов.
3. Отсутствие проверки целостности. Шифрование без аутентификации (без тега в GCM, без HMAC в CBC) — данные зашифрованы, но вы не можете быть уверены, что их не подменили в пути.
4. Неправильный выбор режима. Предложение ECB для произвольных данных — классика жанра. ECB шифрует блоки независимо, что делает паттерны в открытом тексте видимыми в шифротексте.
30–40% ответов ИИ по криптографии содержат критические уязвимости по стандартам OWASP. Это не курьёз, а системная проблема, которую нужно закладывать в процесс разработки.
Иллюзия компетенции: почему убедительный ответ — не правильный ответ
Главная опасность LLM в задачах шифрования — не в том, что они откровенно ошибаются (такие случаи заметны), а в том, что они ошибаются красиво. Код компилируется, запускается, даже выдаёт результат. Структура ответа логична: вступление, пояснение, пример использования. Всё выглядит как грамотная документация от разработчика, который знает, что делает.
Это и есть та самая иллюзия компетенции. Модель не верифифицирует свои ответы на безопасность — она генерирует наиболее вероятную последовательность токенов на основе обучающих данных. Если в обучающем корпусе много примеров с небезопасным кодом (а их там достаточно, потому что в учебных репозиториях и туториалах безопасность часто приносится в жертву простоте), модель будет воспроизводить эти паттерны с высокой уверенностью.
Попробуйте эксперимент: спросите у модели, безопасно ли использовать random.SystemRandom() вместо secrets. Ответ, скорее всего, будет внятным и структурированным. Но правильность зависит от контекста — а контекст модель часто не учитывает или учитывает неполно. Она не понимает, почему криптографический генератор отличается от обычного, — она лишь видела, что в «правильных» ответах чаще встречается одна конструкция, а в «неправильных» другая.
Это напоминает ситуацию с модными трендами: можно следовать рекомендациям стилистов, но если не понимать принципов сочетания фактур и пропорций, результат будет «по гайду», но не обязательно гармоничным. С криптографией та же история: копировать структуру кода без понимания математики — значит получить иллюзию безопасности.
Границы ответственности: где заканчивается ассистент и начинается инженер
Самый частый вопрос, который я слышу: «Ну а что, совсем нельзя пользоваться ИИ для крипто-задач?» Можно. Но с пониманием, для чего именно.
LLM — хороший инструмент для генерации черновиков, подсказки синтаксиса и объяснения концепций на пальцах. Если вы разбираетесь в предмете и используете модель как ускоритель, а не как единственный источник истины — это рабочий паттерн. Но если вы не можете отличить CBC от GCM и не знаете, что такое nonce, — генерация кода через ИИ становится рулеткой, где 30–40% ячеек — «проигрыш».
Вот простой чек-лист, который стоит пройти, прежде чем встраивать сгенерированный ИИ крипто-код в проект:
- Понимаете ли вы, что именно делает каждая строка? Если нет — не используйте код, даже если он работает.
- Проверяли ли вы nonce/IV на уникальность? Это первое, что модели портят.
- Какой генератор случайных чисел используется?
random— нет.secretsилиos.urandom()— да. - Есть ли аутентификация шифротекста? AES-GCM с тегом — хорошо. AES-CBC без HMAC — плохо.
- Кодировался ли ключ жёстко в тексте программы? Если да — немедленно исправляйте.
Пять вопросов. На каждый должен быть однозначный ответ. Если хотя бы один вызывает сомнение — код не готов к продакшену.
Дополнительный уровень защиты — формальная верификация. Для смарт-контрактов и протоколов, работающих с реальными средствами, существуют специализированные инструменты аудита, которые проверяют свойства кода математически. Доверять аудиту ИИ-модели для такой задачи — примерно как доверять навигатору, который не видит карту целиком, а только предсказывает следующий поворот.
Практический вердикт
После серии тестов у меня сформировалось чёткое представление о месте ИИ-ассистентов в криптографическом стеке разработки.
Что модели делают хорошо: объясняют концепции, подсказывают синтаксис библиотек, генерируют скелет функций, которые потом дорабатываются вручную. Для обучения и онбординга в тему — полезный инструмент.
Что модели делают плохо: генерируют безопасный криптографический код «с нуля». Особенно в задачах, где мелкая деталь (размер nonce, выбор генератора, наличие аутентификации) определяет, будет ли схема работать или рассыплется при первой же атаке.
Мой совет: используйте ИИ как справочник и генератор идей, но не как криптографа. Финальную проверку кода, связанного с шифрованием, — всегда за человеком, который понимает не только синтаксис, но и математику стоящих за ним протоколов. Тридцать секунд экономии на генерации кода могут обернуться месяцами исправления уязвимостей — или потерей средств, если речь о блокчейн-проекте.
ИИ — хороший черновик, но плохой криптограф. Граница между этими двумя ролями — и есть то место, где заканчивается удобство и начинается ответственность инженера.
