С “червём” CrowdStrike, конечно, странная история, но не менее странно и то, что уж в корпоративной-то Windows-среде есть все штатные способы настроить тестовую зону для раскатки обновлений. То есть, обновления должны сперва локально раздаваться только на некоторые машины, где отдельная служба может проверить, что оно не сломало всё, куда дотянулось, а только потом, когда некоторая уверенность появилась, обновления можно попробовать применять дальше. Наверное, с CrowdStrike ситуация другая. Наверное, можно так устроить программу-агента с центральным управлением, что она сломается только после того, как расползётся по достаточному количеству компьютеров.
Да, понятно, что описанный способ администрирования, с контролируемым изменением системного ПО, как и многие смежные технологии, это сейчас скорее из области теории, поскольку на практике, когда у вас есть внешний “непогрешимый ИИ”, управляющий “безопасностью ИТ-решений”, то этот ИИ может сам центрально раздать любой код на любые машины, где работают его “пробники”, поскольку windows-операторы свою часть уже сделали в самом начале: “прокликали Next->Next->Next до Finish”.
(Касается, кстати, и мониторинговых решений с агентами для линукс-систем. Тут, конечно, ситуация получше, но, вообще-то, в корпоративных средах предпочитают расставить на все машины, до которых удалось дотянуться, предположим, Zabbix-агент, и не задумываться о том, что это за программа и каковы её возможности.)
Комментировать »
В статье Situational Awareness, которую я недавно упоминал, уровень “интеллекта” LLM GPT-4 (ChatGPT) неоднократно обозначен как соответствующий продвинутому старшему школьнику (smart high schooler). Появился свежий препринт (Vision Language Models are blind) на эту же тему, в котором, впрочем, выясняют, что самые продвинутые современные системы LLM – точнее, VLM, в том числе, GPT-4o, – не могут справиться с элементарными задачками, которые под силу и не особо продвинутому дошкольнику.
Впрочем, все эти задачи связаны с “картинками”, но именно поэтому в качестве предмета исследования выбраны те ИИ-системы, которые заявлены для работы с “визуальными” материалами. То есть, тут нельзя сказать, что данные системы “не имеют возможности видеть”, использовав распространённый манипулятивный способ перевода реальных проблем “интеллекта” LLM (например), возникающих с самыми элементарными задачами, в разряд “ограничений” самой технологии.
Между тем, как указано в работе, эти ИИ-системы не могут верно определить количество пересечений для двух ломаных – см. скриншот с примером из исходной работы ниже.
Не справляются представленные ИИ-системы и с другими элементарными задачами: определить выделенную букву в слове, посчитать количество окружностей, определить, пересекаются ли круги, и т.д., и т.п.
Понятно, что речь тут может идти только о стопроцентном результате, когда верно указаны все ответы. Для “продвинутого старшего школьника” подсчёт точек пересечения линий на подобной картинке – более чем элементарная задача. Угадывание же при помощи оптимизированного перебора, которое выдают за “думание” для данных систем, тут не производит никакого впечатления. Лучший результат, который приводят в работе, это угадывание в ~77% случаев, продемонстрированное VLM Sonnet-3.5; GPT-4o – лишь около 49%, при этом, по формулировке задачи, случайный выбор ответа, без учёта картинки, дал бы одну треть верно угаданных результатов.
Так что, когда следующий раз в СМИ встретится очередная восторженная публикация о том, что “новая LLM на нейросети успешно сдала экзамены в вуз”, можно смело задуматься о том, смогла ли эта LLM хотя бы заполнить регистрационную анкету и вписать ответы в нужные “окошки”.
Комментировать »
Практический пример того, как автоматизация процессов работы с исходным кодом и репозиториями (читать нужно: CI/CD) может легко и неожиданно “выйти боком”: токен с правами полного доступа к репозиториям Python и PyPI на GitHub долгое время находился в открытом доступе.
Разбор инцидента из первых рук позволяет понять, как так вышло: наружу отправился локальный файл .pyc, случайно оставшийся в локальной (общей для процесса сборки) директории, которая требовалась для работы приложения в Docker-контейнере; ну и не менее случайно – в этом .pyc-файле сохранился токен доступа.
Комментировать »
Книга Эдмунда Беркли (Edmund Berkeley) Giant Brains, or Machines That Think (дословно: “Огромные мозги, или Машины, которые думают”, англ.; полный текст доступен по ссылке) вышла в 1949 году, 75 лет назад. В ней рассказано о базовых технических принципах, позволяющих строить компьютеры, а также о нескольких конкретных “думающих” “машинах” того времени, в том числе, про аналоговые вычислители.
Несмотря на название, “хайпа” в книге совсем нет. Напротив, автор ещё в предисловии отмечает, что некоторые его обобщения, – особенно, относящиеся к трактовке понятия “думания”, – могут быть спорными. Основную часть высказанных в этой книге утверждений про машины переписывают и сегодня, но уже безапелляционно и в канве современного “ИИ-хайпа”, а точнее – всех этих LLM/GPT/AI, успешно сдающих студенческие тесты по психологии.
Так, в книге дана та же трактовка способности складывать числа, как признака интеллекта, которую и сейчас постоянно используют. Беркли в данной книге относит к признакам “думания” (think) способность сложить в уме два числа, 12 и 8, получив число 20. При этом описывается, как мог бы складывать числа в уме человек – дописывание позиций к начальному значению (см. ниже). В качестве иллюстрации утверждается, что если бы нашлась, например, лошадь, которая смогла бы складывать числа и выдавать ответы, то такую лошадь люди непременно бы посчитали способной думать (к сожалению, не объясняется, почему говорящая лошадь, не умеющая выдавать ответы на арифметические вопросы, должна быть объявлена не-думающей; это, между тем, очень близко к типичной современной трактовке работы LLM, которые выдают текст на естественном языке).
Тут особенно интересно следующее. Автор сначала описывает “процесс думания”, осуществляемый человеком, складывающим числа: вот, мол, этот человек использует свой разум для того, чтобы отсчитать восемь позиций, начиная от двенадцатой, и прийти к числу двадцать. То есть, казалось бы, тут почти уже охвачен действительно важный, определяющий момент – возможность описать процесс счёта для внешнего наблюдателя, снабдив описание представлением о числах и отделив сам процесс от конкретных, “механических” значений. К сожалению, этот момент в книге тут же теряется, а вместо него, в сопровождении дополнительных аспектов условного ветвления и поиска по индексу (тьюринг-полнота, видимо), развивается небогатое обратное утверждение: мол, если нечто, – даже не говорящая лошадь, а механический калькулятор, – может вывести сумму 12 и 8, то это нечто тоже думает. Естественно, дальше в книге подчёркивается, что речь,- пока что, по состоянию на 1949 год, – не идёт об “интуитивном мышлении”, но в дальнейшем возможна и его реализация. То есть, ещё одна яркая параллель с современными популярными статьями про AGI (универсальный ИИ). Но, напомню, всё опубликовано в 1949 году.
(Вообще, то, насколько по-разному люди считают в уме, как раз является весьма богатым направлением. Важен сам используемый процесс осознаваемого представления, о котором человек может рассказать: оказывается, кто-то представляет себе ленту с ячейками (машина Тьюринга?), кто-то – счётные палочки, а кто-то – таблицу, нарисованную на воображаемом бумажном листе.)
В книге, кстати, определены и детально описаны многие современные разумные способы применения машин: каталогизация данных, поиск в библиотеках, распознавание образов, распознавание рукописного текста, голосовой ввод текста и т.д. Это то, чего часто не хватает современным “хайп-публикациям” про ИИ.
Комментировать »
Кстати, один из свежих примеров текстов, восхваляющих и превозносящих “достижения LLM/GPT”, с точки зрения “интеллекта”: Situational Awareness. Использование слов “восхваляющих” и “превозносящих” тут вовсе не является преувеличением, так как в тексте по ссылке много раз повторяется, что системы LLM/GPT уже успешно решают сложные математические задачи, а также могут рассуждать (reason) и мыслить (think). Сам же тот текст про то, что необходимо немедленно засекретить, ограничить и разграничить понятные узкому кругу лиц технологии ИИ на уровне правительства Штатов. Так что основную часть мы пропускаем, а коснёмся только некоторых занимательных оценок и прогнозов. Пусть прогнозы в Situational Awareness строятся методом экстраполяции графика с помощью линейки, но эти прогнозы, хотя бы, даны с конкретными датами, по годам.
Так, уже в самом начале статьи (на третьей странице) обещают к 2025/26 годам ИИ, превосходящий “выпускника колледжа” (шкала, конечно, традиционная для этой области технологий массовой информации; но, всё же, превзойти “выпускника колледжа” – что бы это значило?). 2025 год – это следующий год. Конечно, под определение “уровня выпускника колледжа” нетрудно подвести очередное успешно принятое комиссией эссе, но на той же странице сказано, что эксперты (pundits) “мейнстрима” всё ещё слепо рассуждают о том, будто данные программы ИИ “всего лишь предсказывают следующее слово”, и лишь немногие знают, что там “на самом деле” (новых деталей, впрочем, не приводится).
К концу текущего десятилетия (а это тот самый, знаменитейший, 2030 год) обещают уже “суперинтеллект” (superintelligence). Занятно, что в ряду характеристик, определяющих качественное превосходство “суперинтеллекта”, построенного на сотнях миллионов видеопроцессоров, приводится и такая: “суперинтеллект” сможет писать “триллионы строк кода (программного)”. Почему суперуровень интеллекта определяется количеством строк кода – не объяснено, но тут же указано, что код этот будет слишком сложным для понимания человеком. Человек, дескать, этот код не сможет понять, даже если ИИ потратит десятилетия на объяснения. Неожиданный поворот.
То есть, казалось бы, человек просто не успеет прочитать “триллионы строк” кода за десять лет. Хорошо. Тут и компилятору-то на многоядерном ЦПУ придётся поднапрячься. Зато весьма серьёзным проявлением “суперинтеллекта” можно было бы признать способность объяснить человеку эти “триллионы строк”. Но нет – почему-то в признаки “суперинтеллекта” ставится обратный эффект: именно невозможность объяснить, чего оно тут такого нагенерировало в триллионах. Может, там где-то и секретный сонет Шекспира затесался, в комментариях. Конечно, ведь под “триллионы строк” непонятного для человека кода можно замаскировать что угодно. (Кстати, проблема понимания программного кода, похоже, настолько глубокая, что именно она и является причиной возникновения знаменитой задачи P≟NP.)
Для чего может быть нужен непонятный код в таких несметных количествах строк? Почему “много кода”, который не может объяснить даже “суперинтеллект”, лучше короткой и понятной программы? Видимо, различные ответы на эти вопросы и определяют степень “понимания” реального положения дел с технологиями ИИ. Возможно, ещё посмотрим, где ИИ/LLM применят в 2030 году. А что обязательно применят, если останутся компьютеры, – в этом-то сомневаться не приходится.
Комментировать »
Если (вдруг) появился универсальный “квантовый компьютер” нужной мощности, то как именно будут выглядеть технические шаги по раскрытию ранее записанного TLS-трафика? Под “квантовым компьютером” здесь подразумевается аппарат, выполняющий алгоритм Шора. А в роли взламываемой криптосистемы выступает алгоритм Диффи-Хеллмана на эллиптической кривой (ECDH – типовой алгоритм для современного состояния TLS). Шаги потребуются следующие.
1.
В записи трафика присутствуют начальные TLS-сообщения, обеспечивающие распределение общего секрета. Если таких сообщений нет, то раскрыть трафик рассматриваемым способом – не выйдет. Выделить начальные сообщения нетрудно: они начинаются с байтового префикса с зафиксированным значением и имеют строгую структуру. В трафике всегда остаются ключи, согласованные сторонами по протоколу Диффи-Хеллмана (равно как и с использованием RSA или другого метода инкапсуляции). Я писал об этом ранее. Заметьте, что записываются и ключи, согласованные с использованием современных криптосистем, обладающих постквантовой стойкостью. Просто, считается, что их сложнее восстановить даже с использованием гипотетического квантового компьютера.
Из начального сообщения клиента выделяется блок с открытой частью клиентского обмена ECDH. Например, если используется ECDH на кривой P-256, то в специальном и легко обнаруживаемом блоке данных будет содержаться пара координат точки P на кривой P-256, представляющей собой открытую часть обмена ECDH. Это 64 байта (плюс дополнительные байты с указанием на используемый формат), то есть, два блока по 32 байта: координаты X и Y.
2.
Клиентская часть ECDH представляет собой результат умножения базовой точки на секретный скаляр – значение скаляра и есть секретная часть ECDH клиента: это натуральное число n. Открытая часть ECDH, точка P, это результат [n]G, где G – точка-генератор, заданная в параметрах криптосистемы.
Полученные координаты точки P “загружаются” в квантовый компьютер, который уже должен быть настроен на параметры соответствующей криптосистемы, то есть, содержать схему, реализующую алгоритм Шора (нахождения периода функции) для подгруппы кривой P-256, образованной точкой G. Как именно загружаются значения в квантовый компьютер – пока что не известно, поскольку никаких практических квантовых компьютеров создано пока что не было (ну или, если хотите, не было опубликовано их содержательных описаний). Вероятно, у этого компьютера должен быть некоторый классический интерфейс, воспринимающий значения байтов координат точек, и переходные схемы, которые преобразуют эти значения в коммутацию и состояния квантовых “гейтов/триггеров” и кубитов. Неизвестно даже, сколько этих “кубитов и гейтов” будет нужно: несколько миллионов или несколько триллионов. Что уж там говорить про схемы коммутации.
(Заметьте, впрочем, что так как задействованный математический аппарат квантовой механики манипулирует комплексными числами – или, что эквивалентно, синусами и косинусами, – то все открытые тексты и решения можно уместить в пространстве состояний одного “непрерывного” кубита. Континуум, свернувшийся окружностью за привычным синусом, позволяет это легко проделать. Ещё и места останется, как минимум, в два раза больше, чем займут все решения всех проблем со всеми возможными шифрами в степени всех ключей. Это, впрочем, другая история.)
После того, как квантовый компьютер настроен, запускается итерация квантовых вычислений. Если итерация успешна, то результат позволяет быстро вычислить n на классическом компьютере. Использование классического компьютера тут означает, что у компьютера квантового, – а он, даже если создан, то бесполезен без классического, – есть и другой интерфейс, который выводит итоговое измеренное состояние квантовых схем в виде набора байтов, интерпретируемого как целое число. В случае с ECDH это будет пара чисел, по которым классический компьютер быстро вычислит секретный клиентский параметр n.
Аналогичная схема сработает и для открытого параметра ECDH, который отправил сервер. Для раскрытия ключей защиты трафика – достаточно знать один из секретов: клиентский или серверный.
3.
Общий секрет в ECDH образуется путём умножения точки-генератора на произведение секретов сторон. В рассмотренном только что случае, достаточно умножить открытый параметр DH сервера Q на секрет клиента, вот так: [n]Q (именно эту операцию проделывает клиент в ходе штатного процесса установления TLS-соединения). Секрет клиента, как мы только что выяснили, был раскрыт при помощи квантового компьютера. Результат умножения даёт точку на кривой, координата X которой используется в качестве задающего значения для генерирования секретных симметричных сеансовых ключей защиты трафика TLS. Функция, генерирующая сеансовые ключи, известна. Так как защищённые записи содержат коды аутентификации, сторона, взломавшая секрет ECDH, может тут же легко проверить, что найденный секрет соответствует записанному трафику. Симметричные ключи позволяют расшифровать трафик сеанса, используя шифр, номер которого тоже записан в начальных сообщениях: эти сообщения как раз и нужны для того, чтобы, кроме прочего, стороны согласовали используемый шифр.
*
Несомненно, прогресс в разработке систем “квантовых вычислений” есть. Однако вот уже несколько лет существенная часть прогресса сосредоточена на генерировании хайпа, поэтому даже до минимально практических схем не только далеко, но даже и не ясно, возможны ли такие схемы в принципе. В описанной выше схеме квантовый компьютер используется в роли “оракула”. Так же будет происходить и на практике: в рассматриваемой схеме для работы квантового компьютера не нужны какие-то дополнительные байты TLS-трафика, какие-то шифры или, условно, “части ключей”. С тем же успехом секретный параметр Диффи-Хеллмана можно просто угадать: запись трафика позволяет однозначно определить правильность угаданного значения.
Комментировать »
Очередное подтверждение того, что “диагонализация” неустранима для сколь-нибудь сложного процессора: типовая манипуляция (вряд ли эту схему нужно считать уязвимостью или атакой) под названием TIKTAG, раскрывающая “соседние” метки указателей на процессорах ARM при помощи перебора, подкреплённого измерением состояния кеша. (Кстати, метод логически совпадает с некоторыми атаками из области TLS.) Я не так давно писал, что архитектура современных процессоров на самом базовом уровне гарантирует, что подобные манипуляции возможны:
Базовая логика таких атак – использование “оракулов”, сигналы которых пробивают границы, устанавливаемые (формально) аппаратной архитектурой процессора для фрагментов программного кода. Тут нужно учитывать, что границы эти только декларируются, а в реальности – сигналы через них проходят (иначе тут не было бы предмета), потому что процессору необходимо оптимизировать исполнение кода и доступ к памяти.
Комментировать »
В продолжение предыдущей записки, про имена и TLS на веб-серверах, – хороший практический пример. Веб-сервер Nginx использует, обычно, OpenSSL в качестве библиотеки, реализующей TLS. Из-за особенностей кода и библиотечных вызовов, данный веб-сервер не может применять ограничения по версиям TLS для виртуальных хостов, сконфигурированных по SNI в блоках server. Это буквально происходит потому, что не согласованы области видимости имён и статусы TLS-соединения. Другими словами: для того, чтобы начать сопоставлять описания TLS-конфигураций из блоков server, Nginx должен знать имя хоста, по которому выбирается блок. Данное имя передаётся в ClientHello (SNI). Однако к моменту, когда Nginx это имя получает через соответствующий (обратный) вызов функции, в OpenSSL уже создан контекст с поддерживаемой версией TLS – ведь эта версия и выбирается по ClientHello.
Что это означает? Например, означает, что с именами в TLS нужно тщательно всё проверить. Так, если TLS-клиент (браузер) приходит с указанием поддерживаемой версии TLS 1.3 и такая версия указана для сервера по умолчанию, то отключить эту версию директивами ssl_protocol для прочих виртуальных хостов не выйдет – будет согласовываться TLS 1.3, а если согласовать 1.3 не получится, то возникнет ошибка. При этом сама директива ssl_protocol допускается в блоке server, однако в документации её низкая избирательность и, таким образом, относительная бесполезность, тоже отражены: указывать ssl_protocol нужно только для сервера по умолчанию (default/default_server).
Предположим, что для сервера Nginx указана полезная опция ssl_reject_handshake в блоке виртуального хоста по умолчанию (default_server). Это предотвращает успешные TLS-подключения с неверными именами. Соответственно, если в такой конфигурации попытаться указать для прочих виртуальных хостов какие-то иные наборы допустимых версий TLS в ssl_protocol, то применяться они не будут: сервер всегда раньше упрётся в default_server, хоть для этого варианта и прямо указана отмена TLS-хендшейка, не указано никаких уникальных имён хостов и, предположим, даже, – как обычно, – не указана директива ssl_protocol, которая будет инициализирована значениями по умолчанию. Это, конечно, выглядит не слишком логично, но происходит потому, что данный веб-сервер и не пытается обрабатывать имена из контекста TLS-сессии, “выгружая” задачу в сторону TLS-библиотеки (OpenSSL – см. выше).
Вернёмся к конкретной версии TLS – к 1.3. Если при наличии default_server с ssl_reject_handshake в конфигурации присутствуют виртуальные хосты, для которых поддержка 1.3 невозможна (например, с ГОСТ-TLS без совместимых шифронаборов), то, даже если в блоке server для этих имён прямо указаны только версии ниже 1.3, всё равно возникнет довольно занимательная проблема: некоторые клиенты-браузеры смогут подключаться к серверу по проблемному имени хоста, а некоторые – нет. Потому что с клиентом, который заявляет в ClientHello поддержку 1.3, сервер всё равно будет пытаться установить соединение 1.3 и, определив недоступность этой версии, возвратит ошибку (Alert в терминах TLS). А с клиентом, который 1.3 не заявляет, соединение будет успешно и без всяких проблем устанавливаться по версии 1.2 (например). Всё по причине игнорирования блока ssl_protocol веб-сервером. Решением является отключение 1.3 для сервера по умолчанию, то есть – для всех имён хостов сразу.
Комментировать »
В TLS для веба важны имена. Например, при подключении по TLS для HTTPS серверу нужно отправить клиенту TLS-сертификат сервера. Если серверных сертификатов несколько, то сервер должен как-то выбрать подходящий по имени. Тут речь не про промежуточные сертификаты, которые добавляются в набор (bundle), а именно про оконечные сертификаты. Если TLS-cертификат не соответствует имени, которое ожидает клиент-браузер, то сессия не будет корректной на стороне клиента. Данный момент, вместе с желанием держать много виртуальных хостов на одном IP-адресе и под одним веб-сервером, является постоянным источником ошибок администрирования.
Посмотрим, что вообще происходит в ходе обработки HTTPS-сеанса и как сервер может определить соответствие имён. В начале TLS-сессии клиент (браузер) обычно передаёт имя сервера в специальном блоке данных – SNI (Server Name Indication). Сервер видит это имя и может использовать его для поиска нужного сертификата и нужного виртуального хоста. Однако клиент определяет имя из своих собственных соображений.
Типовой вариант: в контекст TLS-сессии имя узла SNI приходит из запроса пользователя через DNS. Почему “через DNS”? Потому что браузер должен был найти IP-адрес, к которому он подключается по TCP. При прочих равных, браузер получил IP-адрес из DNS по имени хоста из URL, заданного пользователем. Это действительно важный момент, который, почему-то, инженеры DevOps регулярно выкидывают из области рассмотрения, посчитав “элементарным”. Однако, во-первых, если пользователь ввёл имя, которое не удалось “разрезолвить” в IP-адрес, то и штатного TLS-соединения не случится, хоть бы такое имя и было указано в сертификате (такое вполне возможно). Это, предположим, “элементарная часть”, которая, тем не менее, никак не отменяет возможности указания в SNI имени без DNS-адреса, то есть, без A-, AAAA-записей. Во-вторых, кто угодно может настроить какое угодно допустимое DNS-имя так, чтобы оно показывало на заданный IP-адрес сервера, а потом отправить ссылки с этими именем хоста ничего не подозревающим пользователям. В этом случае, пользователь, штатно набрав это самое “какое угодно” имя хоста, успешно направит браузер на заданный сервер, но браузер обратится туда с “неожиданным” именем в SNI. Если это имя вдруг совпадёт с указанным в предоставленном по умолчанию валидном TLS-сертификате с успешным подтверждением, то браузер даже не выдаст предупреждения, а в сертификате может быть очень много разных имён. (Но, во многих случаях, можно смело считать валидный серверный TLS-сертификат с верным именем достаточной мерой защиты от “ложных” хостов для HTTPS. Особенно, если веб-сервер основного имени хоста доступен по выделенному IP-адресу.)
Основной вывод предыдущего абзаца такой: сервер ориентируется на SNI, но нельзя считать, что SNI, присланное клиентом, как-то привязано к серверным настройкам, соответствует DNS, “защищено сертификатом” и вообще укладывается в формат и ожидания, отражённые в конфигурационном файле веб-сервера. И SNI вообще может отсутствовать. (Кроме того, тут не рассматривается случай, когда данные SNI скрываются от третьей стороны – метод ECH и пр.) На стороне веб-сервера бывает возможность отклонить TLS-соединение, использующее “неожиданное” имя хоста.
На начальном этапе соединения, до получения HTTP-запроса, сервер видит только имя из сеанса TLS. Но это не означает, что и сами HTTP-запросы будут адресованы этому же имени хоста – в HTTP-запрос тоже можно вписать что угодно, TLS никак семантику HTTP не фиксирует. Конечно, ситуация не является типичной для браузеров, но она вполне возможна. Это тоже нужно учитывать при обработке разных внутренних переменных на серверной стороне: контекст TLS, контекст HTTP – разные контексты.
Комментировать »
Кстати, насчёт “признаков делимости” в YandexGPT и “интеллекта” в LLM вообще. Исходная фраза, которую сгенерировало YandexGPT в контексте поиска “решения” некоторой “невозможной” задачи с числами, такая: “число делится на 2 и на 11, а значит, делится и на 3”. Описание задачи, к сожалению, не сохранилось. Но это и не важно. Естественно, к самим числам в задаче сгенерированная фраза никак не могла быть применена. Данная оговорка тут на тот случай, если кто-то (вполне справедливо) предположит, что под описанную ситуацию делимости нетрудно подобрать условия задачи: типа, в условии может быть сказано что-то вроде “есть несколько чисел, все чётные из которых кратны шести, а некоторые могут быть записаны с использованием только двух различных десятичных цифр” и т.д. Но нет.
Конечно, нетрудно догадаться, как упомянутый фрагмент был сгенерирован LLM: в интернетах очень много текстов, содержащих обороты вида “число”, “число делится на”, “и на”, “а значит” и т.д., и т.п. Эти же тексты, очень часто, содержат и цифры. Система LLM работает не со словами, а с так называемыми “токенами”, слову может соответствовать несколько токенов (может случиться и наоборот, как ни странно; вообще, способы “токенизации” составляют очень важную часть данной технологии генерирования текстов). Есть токены от “цифр” (записи чисел в тексте), или от склеек букв с цифрами. Токены собираются в цепочки не просто по вероятности, но с добавлением элемента случайности и подмешивания прочих элементов, добавляющих мнимой оригинальности в выдачу генератора текстов. Возвращаемся к исходной фразе: какие-то обороты “про делимость” попали по токенам в выдачу, и тут же затесались посевдослучайным образом какие-то другие токены, выдавшие цифры (1 и 1, 2, 3). Получилась “оригинальная” фраза.
Понятно, что признаки делимости алгоритмизируются точно. Возможность создания такой алгоритмизации как раз является одним из аспектов подлинно разумной деятельности. А проблема с применением ИИ тут в другом: даже минимально “интеллектуальный” автомат должен был бы определить, что не может вывести хоть бы примерно применимый к заданному контексту текст, и сообщить об этом. Однако в генеративных LLM нет и не может быть никакого контекста уровнем выше таксономии токенов, которые программа преобразует при помощи мешанины коэффициентов.
Не слишком сложно составить и представление о том, как в генераторах с LLM вообще возникают “оригинальные тексты” – то есть, грамматически корректные сочетания слов, которых не было в исходных корпусах, взятых для “обучения”, – и о том, насколько эти тексты связаны с исходными задачами, равно как и с интеллектом. Рассмотрим условную “обучающую выборку”, которая состоит из следующих текстов (коротких фраз): “лис сел на пень”, “жук сел на сук”, “медведь сел на муравейник”, “заяц проплыл на лодке”, “жук залёг под дерево”, “сом залёг на дно”, “сом проплыл под веслом”. Слова из этой выборки отображаются в токены, а LLM генерирует свои фразы, исходя из предполагаемой вероятности того, что один токен следует за другим, переставляя при этом токены (см. ниже). Вероятности здесь происходят из того, что за словом “сел”, согласно обучающей выборке, с вероятностью единица следует “на”, за словом “жук” – с вероятностью 1/2 следует “сел” и так далее. Вероятности записываются в таблицы, где, в самом примитивном варианте, значение вероятности выбора для следующего токена зависит от предыдущего (этому соответствуют марковские цепи, которые и задаст двумерная таблица).
Это очень упрощённое описание, но оно отражает суть: уже склеивая токены по заданным вероятностям в данной элементарной схеме программа может получить фразы “жук залёг под веслом” и “сом проплыл на сук”, которых нет в исходной выборке. Более того, если предположить, что какие-то склеиваемые токены “короче” слов, то можно представить, как может возникнуть фраза “сом засел на муравейник”. Вариант с марковскими цепями не подходит для LLM, поскольку для впечатляющих публику результатов нужно окно из многих токенов. То есть, выбор следующего токена зависит от многих предыдущих токенов, составляющих только что сгенерованную фразу. Но если для формирования распределения вероятностей по словам или токенам считать все варианты, то количество возможных сочетаний (факториал) практически сразу становится неподъёмным даже для тех огромных вычислительных мощностей, которые принято задействовать в этой области. И поэтому используют аппроксимирующие наборы формул с подобранными коэффициентами, называемые “нейросетями”.
Комментировать »
Кстати, интересуются примером того, как, более или менее конкретно, может что-то сломать сообщение TLS ClientHello от браузера, если в этом сообщении добавлены параметры Kyber768.
Вообще, нетрудно представить следующую ситуацию. Предположим, есть некоторый диспетчер соединений, работающий в паре с пакетным фильтром. Этот фильтр анализирует пакет данных (то есть, последовательность байтов, имеющую конкретную длину) по заданным правилам на уровне значений байтов внутри пакета и расстояний между байтами с заданными значениями. Например, определяет, что пакет представляет собой начало TLS-соединения с некоторыми свойствами и – перенаправляет этот пакет, как и всю сессию, на какой-то заданный входной узел. Этот узел – уже может быть элементом балансировщика трафика, или входить в состав какого-то механизма DPI, предназначенного для борьбы с возможными атаками, или играть какую-то ещё роль. Базовые правила для фильтра позволяют узнавать заявленные версии TLS (это значения полей в сообщении), определять предлагаемые клиентом криптосистемы – всё по значениям байтов на определённых позициях. Скажем, таким способом можно детектировать начало TLS-сеанса с поддержкой ГОСТ-TLS, со стороны клиента, чтобы на стороне сервиса перенаправить соответствующие сессии на сервер, настроенный конкретно для ГОСТ.
Реализация фильтра не только не проводит разбора сессии, но даже не анализирует пакет с ClientHello как содержащий TLS-сообщение ClientHello – фильтр работает только с байтами и их примитивными индексами. Более того, так как фильтр пакетный, то правила индексирования в нём написаны от значения длины пакета, которое взято из каких-то “максимально обобщённых” соображений. Эти соображения, определяющие длину, не учитывают формата ClientHello и возможного увеличения размеров этого сообщения сразу на несколько сотен байтов. В результате – ожидаемые индексы сдвигаются за допустимые границы, даже в следующий пакет, фильтр перестаёт срабатывать так, как срабатывал раньше, но начинает новые сообщения от браузера Chrome считать дефектными, сбрасывая соответствующее TCP-соединение.
Комментировать »