ChatGPT и группы FFDH из TLS

В копилку примеров реального использования ИИ/LLM.

Попробовал тут выяснить, можно ли через ChatGPT узнать о группах для протокола FFDH (“мультипликативного” Диффи-Хеллмана, DH), используемых в TLS 1.3. Довольно специальный вопрос. Но зато вполне конкретный. Удивительно, но ChatGPT 5.2 тут же верно сообщило и номер RFC, где описаны эти группы, – RFC 7919, – и о том, что группы строго зафиксированы, что их всего пять. Это всё верно. Но, как обычно в таких делах, не будем торопиться с выводами.

То есть, подразумеваем, что ChatGPT тут использует человек, хорошо знакомый с математической частью, но который хочет узнать технические детали DH конкретно в TLS 1.3. Первая выдача ChatGPT, пусть и содержала какие-то домыслы про HSM и пр., но оказалась бы в таком сценарии полезной: номер RFC, информация о том, что используется зафиксированный набор групп, в общем – по теме и неплохо. В этом-то и кроется ловушка, как будет видно далее: данная система легко, с первого шага, производит впечатление “информированной”, но таковой не является.

Следующим запросом я попробовал выяснить значение конкретного модуля конкретной группы (основной параметр, задающий группу для FFDH, – простое число, называемое модулем). Опять же, удивительно, но ChatGPT даже смогло “понять” и корректно обработать опечатку в моём запросе: я пропустил одну цифру, написав ffdhe372 вместо ffdhe3072.

“В TLS нет группы под названием ffdhe372” – верно сообщило ChatGPT (здесь и далее я перевожу с исходного английского). “Вы наверняка имели в виду ffdhe3072 (RFC 7919, Group 15)” – уточнило ChatGPT. Что это за “Group 15” – непонятно, но, ладно, в остальном – очень верно. Именно ffdhe3072 и имелась в виду. Опять же, выглядит, как ответ очень “информированной” системы. Не то чтобы исправление подобных опечаток с использованием статистики корпуса текстов представляло какую-то техническую трудность, но, тем не менее, создаёт впечатление “подлинности”.

Ещё более удивительно, но ChatGPT распечатало абсолютно верное значение модуля – цифра к цифре. Это, конечно, улучшение, если сравнивать с тем, что было пару лет назад. Но дело тут не в данном улучшении, как вы, думаю, уже догадались: ChatGPT и сейчас легко генерирует несуществующие цитаты – я недавно сталкивался с тем, например, что оно сгенерировало ложную цитату “из труда Бомбелли”. Опять же – очевидно, что внутри ChatGPT нет никакой точной “базы знаний”, откуда оно могло бы извлекать подобную информацию универсальным образом – значение модуля, в данном случае. Но если смотреть узко, то складывается впечатление, что такая база там есть, что ChatGPT сходило в сохранённый текст RFC и скопировало оттуда значение модуля.

Нет. Всё не так, несмотря на непрерывное маркетинговое давление.

Дальше я спросил, как доказывается, что это – простое число. (Модуль должен быть простым числом, это базовое требование.) И тут ChatGPT кинулось в рассказы о тестах на простоту, о “доказуемо простых” числах и т.д., заявив, что использовался “алгоритм Маурера” (Maurer) и написав тому подобные техничные слова. Проблема в том, что это всё общие методы, не имеющие отношения к конкретному RFC и к конкретному модулю.

То есть, ChatGPT заявило, что простые модули в RFC 7919 выбирались методом Маурера (или по алгоритму, это не важно), начиная с некоторого небольшого известного простого. Это совсем не верно, но звучит очень похоже на правду, если только вы уже не знаете технических деталей. Такой вот ловкий обман. Естественно, тут же ChatGPT добавило показательный, по своему ложному положению, текст: “если бы в TLS использовались простые числа, похожие на случайные, но без доказательств, то злонамеренная сторона-генератор могла бы встроить бэкдор”. Этот фрагмент дословно верный, но только если его рассматривать вне контекста обсуждения и исходного запроса. А если в контексте, то под “доказательствами” тут имеются в виду “сертификаты” (“свидетели”) простоты числа, и это не имеет отношения к методу “защиты от бэкдоров”, который должен быть направлен на исключение возможности получения числа специального вида – доказательства тут должны доказывать то, что алгоритм не позволяет выбрать произвольное простое число, а числа там всегда простые. (Да, математически, наличие “сертификатов”, доказывающих простоту, – вычислительно ограничивает возможности по свободной генерации простых, но тут речь точно не об этом, да и ограничения там не являются блокирующими.)

Итак, следующий мой вопрос был о том, как же именно был получен модуль ffdhe3072.

Метод вычисления всех модулей из RFC 7919 описан в самом этом RFC. Буквально. Я как-то даже писал об этом подробно. В основе вычисления – запись числа e. В этом весь смысл: числа взяты “из записи” e, а не придуманы “с бэкдорами”. Схема называется NUMS – Nothing Up My Sleeve (“ничего в моём рукаве”).

То есть, если бы в ChatGPT был интеллект, – пусть и искусственный, – то этот “интеллект” взял бы RFC и прочитал. Тем более, что так хорошо всё начиналось. Но нет. ChatGPT стало продолжать в красках расписывать, что модули для RFC 7919 были получены по “детерминированному алгоритму Маурера”, прямо приводя фальшивый способ получения исходной константы: seed = SHA-256(“TLS FFDHE 3072”). Да. Настолько детально. И так далее, и тому подобное. Никакого отношения к RFC и к оригинальному источнику значений модулей – в этом не было (в RFC, ещё раз, написана конкретная формула, но она вообще не имеет отношения к “Мауреру”).

Это очередной пример большой проблемы: данные системы AI/LLM генерируют огромное количество текста с глубокими фактическими ошибками; на это тратится много энергии в дата-центрах; результат – затапливает; результат – уже встраивают не только в программный код реально используемых систем, но и в те же RFC. Если вы не специалист, который уже в деталях знает то, что пытается “выяснить” через LLM, то шанс обнаружить дефект и подмену минимальными усилиями – совсем не велик: требуется потратить много сил и времени.

P.S. А число, полученное как SHA-256(“TLS FFDHE 3072”), – составное: 0xd73d45623a7a52d11ea654956e701554a137fafd3545d46379891d7c4c79f545 = 3^2 * 7 * 3719447821 * 27939151181 * 3616471485699239 * 4111907187916820252669152053322571860357.

Адрес записки: https://dxdt.ru/2026/02/16/17374/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 5

  • 1 <t> // 16th February 2026, 20:14 // Читатель dss написал:

    У llm есть много реальных проблем. Поэтому мне каждый раз искренне непонятно, зачем для нагнетания FUD вы выбираете непроверяемые и неповторяемые примеры без подробностей, которые очевидно бьют мимо цели.
    Вот мой диалог с чатом: https://chatgpt.com/share/69934dbe-fd4c-800a-b92e-41a073879f7e
    Я могу наблюдать, что он корректно ссылается на нужные секции RFC и дает вполне вменяемые ответы. Ну, на мой взгляд. Я быстро прочитал RFC и не нашел явных ошибок, но мне было лень тратить время на тщательную вычитку, потому что я не собираюсь реализовывать tls руками.
    И каждый раз как я встречаю у вас статью про то, как «тупой llm бредит», я иду в чат, копирую туда заявленные запросы и вижу совсем не те ответы, что вы якобы получали. Похоже на подтасовку, и мне правда очень интересно, зачем вы это делаете, если можно очень просто найти реальные проблемы. Соломенный кланкер какой-то получается.

  • 2 <t> // 16th February 2026, 21:47 // Александр Венедюхин:

    Примеры там все “неповторяемые и непроверяемые”, потому что контекст так или иначе разный. Вы, например, спрашивали на русском. Непонятно, что там было раньше в конкретной сессии и для конкретного пользовательского аккаунта. И т.д. Но, например, в моём случае – сразу выдаётся нужный модуль, а по вашей ссылке – нет.

    Я непосредственные ссылки на ChatGPT не даю потому, что там, во-первых, утекает всё подряд; во-вторых – не хочется связывать мой текст здесь с выдачей. Что касается простого копирования ответов ChatGPT – тут я не вижу смысла тратить место на странице и перегружать текст.

    > копирую туда заявленные запросы и вижу совсем не те ответы,

    Это нормально – оно так работает. Не должно быть одинаковых ответов. Тем более, на разных языках. У вас там тоже – такое себе понаписано: “делает средние биты непредсказуемыми и устраняет подозрения, что число подобрано с бэкдором” и т.д. Но, видимо, проблемы в другом.

    > что вы якобы получали

    Ну, насчёт “якобы” – это вы зря, на мой взгляд: я написал так, как было. Но, собственно, у меня нет цели что-то доказывать.

  • 3 <t> // 17th February 2026, 14:26 // Читатель void написал:

    > 0xd73d45623a7a52d11ea654956e701554a137fafd3545d46379891d7c4c79f545 = 3^2 * 7 * 3719447821 * 27939151181 * 3616471485699239 * 4111907187916820252669152053322571860357

    Но как, Шерлок, чем Вы факторизируете 256-битные числа?

  • 4 <t> // 17th February 2026, 15:41 // Александр Венедюхин:

    В данном случае – воспользовался SAGE (SageMath). Из-за того, что тут много делителей, сработало очень быстро. Вообще, любые 256-битные числа сейчас факторизуются без проблем. Есть специализированные пакеты, я бы рекомендовал CADO-NFS.

  • 5 <t> // 25th February 2026, 17:34 // Читатель Charaverk написал:

    попробовал cloude 4.6 thinking
    на голову выше всего остального просто потому что:
    1. сразу же ‘замечает’ неправильный ответ
    2. принимает то что может ошибаться

    все ещё огромное множество ошибок, и код по типу такого (трейт это буквально минимальный пример)
    хотя я даже не просил генерировать, крч ужас

    std::coroutine_handle saved;
    coro_t make(int id) {LeakDetector d(id);co_return;}
    int main() {saved = {};//…
    уверен кста что ии не смогут написать подобное – https://godbolt.org/z/8MKWMPETc
    Но
    в отличии от других моделей его даже не необходимо (не требуется) газлайтить чтобы он нашёл реальные ошибки
    и целый 1 раз, хотя пускай и для lua with well documented api, но он выдал работающий вариант, проверил по документации потом, и потребовалось всего 1 исправление на 3 функции

Написать комментарий

Ваш комментарий:

Введите ключевое слово "9G948" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

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