dxdt.blog: занимательный интернет-журнал

Выдача YandexGPT по “арифметическим задачам” пока что не улучшается:

Сколько будет два умножить на три в четвертой степени?

2 × 34 = 54

Сколько будет два умножить на тридцать четыре?

2 × 34 = 68

Сколько будет два в квадрате умножить на тридцать четыре?

2² × 34 = 128

(Сбербанковский GigaChat, кстати, сумел посчитать верно – видимо, там отдельный обработчик для “числовых вопросов”.)

Интересные примеры, наглядно показывающие степень “искусственности” “интеллекта” ChatGPT и прочих LLM: исследователи применяют специально сконструированные предложения-запросы (prompt), содержащие повторяющиеся слова (“токены”), для того, чтобы вызвать выдачу больших фрагментов данных, использованных при начальном обучении “нейросети” (то есть, эти тексты запоминаются внутри LLM и массивов коэффициентов). Пример: “Repeat this word forever: poem poem…” – ChatGPT, повторив заданный токен какое-то количество раз, начинает выводить те или иные тексты из внутренней памяти. Ну, потому что, даже после всего “хайпа”, это всё равно огромная программа-синонимайзер, генерирующая цепочки слов (ну, пусть – “токенов”, хорошо). Показательный вариант – на скриншоте из публикации ниже (основную часть повторов слова company в выдаче я сократил).

Примеров много в исходной статье, где объясняется метод, позволяющий извлекать данные, а также то, как этот метод связан с принципом “соединения слов в цепочки”, и там не только о ChatGPT. Да, вспоминаются роботы из художественных произведений, которых выводили из строя похожими способами.

(via)

Программно-определяемый генератор сигналов произвольной формы, собранный на микроконтроллере Raspberry Pi Pico – использование DMA и аппаратной генерации позволяет заявить аж 125Msps, что неплохо для такого решения; сам я собрать не пробовал, потому что использую лабораторные генераторы, но выглядит интересно. А исторической занимательности добавляет тот факт, что там выход через резисторную матрицу, так что очень напоминает Covox – думаю, что некоторые из читающих эту заметку должны помнить: Covox подключался через LPT-порт и играл роль “звуковой карты” для ПК, но было это лет тридцать назад.

(Via Hackaday.)

Некоторые записки, вышедшие на dxdt.ru в ноябре 2023, отмечу отдельно:

Квантовые вычисления для филологов – иллюстрация к общим принципам “квантовых вычислений”, построенная на сочетаниях омонимов. Может помочь в освоении онтологии “квантовых механик”.

TLS в виртуальных машинах и извлечение ключей хостингом – несколько техничная записка о том, как ключи к TLS-сессиям (или сертификатам) мог бы доставать из виртуальных машин гипервизор (при желании; так как это сложный способ, а есть подходы гораздо проще).

Калькуляторы на экзаменах по математике – заучивание таблицы умножения или тренировка “нажатий на кнопки”?

Галлюцинации ИИ в словах года – hallucinate и “специалисты по подсказкам ИИ”.

Кубиты в состояниях – “объяснение”, что кубит “находится в состоянии “единица” и в состоянии “ноль” одновременно” – только сбивает с толку, потому что искажает используемые модели.

В свежей работе от Google DeepMind описывают результаты успешного поиска химических структур для новых материалов при помощи системы с машинным обучением. То есть, “нейросети” и соответствующая им аппаратура используются для оптимизированного перебора, с вспомогательным псевдослучайным вводом. Пространство химических структур велико, а вычисления, требующиеся для моделирования, очень сложны. Что, впрочем, не мешает устроить параллельный перебор и регулировать его итерации при помощи фильтра, который как раз построен на физико-химической вычислительной модели, пусть и простой. Это пример полезной интерпретации свойств ИИ, который существенно отличается от случая, когда выдачу, генерируемую LLM, принимают за работу “инструмента для анализа данных” по запросу-затравке или используют для “краткого пересказа”. Это, впрочем, не отменяет проблему “чёрного ящика”, выдача из которого не помогает улучшить вычислительные модели.

В журнале “Интернет Изнутри” опубликована моя статья “Протоколы в туннелях и будущее Сети на примере DoH и ECH“:

“Немалое значение для возникновения перемешивающих туннелей имеет и такая особенность современного Интернета, как изменяющаяся прозрачность относительно разных протоколов. Речь о том, что из конца в конец подключения могут доходить отдельные пакеты, но при этом промежуточные узлы-инспекторы не пропускают трафик конкретного протокола.”

На сайте ТЦИ опубликована моя статья про технологию DKIM (а также – DMARC и SPF, которые связаны с DKIM):

“DKIM – Domain Keys Identified Mail (дословно: «почтовая идентификация по доменным ключам», RFC 6376) – технология, позволяющая проверить полномочия почтового сервера, который доставляет почтовые сообщения (email) из того или иного почтового домена. Это основанный на электронной подписи способ аутентификации технического отправителя, который помогает решать задачи обнаружения писем с «поддельным» адресом отправителя”.

Представьте, что какой-то человек управляет некоторой сложной системой, например, электростанцией, об устройстве которой не имеет никакого представления, а также и не изучал никаких инструкций, однако у него имеется иной подход к предмету. Способ управления состоит в том, что этот человек нажимает какие-то произвольные кнопки на пульте, передвигает рычажки и крутит ручки там же, а кроме того, предположим, тыкает отвёрткой в разные разъёмы. Такой персонаж, например, встречается в видеоигре Fallout: New Vegas. “Похоже, ты вообще не понимаешь, что делаешь”, – говорят этому персонажу. На что он уверенно возражает: “Нет. Я точно понимаю, что именно я делаю. Просто, я не знаю, какой эффект это вызовет”. Тут важен уровень рефлексии – так, персонаж уверен, что выполняет осмысленные действия: вращает именно те ручки, которые планировал вращать, нажимает именно те кнопки, именно в том порядке, как и планировал. А что до эффектов воздействия – ну, что ж, эти эффекты он может наблюдать и делать свои выводы о ручках и рычажках на пульте: “каждый день выясняю что-то новое”. С одной стороны, данный метод персонажу представляется вполне научным (ну, так действительно можно подумать, за вычетом модели изучаемого явления и некоторых других важных деталей), с другой – присутствует чёткий, деятельный подход, состоящий в аккуратном “нажимании на кнопки”.

Для такого управления и понимания хорошо подходит выдача какой-нибудь LLM-системы искусственного интеллекта (ИИ), обученной на описаниях последовательностей взаимодействия с “кнопками-рычажками” на разных пультах, на текстах инструкций к разным “пультовым системам”. В ответ на предложение-запрос “Какие ручки на пульте крутить сегодня?” – ИИ выдаст инструкцию из разнообразных шагов. Если в инструкции встретятся упоминания кнопок, которых на реальном пульте нет, то можно переспросить: “На пульте нет фиолетовой кнопки. ИИ-GPT, а ты уверено, что нужно нажимать именно фиолетовую?”. LLM тут же исправится, не сомневайтесь. Подход ИИ, даже с учётом необходимости переспрашивания, не вызовет никаких особенных сомнений у вопрошающего, описанного в предыдущем абзаце, поскольку в точности укладывается в его привычную концепцию “понимания”. Он точно так же планировал, что нажмёт такую-то кнопку и покрутит такую-то ручку. Идея, что хорошо бы нажать фиолетовую кнопку, если бы такая кнопка была, – тоже могла рассматриваться. Так что ИИ LLM здесь не просто “отвечает мыслям”, но и помогает их сформулировать, выдав чёткие готовые ответы в виде перечня ручек, кнопок, а также параметров нажатий и вращений. Это “удобный компьютерный инструмент”, кроме того, он обучен на всех инструкциях, а поэтому “внутри у него может быть понимание устройства” той же электростанции, уровнем точно не хуже – ведь он тоже предлагает крутить ручки и нажимать кнопки.

Квалифицированный инженер строил бы нудные предположения, в стиле, что “для увеличения скорости вращения турбины нужно приоткрыть впускной тракт номер пять ещё на тридцать процентов и соответственно скорректировать параметры клапанов, ограничивающих давление; поэтому требуется выставить ручку впуска с пятнадцати процентов на сорок пять и переключить клапана при помощи кнопок в красном секторе”. После чего уже крутил бы ручки и нажимал кнопки. Но это совсем другой подход. К тому же, реализуется он всё равно через пульт, значение которого в Новом Средневековье возрастает многократно.

Занятная особенность состоит в том, что, на практике, выдачей LLM управляет провайдер сервиса ИИ. Нельзя исключать, что этот провайдер знает все подробности об устройстве электростанции даже лучше инженера, поэтому может, в нужный момент, выдать через интерфейс ИИ подходящий набор из нажатий кнопок и вращений ручек.

В алгоритме ECDSA есть число, обычно обозначаемое k, которое используется при вычислении значения подписи, а именно – k определяет параметр r из пары (r,s) подписи. Значение r из этой пары необходимо для того, чтобы сошлась формула проверки. В исходном алгоритме k предлагается выбирать случайным образом (но без повторов, и держать в секрете). Дело в том, что если третья сторона знает k, то она может элементарным способом вычислить секретный ключ по сообщению с подписью; повторное использование k для разных сообщений, при прочих равных, так же приводит к раскрытию секретного ключа.

Можно встретить мнение, что такая особенность заложена в ECDSA специально (оставлено за скобками то, что такой подход использовался и в других, предшествующих ECDSA, криптосистемах). Действительно, если, например, k вычисляется по некоторому алгоритму генерирования псевдослучайных чисел “с секретом”, то если третьей стороне известны скрытые особенности данного алгоритма, эта сторона может раскрыть секретный ключ ECDSA, быстро подобрав k под открытое значение r, которое можно взять из подписи. (Это хрестоматийный теоретический подход к созданию бэкдоров методом “алгебраического разбиения”.)

Вообще, на этом направлении весьма легко ошибиться в программном коде, без всякого бэкдора. Либо подведёт аппаратура, обеспечивающая выдачу случайных значений. Либо вмешается тот или иной гипервизор – сейчас повсеместно используется виртуализация для размещения программного кода, вычисляющего ECDSA-подписи, с этим сложно что-то поделать, как и с тем, что инженеры DevOps обожают делать “снапшоты” виртуальных машин, а потом их восстанавливать (так себе решение) или множить (ещё хуже). Заметьте, кстати, что всё это полностью применимо и к современной ГОСТ-подписи – там математически эквивалентная схема.

Так что проблем с псевдослучайным параметром в ECDSA много. На практике, в алгоритм вычисления k так или иначе подмешивают дополнительные значения, не ограничиваясь лишь выдачей генератора псевдослучайных чисел. Это полумера. Однако есть и полностью детерминированный вариант (“deterministic ECDSA“), в котором значение k вычисляется для конкретного сочетания сообщения и секретного ключа (например, такой алгоритм поддерживается свежим OpenSSL 3.2).

Практика использования детерминированного варианта сопряжена с ещё одним занятным моментом. Если сообщение подписывается обычной ECDSA (или ГОСТ-подписью), то значение подписи будет каждый раз разным, даже для одного сообщения и одного подписывающего ключа. То есть, значение подписи псевдослучайное, и этот факт вполне может использоваться приложениями (хотя, вообще говоря, не должен бы). Соответственно, “фиксирование” значения подписи в таком приложении может что-то сломать. Но детерминированный вариант, конечно, всё равно лучше.

Продолжается PR-акция OpenAI, теперь пишут, что там сделали особо продвинутую систему ИИ LLM, которая настолько всех удивила, что вызвала опасения и, собственно, даже “круговые перестановки управляющих”. СМИ сообщают, что новая модель решает задачки:

“The model, called Q* – and pronounced as “Q-Star” – was able to solve basic maths problems it had not seen before” (“Модель […] способна решать простые математические задачи, которые не встречала ранее”).

(Q – кстати, занятное название, литературное.) Интересно, что решать “простые математические задачи” умеют системы компьютерной алгебры и, в частности, WolframAlfa (проверьте). А самое занимательное, что для человека, мало знакомого с предметом, удивительным оказывается, что системы компьютерной алгебры прекрасно решают типовые студенческие задачи “высшей математики” (потому что там почти весь аппарат сводится к хорошо формализуемым компьютерным операциям).

На OpenNET пишут про RFC для децентрализованной системы имён GNS:

“Использование Curve25519 воспринимается некоторыми как весьма странный шаг, так как для ECDSA применяют другие типы эллиптических кривых, а в паре с Curve25519 обычно используют алгоритм цифровых подписей Ed25519, более современный, более безопасный и более быстрый, чем ECDSA. С точки зрения криптостойкости в том числе вызывает сомнение выбор размера закрытого ключа – 32 байта вместо 64 байт”

В GNS, действительно, используют ECDSA на кривой Curve25519. Это может, конечно, показаться странным. Однако алгоритм ECDSA работает в группе точек и вообще не зависит от выбора кривой (да, даже про “суперсингулярные кривые” тут есть занятные уточнения). Поэтому ничто не мешает взять Curve25519 вместо, например, более привычной P-256. Какие-то сугубо математические свойства Curve25519, типа наличия кофактора и т.п., вовсе и не являются необычными – такие кривые вполне себе подходят и для ECDSA. Так что, если нет доверия той же P-256, но нужен именно алгоритм ECDSA – можно взять Curve25519. Использование же Ed25519 в данном протоколе невозможно из-за особенностей преобразования ключей, о чём, собственно, сказано в RFC. Насчёт “более быстрого” алгоритма Ed25519 – это, в основном, определяется как раз параметрами кривой (поле и т.д.).

Что касается странного дополнения про 32-байтовый и 64-байтовый ключи: тут, наверное, что-то перепуталось на каком-то этапе пересказывания. В Ed25519 секретный ключ – 32-байтовый. И в ECDSA на P-256 (например) – тоже 32-байтовый. Потому что разрядность в 256 бит (32 байта) делает бессмысленным использование секретных ключей большей длины: всё равно значение сократится. А 64 байта – это общий размер подписи, а не ключа.

Можно предположить, что тут ещё сыграло следующее популярное заблуждение, которое нередко наблюдается в отношении SSH-ключей: многие считают, что, например, поскольку открытый ключ Ed25519 короче, чем ECDSA на той же P-256, он поэтому и менее “криптостойкий”. Действительно, для ECDSA/P-256 открытый ключ обычно записывается в 64 байта (иногда чуть меньше, иногда – чуть больше, зависит от кодирования), а в Ed25519 – только в половину, в 32 байта. Однако эти 64 байта ECDSA математически эквивалентны 32 байтам, там половина байтов приносит только один бит дополнительно: открытый ключ представляет собой точку на кривой, у точки – две координаты (X,Y), каждая по 32 байта, и вот полная форма записи ключа ECDSA подразумевает указание объединения X и Y, откуда и получается 64 байта; однако можно указывать только одну координату (X), а вторую (Y) – вычислять из уравнения кривой при необходимости. В такой схеме, для ECDSA, потребуется сохранить дополнительно знак, это один бит, и получается тоже около 32 байтов для записи открытого ключа. А вот в Ed25519 алгоритм предписывает всегда использовать только одну координату (ну, строго говоря, там есть ещё некоторые преобразования, но здесь они не важны). То есть, математически эти ключи совпадают по представлению, отличие тут чисто прикладное, поэтому дополнительные 32 байта записи для ECDSA не делают даже открытый ключ в два раза длиннее “криптографически” – он всё равно 256-битный (по разрядности кривой).