Чем определяется популярность кода unicode в интернет

Чем определяется популярность кода unicode в интернет

• Главная
• Обучение
• Предварительный просмотр

• Мероприятия / ВИШР
• Обучение
• Тренажер ЕГЭ
• Учебные пособия
• Игры
• 120 лет ТПУ. Викторина онлайн
• Университетские субботы
• Высшая инженерная школа России

Информатика

1.1.3. Дискретное (цифровое) представление текстовой, графической, звуковой информации и видеоинформации. Единицы измерения количества информации

Рейтинг: 0

Кодирование текстовой информации

Компьютеры часто используются для обработки текстовой информации.

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

Количество разных символов, которые может различать компьютер, зависит от числа двоичных разрядов, отводимых для кодирования любого символа.

Традиционно для кодирования одного символа используется количество информации, равное 1 байту, то есть I= 1 байт = 8 битов

Для кодирования одного символа требуется 1 байт информации. Если рассматривать символы как возможные события, то можно вычислить, какое количество различных символов можно закодировать:

Такое количество символов вполне достаточно для представления текстовой информации, включая прописные и строчные буквы русского и латинского алфавита, цифры, знаки, графические символы и пр.

Кодирование заключается в том, что каждому символу ставится в соответствие уникальный десятичный код от 0 до 255 или соответствующий ему двоичный код от 00000000 до 11111111. Таким образом, человек различает символы по их начертаниям, а компьютер — по их кодам.

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

В процессе вывода символа на экран компьютера производится обратный процесс — декодирование, то есть преобразование кода символа в его изображение.

Важно, что присвоение символу конкретного кода — это вопрос соглашения, которое фиксируется в кодовой таблице (например, ASCII (англ. American Standard Code for Information Interchange) — американский стандартный код для обмена информацией. ASCII представляет собой кодировку для представления десятичных цифр, латинского и национального алфавитов, знаков препинания и управляющих символов). Первые 33 кода (с 0 по 32) соответствуют не символам, а операциям (перевод строки, ввод пробела и так далее).

Коды с 33 по 127 являются интернациональными и соответствуют символам латинского алфавита, цифрам, знакам арифметических операций и знакам препинания.

Коды с 128 по 255 являются национальными, то есть в национальных кодировках одному и тому же коду соответствуют различные символы.

В настоящее время существуют пять различных кодовых таблиц для русских букв (КОИ8, СР1251, СР866, Маc, ISO), поэтому тексты, созданные в одной кодировке, не будут правильно отображаться в другой.

Широкое распространение получил новый международный стандарт Unicode, который отводит на каждый символ не один байт, а два, поэтому с его помощью можно закодировать не 256 символов, а N = 2 16 = 65536 различных символов. Эту кодировку поддерживают последние версии платформы Microsoft Windows & Office (начиная с 1997 года).

Символы Unicode: о чём должен знать каждый разработчик

Если вы пишете международное приложение, использующее несколько языков, то вам нужно кое-что знать о кодировке. Она отвечает за то, как текст отображается на экране. Я вкратце расскажу об истории кодировки и о её стандартизации, а затем мы поговорим о её использовании. Затронем немного и теорию информатики.

Введение в кодировку

Компьютеры понимают лишь двоичные числа — нули и единицы, это их язык. Больше ничего. Одно число называется байтом, каждый байт состоит из восьми битов. То есть восемь нулей и единиц составляют один байт. Внутри компьютеров всё сводится к двоичности — языки программирования, движений мыши, нажатия клавиш и все слова на экране. Но если статья, которую вы читаете, раньше была набором нулей и единиц, то как двоичные числа превратились в текст? Давайте разберёмся.

Краткая история кодировки

На заре своего развития интернет был исключительно англоязычным. Его авторам и пользователям не нужно было заботиться о символах других языков, и все нужды полностью покрывала кодировка American Standard Code for Information Interchange (ASCII).

ASCII — это таблица сопоставления бинарных обозначений знакам алфавита. Когда компьютер получает такую запись:

01001000 01100101 01101100 01101100 01101111 00100000 01110111 01101111 01110010 01101100 01100100 

то с помощью ASCII он преобразует её во фразу «Hello world».

Один байт (восемь бит) был достаточно велик, чтобы вместить в себя любую англоязычную букву, как и управляющие символы, часть из которых использовалась телепринтерами, так что в те годы они были полезны (сегодня уже не особо). К управляющим символам относился, например 7 (0111 в двоичном представлении), который заставлял компьютер издавать сигнал; 8 (1000 в двоичном представлении) — выводил последний напечатанный символ; или 12 (1100 в двоичном представлении) — стирал весь написанный на видеотерминале текст.

В те времена компьютеры считали 8 бит за один байт (так было не всегда), так что проблем не возникало. Мы могли хранить все управляющие символы, все числа и англоязычные буквы, и даже ещё оставалось место, поскольку один байт может кодировать 255 символов, а для ASCII нужно только 127. То есть неиспользованными оставалось ещё 128 позиций в кодировке.

Вот как выглядит таблица ASCII. Двоичными числами кодируются все строчные и прописные буквы от A до Z и числа от 0 до 9. Первые 32 позиции отведены для непечатаемых управляющих символов.

Проблемы с ASCII

Позиции со 128 по 255 были пустыми. Общественность задумалась, чем их заполнить. Но у всех были разные идеи. Американский национальный институт стандартов (American National Standards Institute, ANSI) формулирует стандарты для разных отраслей. Там утвердили позиции ASCII с 0 по 127. Их никто не оспаривал. Проблема была с остальными позициями.

Вот чем были заполнены позиции 128-255 в первых компьютерах IBM:

Какие-то загогулины, фоновые иконки, математические операторы и символы с диакретическим знаком вроде é. Но разработчики других компьютерных архитектур не поддержали инициативу. Всем хотелось внедрить свою собственную кодировку во второй половине ASCII.

Все эти различные концовки назвали кодовыми страницами.

Что такое кодовые страницы ASCII?

Здесь собрана коллекция из более чем 465 разных кодовых страниц! Существовали разные страницы даже в рамках какого-то одного языка, например, для греческого и китайского. Как можно было стандартизировать этот бардак? Или хотя бы заставить его работать между разными языками? Или между разными кодовыми страницами для одного языка? В языках, отличающихся от английского? У китайцев больше 100 000 иероглифов. ASCII даже не может всех их вместить, даже если бы решили отдать все пустые позиции под китайские символы.

Эта проблема даже получила название Mojibake (бнопня, кракозябры). Так говорят про искажённый текст, который получается при использовании некорректной кодировки. В переводе с японского mojibake означает «преобразование символов».

Пример бнопни (кракозябров).

Безумие какое-то.

Именно! Не было ни единого шанса надёжно преобразовывать данные. Интернет — это лишь монструозное соединение компьютеров по всему миру. Представьте, что все страны решили использовать собственные стандарты. Например, греческие компьютеры принимают только греческий язык, а английские отправляют только английский. Это как кричать в пустой пещере, тебя никто не услышит.

ASCII уже не удовлетворял жизненным требованиям. Для всемирного интернета нужно было создать что-то другое, либо пришлось бы иметь дело с сотнями кодовых страниц.

��� Если только ������ вы не хотели ��� бы ��� читать подобные параграфы. �֎֏0590֐��׀ׁׂ׃ׅׄ׆ׇ

Так появился Unicode

Unicode расшифровывают как Universal Coded Character Set (UCS), и у него есть официальное обозначение ISO/IEC 10646. Но обычно все используют название Unicode.

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

Кто-то проделал огромную работу, сопоставляя каждый символ во всех языках с уникальными кодами. Вот как это выглядит:

«Hello World» U+0048 : латинская прописная H U+0065 : латинская строчная E U+006C : латинская строчная L U+006C : латинская строчная L U+006F : латинская строчная O U+0020 : пробел U+0057 : латинская прописная W U+006F : латинская строчная O U+0072 : латинская строчная R U+006C : латинская строчная L U+0064 : латинская строчная D

Префикс U+ говорит о том, что это стандарт Unicode, а число — это результат преобразования двоичных чисел. Стандарт использует шестнадцатеричную нотацию, которая является упрощённым представлением двоичных чисел. Здесь вы можете ввести в поле что угодно и посмотреть, как это будет преобразовано в Unicode. А здесь можно полюбоваться на все 143 859 кодовых пунктов.

Уточню на всякий случай: речь идёт о большом словаре кодовых пунктов, присвоенных всевозможным символам. Это очень большой набор символов, не более того.

Осталось добавить последний ингредиент.

Unicode Transform Protocol (UTF)

UTF — протокол кодирования кодовых пунктов в Unicode. Он прописан в стандарте и позволяет кодировать любой кодовый пункт. Однако существуют разные типы UTF. Они различаются количеством байтов, используемых для кодировки одного пункта. В UTF-8 используется один байт на пункт, в UTF-16 — два байта, в UTF-32 — четыре байта.

Но если у нас есть три разные кодировки, то как узнать, какая из них применяется в конкретном файле? Для этого используют маркер последовательности байтов (Byte Order Mark, BOM), который ещё называют сигнатурой кодировки (Encoding Signature). BOM — это двухбайтный маркер в начале файл, который говорит о том, какая именно кодировка тут применена.

В интернете чаще всего используют UTF-8, она также прописана как предпочтительная в стандарте HTML5, так что уделю ей больше всего внимания.

Этот график построен в 2012-м, UTF-8 становилась доминирующей кодировкой. И всё ещё ею является.

График показывает распространённость UTF-8.

Что такое UTF-8 и как она работает?

UTF-8 кодирует с помощью одного байта каждый кодовый пункт Unicode с 0 по 127 (как в ASCII). То есть если вы писали программу с использованием ASCII, а ваши пользователи применяют UTF-8, они не заметят ничего необычного. Всё будет работать как задумано. Обратите внимание, как это важно. Нам нужно было сохранить обратную совместимость с ASCII в ходе массового внедрения UTF-8. И эта кодировка ничего не ломает.

Как следует из названия, кодовый пункт состоит из 8 битов (один байт). В Unicode есть символы, которые занимают несколько байтов (вплоть до 6). Это называют переменной длиной. В разных языках удельное количество байтов разное. В английском — 1, европейские языки (с латинским алфавитом), иврит и арабский представлены с помощью двух байтов на кодовый пункт. Для китайского, японского, корейского и других азиатских языков используют по три байта.

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

И теперь мы, как по волшебству, пришли к соглашению, как закодировать шумерскую клинопись (Хабр её не отображает), а также значки emoji!

Подытожив сказанное: сначала читаем BOM, чтобы определить версию кодировки, затем преобразуем файл в кодовые пункты Unicode, а потом выводим на экран символы из набора Unicode.

Напоследок про UTF

Коды являются ключами. Если я отправлю ошибочную кодировку, вы не сможете ничего прочесть. Не забывайте об этом при отправке и получении данных. В наших повседневных инструментах это часто абстрагировано, но нам, программистам, важно понимать, что происходит под капотом.

Как нам задавать кодировку? Поскольку HTML пишется на английском, и почти все кодировки прекрасно работают с английским, мы можем указать кодировку в начале раздела .

Важно сделать это в самом начале , поскольку парсинг HTML может начаться заново, если в данный момент используется неправильная кодировка. Также узнать версию кодировки можно из заголовка Content-Type HTTP-запроса/ответа.

Если HTML-документ не содержит упоминания кодировки, спецификация HTML5 предлагает такое интересное решение, как BOM-сниффинг. С его помощью мы по маркеру порядка байтов (BOM) можем определить используемую кодировку.

Это всё?

Unicode ещё не завершён. Как и в случае с любым стандартом, мы что-то добавляем, убираем, предлагаем новое. Никакие спецификации нельзя назвать «завершёнными». Обычно в год бывает 1-2 релиза, найти их описание можно здесь.

Если вы дочитали до конца, то вы молодцы. Предлагаю сделать домашнюю работу. Посмотрите, как могут ломаться сайты при использовании неправильной кодировки. Я воспользовался этим расширением для Google Chrome, поменял кодировку и попытался открывать разные страницы. Информация была совершенно нечитаемой. Попробуйте сами, как выглядит бнопня. Это поможет понять, насколько важна кодировка.

Заключение

При написании этой статьи я узнал о Майкле Эверсоне. С 1993 года он предложил больше 200 изменений в Unicode, добавил в стандарт тысячи символов. По состоянию на 2003 год он считался самым продуктивным участником. Он один очень сильно повлиял на облик Unicode. Майкл — один из тех, кто сделал интернет таким, каким мы его сегодня знаем. Очень впечатляет.

Надеюсь, мне удалось показать вам, для чего нужны кодировки, какие проблемы они решают, и что происходит при их сбоях.

• Блог компании VK
• Веб-разработка
• Проектирование и рефакторинг
• Терминология IT
• Хранение данных

Unicode: как человечество пришло к международному стандарту кодирования символов

Уверена, что большинство читателей хоть немного знакомы с терминами «Unicode» и «UTF-8». Но все ли знают, что именно стоит за ними? По сути они относятся к стандартам кодирования символов, также известным как наборы символов. Концепция появилась во времена оптического телеграфа, а не в компьютерную эру, как можно было подумать. Еще в 18 веке существовала потребность в быстрой передаче информации на большие расстояния, для чего использовались так называемые телеграфные коды. Информация кодировалась с помощью оптических, электронных и других средств.

В течение сотен лет, прошедших с момента изобретения первого телеграфного кода, не было никаких реальных попыток международной стандартизации таких схем кодирования. Даже первые десятилетия эры телетайпов и домашних компьютеров мало что изменили. Несмотря на то, что EBCDIC (8-битная кодировка символов IBM, продемонстрированная на перфокарте в заглавной иллюстрации) и ASCII немного улучшили ситуацию, способа кодировать растущую коллекцию символов без значительных затрат памяти все еще не было.

Развитие Юникода началось в конце 1980-х годов, когда рост обмена цифровой информацией во всем мире сделал потребность в единой системе кодирования более насущной. В наши дни Юникод позволяет нам использовать единую схему кодирования для всего — от базового английского текста и традиционного китайского, вьетнамского, даже майянского языков до пиктограмм, которые мы привыкли называть «эмодзи».

От кода к графикам

Еще в эпоху Римской империи было хорошо известно, что быстрая передача информации имеет значение. В течение долгого времени это означало наличие гонцов на лошадях, которые доставляли сообщения на большие расстояния, или их эквивалента. Как улучшить систему доставки информации, придумали еще в 4 веке до нашей эры — так появились водяной телеграф и система сигнальных огней. Но действительно эффективной передача данные на большие расстояния стала лишь в 18 веке.

Об оптическом телеграфе, также называемом «семафоре», мы уже писали в статье об истории оптической связи. Он состоял из ряда ретрансляционных станций, каждая из которых была оборудована системой поворотных стрелок, используемой для отображения символов телеграфного кода. Система братьев Шапп, которая использовалась французскими войсками между 1795 и 1850-ми годами, была основана на деревянной перекладине с двумя подвижными концами (рычагами), каждый из которых мог перемещаться в одно из семи положений. Вместе с четырьмя позициями для перекладины семафор в теории мог обозначить 196 символов (4x7x7). На практике число сокращалось до 92-94 позиций.

Французский оптический телеграфный код братьев Шапп, 1809 год

Система семафоров использовалась не столько для прямого кодирования символов, сколько для обозначения определенных строк в кодовой книге. Метод подразумевал, что по нескольким кодовым сигналам можно было расшифровать все сообщение. Это ускоряло передачу и делало бессмысленным перехват сообщений.

Улучшение производительности

Затем оптический телеграф был заменен электрическим. Это означало, что времена, когда кодировки фиксировались людьми, наблюдающими за ближайшей релейной вышкой, прошли. С двумя телеграфными устройствами, соединенными металлическим проводом, инструментом для передачи информации стал электрический ток. Это изменение привело к появлению новых кодов электрического телеграфа, а код Морзе в итоге стал международным стандартом (за исключением США, которые продолжали использовать американский код Морзе за пределами радиотелеграфии) с момента его изобретения в Германии в 1848 году.

Международный код Морзе имеет преимущество перед американским аналогом: в нем используется больше тире, чем точек. Такой подход снижает скорость передачи, но улучшает прием сообщения на другом конце линии. Это было необходимо, когда длинные сообщения передавались по многокилометровым проводам операторами разного уровня подготовки.

Стандарт ITA 2

По мере развития технологий ручной телеграф был заменен на Западе автоматическим. В нем использовался 5-битный код Бодо, а также производный от него код Мюррея (последний основывался на использовании бумажной ленты, в которой пробивались отверстия). Система Мюррея позволяла заранее подготовить ленту с сообщениями, а затем загрузить ее в устройство для чтения, чтобы сообщение передалось автоматически. Код Бодо лег в основу международного телеграфного алфавита версии 1 (ITA 1), а модифицированный код Бодо-Мюррея лег в основу ITA 2, которая использовалась вплоть до 1960-х годов.

К 1960-м годам ограничение в 5 бит на символ уже не требовалось, что привело к развитию 7-битного ASCII в США и таких стандартов, как JIS X 0201 (для японских символов катакана) в Азии. В сочетании с телетайпами, которые тогда широко использовались, это позволяло передавать довольно сложные сообщения, включающие символы верхнего и нижнего регистров.

Полный набор символов 7-битного ASCII

В течение 1970-х и начала 1980-х годов ограничений 7- и 8-битных кодировок, таких как расширенный ASCII (например, ISO 8859-1 или Latin 1), было достаточно для основных домашних компьютеров и офисных нужд. Несмотря на это, потребность в улучшении была очевидна, поскольку общие задачи, такие как обмен цифровыми документами и текстом, часто приводили к хаосу из-за множества кодировок ISO 8859. Первый шаг был сделан в 1991 году — появился 16-битный Unicode 1.0.

Развитие 16-битных кодировок

Удивительно, что всего в 16 битах Unicode удалось охватить не только все западные системы письма, но и многие китайские иероглифы и множество специальных символов, используемых, например, в математике. С 16 битами, допускающими до 65 536 кодовых точек, Unicode 1.0 легко вмещал 7 129 символов. Но к моменту появления Unicode 3.1 в 2001 году он содержал не менее 94 140 символов.

Сейчас, в своей 13 версии, Unicode содержит в общей сложности 143 859 символов, не считая управляющих. Изначально Unicode предполагалось использовать только для кодирования систем записи, которые применяются в настоящее время. Но к релизу Unicode 2.0 в 1996 году стало понятно, что эту цель следует переосмыслить, чтобы кодировать даже редкие и исторические символы. Чтобы достичь этого без обязательной 32-битной кодировки каждого символа, Unicode изменился: он позволил не только кодировать символы напрямую, но и использовать их компоненты, или графемы.

Концепция в чем-то похожа на векторные изображения, где не указывается каждый пиксель, а вместо этого описываются элементы, составляющие рисунок. В результате кодировка Unicode Transformation Format 8 (UTF-8) поддерживает 2 31 кодовую точку, при этом для большинства символов в текущем наборе символов Unicode обычно требуется один-два байта.

Unicode на любой вкус и цвет

На данный момент довольно много людей, вероятно, сбиты с толку из-за различных терминов, которые используются, когда дело доходит до Unicode. Поэтому здесь важно отметить, что Unicode относится к стандарту, а различные Unicode Transformation Format являются его реализациями. UCS-2 и USC-4 — это более старые 2- и 4-байтовые реализации Unicode, при этом UCS-4 идентичен UTF-32, а UCS-2 заменяем UTF-16.

UCS-2 как самая ранняя форма Unicode проникла во многие операционные системы 90-х годов, что сделало переход на UTF-16 наименее опасным вариантом. Вот почему Windows и MacOS, оконные менеджеры, такие как KDE, и среды выполнения Java и .NET используют внутреннее представление UTF-16.

Обзор базовой многоязычной плоскости Unicode, первой плоскости Unicode практически со всеми современными языками

UTF-32, как следует из названия, кодирует каждый символ в четырех байтах. Это немного расточительно, зато абсолютно предсказуемо. Тот же UTF-8 символ может кодировать символ в диапазоне от одного до четырех байтов. В случае с UTF-32 определение количества символов в строке — это простая арифметика: взять все количество байтов и поделить на четыре. Это привело к появлению компиляторов и некоторых языков, например Python, позволяющих использовать UTF-32 для представления строк Unicode.

Однако из всех форматов Unicode наиболее популярным на сегодняшний день является UTF-8. Этому во многом способствовала всемирная сеть Интернет, где большинство веб-сайтов обслуживают свои HTML-документы в кодировке UTF-8. Из-за компоновки различных плоскостей кодовых точек в UTF-8, Western и многие другие распространенные системы записи умещаются в пределах двух байтов. Если сравнивать со старыми кодировками ISO 8859 и Shift JIS, фактически тот же текст в UTF-8 не занимает больше места, чем раньше.

От оптических башен до интернета

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

Для тех, кому довелось переключаться между кодировками ISO 8859 в почтовых клиентах и ​​веб-браузерах, чтобы получить что-то, похожее на исходное текстовое сообщение, поддержка Unicode стала благословением. Я могу понять этих людей. Когда 7-битный ASCII (или EBCDIC) был безальтернативной технологией, иногда приходилось тратить часы, разбираясь в символьной путанице цифрового документа, полученного из европейского или американского офиса.

Даже если Unicode не лишен проблем, трудно не испытывать благодарности, сравнивая его с тем, что было раньше. Вот они, 30 лет существования Unicode.

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

Ресурсы: техническое описание TLS, LaTeX — в картинки (img)

Квантовая криптография и металлический контейнер

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

Вывод ключей Kyber768 на tls13.1d.pw

Переделал вывод открытого ключа Kyber768 на экспериментальном TLS-сервере – см. скриншот ниже. Открытый ключ Kyber768 состоит из трёх полиномов (256 коэффициентов, которые превращаются в 384 байта для каждого полинома) и дополнительного параметра в 32 байта (в выдаче сервера он называется Rho). То есть, ключ существенно отличается по представлению, например, от RSA, где открытый ключ можно представить как пару натуральных чисел, одно из которых большое (модуль), или от ECDSA, где открытый ключ – точка на кривой, а поэтому его можно представить как пару натуральных чисел, а если в “сжатом” виде, то как одно. Здесь речь о том, как максимально близко к математическим свойствам вывести значения ключей, так-то понятно, что в этой области всё можно отобразить в виде натурального числа (или в виде полинома, кому как нравится). В принципе, полиномы Kyber768 можно было бы распаковать и отобразить так, чтобы они и выглядели как полиномы, но тогда получится совсем уж мешанина на странице.

Экспериментальный сервер TLS: сигналы внутри сертификата

Продолжаем небольшую серию записок про TLS-сервер на tls13.1d.pw. Этот сервер передаёт несколько сертификатов, в том числе и один необычный сертификат, увидеть который можно только в выдаче той или иной специальной утилиты (например, s_client из OpenSSL) или упомянутым сервисом SSLLabs. Этот сертификат сервер генерирует (и даже подписывает, но это тут не важно) в самом начале установления соединения, а в поля Subject и Issuer записываются, соответственно, IP-адрес с номером порта клиента и имя выбранной криптосистемы обмена ключами. Это такой экзотический способ “посигналить” в (закрытой) части TLS-сообщений. Клиенты должны бы игнорировать неподходящий сертификат в процессе валидации (но могут и ошибку выдать, конечно).

Тест SSLLabs и X25519Kyber768

Очень полезный тест SSLLabs для TLS пока что не умеет обнаруживать поддержку криптосистемы X25519Kyber768 сервером – см. фрагмент результатов для tls13.1d.pw на скриншоте ниже (Supported Named Groups). Это, собственно, понятно и логично: использование данной криптосистемы всё ещё находится в экспериментальном статусе, а поддержка на стороне сервера совсем не распространена.

(Кстати, в результатах указано, что имена групп/криптосистем выведены в порядке предпочтений сервера, но для tls13.1d.pw это не так – сейчас “предпочтение” есть только для X25519Kyber768, остальные криптосистемы выбираются по наличию клиентских key_share, перечню поддерживаемых групп, но при этом ещё и случайным образом отправляется HelloRetryRequest – именно из соображений, что иногда нужно отправить HelloRetryRequest, а не по составу полученных клиентских параметров; обычные TLS-серверы так вряд ли делают.)

Постквантовые криптосистемы и квантовые компьютеры

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

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

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

Технические подробности: постквантовая криптосистема X25519Kyber768 в TLS

В продолжение недавней записки про X25519Kyber768 на TLS-сервере – подробности встраивания данной гибридной криптосистемы в схему работы TLS 1.3.

1. Как нетрудно догадаться, X25519Kyber768 состоит из X25519 и Kyber768, поэтому криптосистема и гибридная. X25519 – это хорошо известный вариант протокола Диффи-Хеллмана (DH), здесь используется без изменений, обычным образом (см. кстати, заметку с задачей про 2^255 – 19). Kyber768 – схема KEM (инкапсуляции ключа), построенная на криптосистеме Kyber с “постквантовой стойкостью”. Эта криптосистема реализует зашифрование с открытым ключом (важный момент).

2. В TLS рассматриваемая криптосистема используется для получения симметричного сеансового секрета. Открытый ключ передаётся клиентом в составе ClientHello, в расширении key_share, а ответная часть сервером – в ServerHello, key_share. В логике сообщений тут ничего не меняется.

3. Изменяется часть внутри key_share, соответствующая X25519Kyber768 – клиент передаёт результат конкатенации байтов, составляющих клиентскую часть DH X25519 и открытый ключ клиента Kyber768. Эти данные имеют фиксированную длину, определяемую алгоритмами: 32 начальных байта для X25519 и 1184 для Kyber768, 1216 байтов всего. На сервере данные разделяются (просто, по длине) и используются для обеих криптосистем. А именно: для X25519 сервер вычисляет общий секрет DH и серверную открытую часть DH (B), так же, как это делалось бы в случае отдельной криптосистемы X25519; для Kyber768 – сервер генерирует общий секрет и оборачивает его в KEM (то есть, зашифровывает исходное секретное значение, используя открытый ключ Kyber, присланный клиентом – тем самые 1184 байта). Два секрета сервер объединяет в один массив – здесь, опять же, простая конкатенация: BaseSecret = x25519[] + Kyber_Shared_Secret[]. Обратите внимание на важное техническое отличие: для X25519 общий секрет, на сервере, это результат умножения открытой части DH клиента (A) на секретный скаляр сервера d: s = d*A; а для Kyber – сервер выбирает исходное значение, которое отправляет клиенту в зашифрованном виде (очень похоже на устаревшую схему с RSA-шифрованием в TLS, но устроенную наоборот). При этом внутри KEM Kyber для вычисления секрета по исходному значению используется отдельная функция (KDF), подмешивающая ещё и значение открытого ключа, это необходимый шаг, но, с точки зрения логики получения секрета, это не так важно. Секрет, генерируемый в рамках Kyber768 в TLS – это тоже 32 байта (256 бит). После завершения данного этапа – сервер получил общий симметричный секрет, представляющий собой объединение выдачи двух алгоритмов: 32 байта и 32 байта. Также сервер получил открытую часть DH и зашифрованный Kyber симметричный секрет (это только часть, предназначенная для Kyber, результат X25519 сюда не попадает).

4. Сервер формирует ответное расширение key_share, присоединяя к 32 байтам открытой части DH X25519 байты шифротекста с симметричным секретом, который зашифрован Kyber – длина шифротекста 1088 байтов, всего 1120 байтов. Ответное key_share сервер отправляет клиенту в открытой части сообщений, в ServerHello, после чего генерирует на основе общего секрета набор симметричных сессионных ключей и переходит к зашифрованному обмену данными.

5. Клиент, получив key_share X25519Kyber768, разделяет данные на открытую часть обмена DH X25519 (B) и шифротекст Kyber768. По значению B DH клиент вычисляет общий секрет DH X25519 (здесь – 32 байта), который совпадает с серверным. Используя секретный ключ, клиент расшифровывает шифротекст и вычисляет общий секрет Kyber. Оба полученных значения объединяются, результат должен совпасть с серверным. (Тут слово “должен” использовано потому, что в Kyber, к сожалению, есть вероятностный элемент: так как это схема, концептуально происходящая из кодов с коррекцией ошибок, то имеется очень небольшая вероятность, что “ошибка” всё же останется, а клиент и сервер получат разные значения секрета.) На основе объединённого секрета клиент вычисляет набор симметричных ключей и может проверить подлинность и расшифровать следующие сообщения сервера.

Таким образом, Kyber простым и понятным способом добавляет 256 бит “постквантовой стойкости” к исходному симметричному секрету TLS-сессии, какие-то другие параметры – не изменяются.

Постквантовые криптосистемы на экспериментальном сервере TLS

Всё же я пока восстановил свой экспериментальный сервер TLS 1.3 – tls13.1d.pw (некоторое время назад я писал, что собираюсь его совсем отключить). А чтобы восстановление выглядело поинтереснее, я реализовал на сервере поддержку постквантовой схемы получения общего секрета (KEM) X25519Kyber768. TLS с Kyber768 там реализован вручную, но я, впрочем, использовал криптопримитивы из удобной библиотеки Cloudflare.

Криптосистему с постквантовой схемой KEM Kyber768 в конце августа Google внедрил в браузер Chrome (в порядке эксперимента), так что можете проверить – на сервере у X25519Kyber768 повышен приоритет, поэтому, при наличии соответствующего открытого ключа в сообщении клиента, выбираться она должна довольно часто.

Вообще, открытый блок клиентского KeyShare в X25519Kyber768 весит аж 1216 байтов (32 + 1184, потому что это ключ X25519, 32 байта, плюс ключ постквантовой части Kyber768, который большой). Тем не менее, я всё же пока что сделал вывод этого ключа без сокращений, что, возможно, выглядит тяжеловато, но видно будет только в браузере с поддержкой данной криптосистемы. (Дополнение, 12/09/2023: технические подробности об использовании криптосистемы.)

Поддержка есть только в самых свежих версиях Chrome (>=116), а включать её нужно через флаги: chrome://flags, набрать “TLS13” в поиске, флаг называется “TLS 1.3 hybridized Kyber support”.

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

VPN и DNS-сервисы с ECS: утечка сведений об адресах

Обычно, DNS-резолвер должен работать внутри VPN-сервиса – то есть, это может быть буквально обособленный резолвер, используемый именно в составе VPN (желательно, с DNSSEC). Но так делается далеко не всегда. Напомню, что DNS-резолвер (в данном случае, речь про рекурсивный резолвер) – это сервис, который проводит опрос серверов DNS, отыскивая, например, IP-адреса по именам узлов – адрес, по которому нужно браузеру обращаться к веб-серверу под именем test.ru. Резолвер выполняет то, что называется рекурсивным опросом: обращается к авторитативным DNS-серверам разных уровней. Эти серверы видят IP-адрес резолвера, но не клиента резолвера, который (вероятно) будет подключаться к сервису по обнаруженному в DNS адресу. При этом, для целей балансировки нагрузки на “целевой” сервис, DNS-серверу удобно было бы знать что-то о клиенте, для которого работает конкретный резолвер – потому что балансировка выполняется именно для клиента сервиса, а не для клиента DNS (сервис доменных имён (DNS) в этот момент уже на нужной стороне отработал). Это особенно актуально для больших открытых сервисов DNS-резолверов, например, Google Public DNS, так как эти сервисы обслуживают клиентов из самых разных точек сети. Чтобы как-то помочь оптимизации, довольно давно придумали расширение DNS под названием EDNS Client Subnet (ECS).

Данная технология (ECS) позволяет резолверу передать в сторону авторитативного сервера сведения об IP-подсети клиента, который обратился с запросом. Проще говоря – авторитативный сервер увидит IP-адресный блок, который соответствует клиенту, находящемуся за резолвером, что позволит определить провайдера. ECS как раз поддерживается Google Public DNS (и не только). Предполагается, что авторитативный сервер, определив провайдера клиента резолвера, сможет применить какие-то правила оптимизации. Если VPN используется для сокрытия IP-адреса пользовательского подключения, но DNS-трафик направляется не через VPN в какой-то DNS-сервис, то наличие ECS в этом сервисе (при прочих равных) означает, что внешние авторитативные DNS-серверы увидят скрываемую подсеть. Об этом нередко забывают.

Технический пример (не учитывающий NAT и другие тонкие настройки): предположим, клиентское устройство использует провайдерский доступ с адресом 10.11.12.13, ему соответствует подсеть 10.11.12.0/24; выход из VPN использует подключение с IP 10.22.22.22 (подсеть 10.22.22.0/24); DNS-трафик направляется напрямую (не через VPN) резолверу 10.53.53.53, резолвер поддерживает ECS. Тогда, при попытке определить значение A-записи (адрес), внешние серверы DNS узнают, что к ним подключается резолвер с адресом 10.53.53.53 для клиента из подсети 10.11.12.0/24. А вот на веб-сервере, к которому обращение произойдёт через VPN, адрес клиента будет виден как 10.22.22.22 – внешняя точка VPN. Естественно, если DNS-трафик маршрутизируется устройством через VPN, то внешний DNS-сервис с ECS сможет передать наружу только подсеть точки выхода VPN (10.22.22.0/24), поскольку именно адрес из этой подсети он видит в качестве источника запроса. Но лучше, конечно, если вообще используется собственный резолвер без ECS в составе VPN-сервиса, потому что возможны и другие каналы утечки метаинформации.

Скорость из OBD и программы-навигаторы

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

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

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

Неверные обобщения “принципа Керкгоффса”

“Принцип Керкгоффса” (Kerckhoffs’s principle) в криптографии гласит, что планируемая стойкость криптосистемы не должна быть связана с тем, что сам используемый алгоритм держится в секрете (секретными должны быть только ключи). Но из этого вовсе не следует, что система с “секретным алгоритмом” заведомо нестойкая, как почему-то можно нередко прочитать – это как раз и есть обобщение, неверно основанное на более широком утверждении. Исходный практический принцип – о другом: если реализация криптосистемы оказалась в руках атакующего, то это не должно приводить к необходимости перехода на другую криптосистему, с другим алгоритмом, поскольку предыдущий оказался скомпрометирован.

Является ли криптосистема с “секретным алгоритмом” более стойкой или менее стойкой, по сравнению с “открытым алгоритмом”? С точки зрения оценки алгоритма, очевидно, сказать ничего нельзя: если “алгоритм секретный”, то его не оценить (но, конечно, “осадок остался”). Улучшается ли безопасность решения, использующего такой подход, в целом? Далеко не факт. Однако точно сказать довольно сложно – зависит от конкретной ситуации: нужно, как минимум, смотреть, в какой модели угроз действуют разработчики (действительно, может, они прежде всего защищаются от конкурирующей компании – кто первый выпустит очередную “умную лампочку”, а набор удачных алгоритмов позволяет экономить на аппаратуре).

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

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

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

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

Широкие проблемы применения ИИ

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

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

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

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

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

Посмотрим, в качестве простого примера, на случай распознавания объектов на изображениях при помощи “обучения нейросетки”: тут на вход поступает большой набор параметров, который приводит к появлению на выходе согласованного с обучающей выборкой варианта из нескольких параметров, заранее заданных закрытым списком. Например, на входе – набор из сотен тысяч пикселей, снабжённых координатами, а на выходе – кортеж значений из названия объекта и некоторого числа: “лиса, 0.9”. Однако в какой-то момент об этом всём благополучно забывают и начинают считать, что данной нейросети что-то там стало известно о свойствах классифицируемых объектов, – например, о лисе, – и переформулируют результат: “на картинке лиса, с вероятностью 90%” (это сейчас происходит повсеместно, хотя именно о вероятности совпадения, да ещё и на выборке, отличной и от обучающей, и от тестовой, по показаниям такого фильтра – судить нельзя). Повышение значимости оценки же связано с тем, что такие манипуляции принято называть “искусственным интеллектом”. Но ведь используется всего лишь фильтр с неясными свойствами, полученный в результате псевдослучайного процесса, который гоняли на некоторой небольшой выборке входных значений. А вместо лисы на картинке может быть набор цветных треугольников, специально показанных в камеру (что неоднократно демонстрировалось на практике): “что мы знаем о лисе? ничего, и то не все”. Конечно, некоторые уже начинают о чём-то догадываться, рассказывают о “галлюцинирующих больших языковых моделях – LLM”, но, похоже, неприятных в своей массовости проблем всё равно не избежать.

Записки dxdt.ru: ← Опубликованные позже Опубликованные раньше →

RSS