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

Забавное развитие темы столкновения коммерческих синонимайзеров LLM, традиционно называемых “искусственным интеллектом”, с не менее коммерческим “копирайтом”: сообщают, что OpenAI, на примере лидера направления – ChatGPT, – указывает на “невозможность создания полезных LLM без использования материалов, защищённых авторским правом” (как, например, скачивание всех статей NY Times).

Естественно, упор в возражениях делается на “всеобъемлющий копирайт” – мол, поскольку всё кругом защищено, то ChatGPT ничего нельзя использовать, и поэтому “интеллект” не работает. И тут даже не важно, что силами “копирайта” читать статьи запрещают не везде (часто, впрочем, запреты относятся к научным статьям, что ситуацию не красит), вообще можно отвлечься от того, что современный “копирайт” далёк от идеала. Забавно вот что: с одной стороны, как бы, создаётся “невиданный независимый ИИ”, да такой мощный, что даже угрожает человечеству, а с другой – это ИИ, оказывается, совсем не действует без копирования и пересказывания свежих газетных статей, и, как говорится, базируется на “картинках, найденных в интернетах” (что, конечно, гораздо ближе к реальному положению дел).

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

То, что секретные ключи переданы при помощи “квантового канала”, даже не означает, что и для защиты передаваемых данных применяется абсолютно стойкий шифр: такой метод, конечно, необходим для обеспечения максимальной стойкости, но эффективный вариант всё равно использует обычный симметричный шифр. Заметьте, что квантовая криптография требует аутентификации сторон канала “классическими” методами, иначе теряется смысл. Более того, так как речь исключительно о технической защите, то оценку защищённости нельзя смешивать с криптографической стойкостью (хоть в названии и использовано слово “криптография”): примерно так же, как нельзя оценивать защищённость помещения только и исключительно по количеству возможных комбинаций механического дверного замка.

Несколько неожиданно, что пассажирский самолёт Boeing 737, у которого вчера на высоте почти пять тысяч метров вылетела фюзеляжная панель вместе с иллюминатором (и “дверью”), это, оказывается, совсем новый 737 Max 9, который только два месяца назад был выпущен, если верить статье The Guardian (по ссылке есть небольшое видео).

Переписал обработку TLS-записей экспериментальным сервером TLS 1.3, так как обнаружил, что сервер иногда ошибочно закрывает TCP-соединение раньше времени; проявлялось это, например, в том, что браузеру Chrome приходилось повторно подключаться, но именно из-за того, как обрабатывался TCP-сокет, а не уровень TLS.

Посмотрим, насколько хорошо удастся “исследовать” вопросы из записки про “шампанское и хлопок” при помощи GigaChat (через бота в Telegram). Результат, конечно, получше, чем у YandexGPT из прошлой записки по теме, однако с уровнем “интеллекта” – проблемы:

Намного ли прочнее обычного хлопок от шампанского?
GigaChat:
Шампанское — это игристое вино, которое обычно изготавливается из трех сортов винограда: шардоне, пино нуар и пино менье. Оно имеет высокую кислотность и низкую концентрацию сахара, что делает его более прочным, чем обычный хлопок. Однако, прочность шампанского зависит от многих факторов, включая его состав, способ производства и хранения. Поэтому, если вы хотите узнать, насколько прочно конкретное шампанское, лучше всего обратиться к производителю или специалисту в этой области.

Насколько громче обычного хлопок от шампанского?
GigaChat:
Шампанское обычно имеет более высокий уровень звукопроницаемости, чем обычный хлопок. Это связано с тем, что шампанское содержит больше пузырьков, которые создают больше шума при открытии бутылки. Однако, громкость звука также зависит от многих других факторов, таких как размер и форма бутылки, способ ее открытия и окружающая среда. Поэтому, если вы хотите узнать, насколько громко будет звучать конкретная бутылка шампанского, лучше всего обратиться к производителю или специалисту в этой области.

Так что, если вы не знали, обратите внимание: “высокая кислотность и низкая концентрация сахара” – вот что делает шампанское более прочным, чем обычный хлопок.

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

На сайте про “прямое подключение” смартфона через спутники Starlink пока что обещают доставку текстовых сообщений (почти что старый Twitter), да и то – в конце 2024 года. И только когда-то потом, после 2025, судя по всему, планируют предоставлять доступ с передачей данных и голосовую связь (что в LTE примерно одно и то же). При этом, понятно, сразу есть куча оговорок про совместимость и доступность. Сейчас, естественно, доступ заявлен только для конкретных операторов, ни о каком там “универсальном глобальном интернет-доступе” речи не идёт. Понятно, что к концу 2025 многое может измениться: и смартфоны могут обновиться, и срок предоставления услуг могут сдвинуть, и условия могут стать другими, например, решение будет доступно только для смартфонов с совместимой прошивкой/радиомодулем. (Само собой, это всё лишь в том случае, если после окончания 2024 года вообще сохранится какой-то интерес к подобным технологиям и спутниками будет возможно управлять. Впрочем, с другой стороны, технология эта – многообещающая, хоть и не совсем в том ключе, как обычно рассказывают, так что велики шансы на дальнейшее продвижение.)

Ссылки по теме: Starlink и взаимодействие с наземными GSM-сетями; Геопривязка в персональных цифровых финансах.

Добавил arm64 в свою реализацию шифра “Кузнечик” (ГОСТ Р 34.12-2015) на ассемблере для Go. Новые функции – для платформы arm64 со 128-битной арифметикой. Попутно немного изменил состав библиотеки, так что название теперь новое (см. исходники ниже). Раньше ассемблер был только для amd64 с AVX, на остальных платформах – компилировалось с “заглушкой”, в которой операции шифра реализованы просто на конструкциях Go – ассемблер, понятно, быстрее.

ARM – весьма и весьма распространённая архитектура, а использование ассемблера, как обычно, даёт прирост производительности во много раз, если сравнивать с “обычным” Go-шным вариантом (тоже оптимизированным, конечно). Однако я всё проверял на Raspberry Pi4 (RPi4), потому что другого варианта ARM-аппаратуры под рукой сейчас не оказалось (а техники Apple у меня вообще нет). Зато на Linux/arm64 в RPi4 – прирост более чем в двадцать раз. Было: примерно мегабайт в секунду для “обычной” реализации. Стало: около 23 мегабайтов в секунду для ассемблерной. Думаю, что должно работать и на других ARM-платформах, и гораздо быстрее, чем на RPi4, но пока не проверял: если кто-то использует, и обнаружит существенные несовместимости (см. ниже) – пишите, пожалуйста, в комментарии здесь или пишите почтой. Вообще, написанный ARM-код ещё есть куда оптимизировать: например, в arm64 имеется “векторная” инструкция, реализующая XOR сразу для трёх входных регистров, что тут очень полезно, но эта инструкция недоступна в процессоре RPi4 (Cortex-A72/BCM2711).

Новая версия кода “Кузнечика”, так как отличается от предыдущей, называется GOSThp. Исходный код публикую ниже. Возможно, потом оформлю в виде полноценного модуля для Golang и выложу копию на Github, а возможно – не оформлю и не выложу. Но использовать в составе проекта на Go этот пакет нетрудно: достаточно скопировать директорию gosthp (см. ещё детали ниже). Работает со старыми версиями Go (проверено для 1.7).

Файлы:

gosthp.tar.gz – всё вместе в одном архиве.
SHA-256: b3f860f15d43814db2f2becfb4c72272de6d3b49f9b0dec70712438af0a6e085
(Update, 20/01/2024: архив перезагружен – изменено описание платформ в +build, даты в комментариях, и даты создания файлов; код – без изменений.)

Внутри архива:

cmd/
	| gostrun.go		- файл с примерами и тестами.
gosthp/	- это сама библиотека.
	| docipher_amd64.go	- объявления функций для amd64.
	| docipher_amd64.s	- код на ассемблере для amd64.
	| docipher_arm64.go	- объявления функций для arm64.
	| docipher_arm64.s	- код на ассемблере для arm64.
	| docipher.go		- универсальная реализация для прочих платформ (см. +build внутри: могут быть расхождения).
	| gosthp.go		- основной модуль.
go.mod
README

Основное дополнение – docipher_arm64.s, собственно, реализация шифра для архитектуры arm64/AArch64.

Как обычно, прилагается демонстрационный код – gostrun.go. Если развернуть упомянутый выше архив в директорию, то собрать gostrun можно так:

$ cd cmd
$ go build -o ~/my-builds/gostrun gostrun.go

Go самостоятельно выберет нужные файлы в соответствии с целевой платформой. Внутри исходников – много комментариев (англ.).
Саму библиотеку можно использовать в среде Go в составе других проектов простым копированием gosthp/, разместив её либо в директорию сборки, либо в общую директорию для пакетов.

Ассемблерная реализация для ARM от x86 отличается в некоторых деталях, не алгоритмических: во-первых, очевидно, другие инструкции; во-вторых, используется больше регистров и основные операции XOR собраны в общий блок; в-третьих, изменён способ вычисления смещений для обращения к таблице значений.

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

Базовые процедуры шифра (зашифрование/расшифрование) используют набор ключей раундов, которые создаются при инициализации конкретного экземпляра cipher – раундовые ключи как раз зависят от ключа шифрования, поэтому записываются в конкретный экземпляр структуры, в которой используются при повторных вызовах. То есть, разворачивание ключа тут тоже производится только один раз, при создании экземпляра cipher.

Что касается совместимости. И amd64, и arm64 – достаточно широкие понятия. В этой реализации шифра “Кузнечик” используются регистры и команды для разрядности 128-бит, которая соответствует разрядности шифра – в этом, собственно, смысл. Уже использование команд “длинной” арифметики из SSE4.1 для amd64 означает, что некоторые старые процессоры, полностью попадающие в amd64, не смогут, тем не менее, исполнять скомпилированный код, поскольку не поддерживают нужных команд. То же самое относится и к arm64 (например, выше я уже упомянул, что не использую “трёхрегистровую” команду XOR по этой же причине). Данная библиотека поддержку команд не проверяет, так что, вообще говоря, это нужно отслеживать отдельно, используя механизмы детектирования свойств аппаратуры, и, соответственно, либо заменять вызываемые функции, либо выводить предупреждение пользователю.

Кстати, ещё немного про Go (Golang). Одна из самых странных особенностей Go – это использование комментариев для управления компиляцией. Например, вот такая директива:

// +build !amd64

– это “обычный” комментарий в исходном коде, но его читает препроцессор и использует указание +build для того, чтобы определить платформу (всё, что не amd64; скажем, так сделано у меня в исходниках ассемблерной реализации “Кузнечика”; современный вариант: “//go:build“). Идея снабдить комментарии двойным дном – довольно богатая, в лингвистическом, так сказать, смысле.

Формально, “// +build !amd64” – это, действительно, комментарий. То есть, здесь обозначено, что строка не относится к, собственно, исходному коду. Это верно. А то, что там потом будет копаться препроцессор – ну так, как бы, и в комментариях бывает написано, что “данная функция нужна только для 8-битной конфигурации, поэтому здесь вызов спрятан в комментарий”. Неявно предполагается, что роль препроцессора играет непосредственно разработчик, а в случае “+build” в Golang – просто этот процесс автоматизируется. Это, конечно, не какой-то там особенный и исключительный случай использования комментариев: вспомните что-нибудь типа “#!/usr/bin/perl”. Тем не менее, ситуация, когда содержание комментария непосредственно влияет на процесс сборки, всё же выглядит необычно.

Вместе с Golang идёт собственный (псевдо)ассемблер. Это очень удобно в специальных случаях. Например, я использую этот ассемблер для реализации криптографических примитивов (и не только: при всём качестве компиляторов, некоторые задачи поиска и обработки данных могут работать существенно быстрее, если самостоятельно реализовать их с упором на особенности конкретной аппаратуры). Так вот, ассемблер в Go тоже необычный. Там своеобразные синтаксис и семантика. Например, “перевёрнутое” отношение операндов: MOV R1, R2 – пишет из R1 в R2, то есть, слева направо. Это вопрос соглашения, бывает разный подход, но естественным вариантом всё же представляется наоборот – R2 в R1, справа налево.

Очень многие мнемоники команд заменены на собственные мнемоники go-ассемблера, причём, трансляция не всегда очевидная, результат замены отличается от платформы к платформе, а сама замена сопровождается неожиданными дополнительными ограничениями.

Например, на arm64 go-ассемблерное “ADD $8, RSP, R2” соответствует оригинальному “ADD X2, SP, #0x8”. RSP превращается в SP потому, что ассемблер Go использует псевдорегистры, среди которых есть SP (и не только), поэтому совпадающие по названию аппаратные регистры переименованы. Псевдо-SP – это, как бы, указатель стека, но с хитростями: псевдо-SP может иногда совпадать по значению с аппаратным SP, в частности, если на подходящей платформе указана нулевая длина “собственного” стека ассемблерной процедуры (но это детали). При этом, ссылки с использованием смещения от значения псевдорегистра SP должны (это прямо строгое требование Go) оформляться с символьными именами, вот так: len-8(SP), где “минус” это не совсем вычитание, а len – это даже не “синтаксический сахар”, но что-то вроде комментария наоборот, поскольку никакой языковой интерпретации len здесь не имеет, ничего из len не вычитается, да и вовсе не обязательно, чтобы эта строка совпадала с именем аргумента в определении прототипа функции или ещё с чем-то совпадала (или не совпадала). Но если не указать произвольный символьный префикс – компилятор выдаст ошибку. Этому, естественно, имеется историческое объяснение, которое называется Plan 9.

Отрицательные и положительные смещения для SP – тоже отдельная забавная история: если SP совпадает с аппаратным регистром по семантике, – что задаётся правилами определения процедуры и входа в процедуру, – то, на некоторых платформах, можно использовать привычные положительные смещения, вот так: len+8(SP), однако где-то в документации написано (попробуйте найти), что “при ручном кодировании” необходимо использовать (только) “отрицательные смещения”. Да. Ну или наоборот, потому что лучшей документацией тут оказывается исходный код – как самого Golang, так и генерируемый компилятором.

Про записки за 2023 год я уже написал в предыдущей заметке. Занятно, что в наступающем 2024 году сайту dxdt.ru должно исполниться 20 лет. Но посмотрим, как там пойдёт, в том числе, с регулярными обновлениями. Я тут обычно оговариваю, что это архив записок на действующей версии сайта ведётся с 2006 года, однако сам сайт начал работать раньше, пусть и с некоторым перерывом.

С наступающим Новым годом! Спасибо, что читаете.

Панель управления WordPress на dxdt.ru пишет, что, по состоянию на момент выхода этой заметки, в 2023 году опубликовано аж 274 записки. Немало. Достаточно для того, чтобы сделать большую подборку из некоторых записок за год, с тематическим разбиением.

Околоматематическое и окололингвистическое

Бесконечные процессы как корни уравнений
Реплика: превращение словарных имён королей – Чарльз/Карл
Пифагорейские идеи и доказательство теоремы Ферма
Python, “численный” j-инвариант и десятичные цифры
Замена смысла текстовых предложений
Неравенство вычитания и языки программирования

Технологии интернета

DNS как транспорт для сигналов и данных
Один сценарий интернет-измерений и поле SNI HTTPS/TLS
Рандомизация регистра символов в DNS
Нормализация символов Unicode и доменные имена
VPN и DNS-сервисы с ECS: утечка сведений об адресах
Неравенство треугольника в Интернете и anycast

Про электронную почту

Интерпретация DMARC в разрезе DKIM
STARTTLS и SMTP

Интернет-рассуждения

Спагеттизация Интернета как проявление битвы за банхаммер
Наложенные сети Google и браузеры в будущем
Домены верхнего уровня, реестры и администраторы

Аппаратура/электроника и “механические” технологии

Несколько комментариев “около 3d-печати”
Работа GPS и коррекция по данным многих устройств
Кибератаки, самоуправляемые автомобили и бот в смартфоне
Инфракрасные сенсоры на орбите
Пеленгация с разнесением по времени
Согласование траекторий автомобилей-роботов
Электромобили с генераторами
Радиомодуль в смартфоне и недокументированные возможности
Starlink и взаимодействие с наземными GSM-сетями
Низкоорбитальные сенсоры как наблюдательные сети

Концепции информационной безопасности

Открытые “исходники” и “бинарный” код с точки зрения ИБ
Как правильно “показать TLS-сертификат”, рекомендации
Open Source и добавление “вредоносного кода”
Метаинформация, мессенджеры и цепочки событий в трафике
Неверные обобщения “принципа Керкгоффса”

Криптография и методы защиты информации

Техническое: poison-расширение и SCT-метки в Certificate Transparency
“Двухфакторная” аутентификация и Google Authenticator
“Инспекция” трафика с сохранением конфиденциальности
Общее представление о шифрах и бэкдоры
Постквантовые криптосистемы в Google Chrome (Kyber768)
Технические подробности: постквантовая криптосистема X25519Kyber768 в TLS
Постквантовые криптосистемы и квантовые компьютеры
Port knocking как инструмент управления доступом к скрытым сервисам
Полностью зашифрованные протоколы и DPI-блокирование
TLS в виртуальных машинах и извлечение ключей хостингом
Техническое: ECDSA на кривой Curve25519 в GNS

Неочевидные аспекты системного администрирования в ИТ

“Блокирующие” источники случайности в операционных системах
Системы счисления и системное администрирование

Вокруг ИИ/AI

Детектирование текстов, сгенерированных ИИ
Вычислимые опасности ИИ
Дорисовывание Луны смартфонами Samsung
ИИ для принятия решений
Машинное обучение и действительные числа
Широкие проблемы применения ИИ
Неверная интерпретация систем ИИ как “инструмента для анализа”
Обобщение ИИ и “кнопки на пульте”
Морфологический переворот как инструмент в “тесте Тьюринга”
“Вес” значений омонимов в текстах для LLM

Манускрипты, папирусы и прочая палеография

“Начала” Евклида, палеография и особенности чтения манускриптов
Офтопик: знаки из точек, манускрипт и буква ë в английском
Пятый постулат Евклида в древнем исполнении
“Сжатие языковых структур” и кусочки “Илиады”
Кибернетический след в “Илиаде” и цветовой сдвиг

Онтологические рассуждения вокруг физики и квантовых вычислений

Алгоритм Шора и Вселенная кубиками
Алгоритм Шора в фантастической машине превращения вероятностей
Реплика: слух человека и преобразование Фурье
“Лазейки” вокруг неравенства Белла
Выключение вариантов в двухщелевом опыте
Распространение квантовой запутанности
Квантовые компьютеры и аксиома непрерывности
Исторические концепции квантовых вычислений
Споткнувшаяся симуляция Вселенной
Квантовые вычисления для филологов
Кубиты в состояниях
Квантовые состояния в неизвестности
Квантовое время и частоты

Почти футурология

Технократический аспект Нового Средневековья
Геопривязка в персональных цифровых финансах
Превентивное удаление “цифровых следов” и художественное произведение

Представьте, что исследование карамельки выявило наличие внутри начинки. Для решения задачи размещения начинки внутри карамелек требуются некоторые особенные машины, которые нужны для формирования и обработки трубочек из карамельного состава. Опрошенные кулинары не знают, как такие машины изготавливают. Приготовить исходный раствор для корпусов карамелек, равно как и начинку из повидла, можно в кастрюле, это просто – типичная кухонная задача. Но вот создание машины, вкладывающей одно в другое, внезапно, требует станков для изготовления необычных металлических деталек, а это совсем другая история.

“Обратная разработка” (ревёрс-инжиниринг) нередко оказывается гораздо сложнее “прямой”. В частности, потому, что, при обратном движении, мыслимый процесс, приводящий к созданию целевого объекта, легко расщепляется, да ещё и в нескольких неожиданных плоскостях: мало того, что машина для помещения начинки в карамельки оказывается более замысловатой, чем кастрюля и сама карамелька с начинкой, так ещё и устроить эту машину можно многими способами, а измеримые свойства исходных карамелек вовсе не позволяют найти среди этих способов оптимальный, так как в карамельке сложность машины необратимым образом сворачивается в элементарный факт обнаружения начинки внутри корпуса.

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