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

Бывают контринтуитивные решения, бывают контринтуитивные в квадрате, но многое тут зависит от того, как преподносят модель “интуиции”. Пример из области, близкой dxdt.ru: вычисление общего секрета по протоколу Диффи-Хеллмана. Первый уровень контринтуитивности тут традиционно описывается так: нужно получить общий секретный ключ через открытый канал, но это “невозможно”, поскольку – как же передать секретный ключ по открытому каналу, чтобы никто не увидел? “Интуитивные” хитрости тут скрыты в понятиях “получить” и “передать”.

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

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

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

• Исчезновение “фрагментации Интернета” с разных точек зрения;
• Перспективный ИИ в “разработке кода”;
• Технократический аспект Нового Средневековья;
• Несколько комментариев “около 3d-печати”;
• Алгоритм Шора и Вселенная кубиками.

(А кроме того – внутренний идентификатор, привязанный к добавлению заметок, перевалил за 10000; но это просто технический идентификатор, количество заметок в базе dxdt.ru на данный момент существенно меньше: 2,732.)

Из недавней записки цитата про ИИ:

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

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

Mitigating the risk of extinction from AI should be a global priority alongside other societal-scale risks such as pandemics and nuclear war.

Перевод (с комментариями): “снижение риска исчезновения (не указано, исчезновение кого имеется в виду, почему-то думают, что человечества; но – не факт) из-за ИИ должно (SHOULD, а не MUST, заметьте) иметь глобальный приоритет, наравне с другими рисками всеобщего масштаба (societal-scale – не обязательно всё человечество), такими как пандемии и ядерная война (“хеш-теги”)”.

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

(via)

Технологии DKIM и DMARC предназначены для управления политиками доставки электронной почты, но подходят к этой задаче с разных сторон. DKIM (DomainKeys Identified Mail) – позволяет сопроводить сообщение электронной почты некоторым доказательством, что отправляющий сервер имеет отношение к домену, который указан в качестве источника сообщения, что этот сервер знает некоторый секретный ключ. Для предоставления доказательств используется цифровая подпись и публикация в DNS соответствующих открытых ключей для проверки подписи. Нужно учитывать, что это “техническая” подпись: она может, косвенно, подтверждать подлинность сервера-источника сообщения, целостность каких-то технических элементов сообщения (в том числе, целостность полезного содержания), однако используется в контексте серверов, то есть, это не подтверждение для конкретного адреса отправителя или пользователя почтовой системы.

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

Логика работы DKIM такая: отправляющий сервер, используя секретный ключ, вычисляет подпись для некоторых технических элементов, составляющих сообщение электронной почты, встраивает значение подписи и вспомогательные сведения в состав сообщения (в так называемый “технический конверт”, который не виден для обычных пользователей), отправляет получившееся сообщение. Принимающий (или промежуточный) почтовый сервер, получив письмо, может использовать данные, переданные в DKIM-параметрах, для извлечения из DNS открытого ключа и, собственно, проверки подписи на сообщении. Если сообщение было отправлено сервером, который не имел доступа к нужному ключу, то этот сервер не может вычислить корректную подпись DKIM. В общем-то – всё. Именная принадлежность ключей и других параметров определяется на основании домена-источника. В самом простом случае – это домен почтового адреса, указанного в качестве отправителя письма. Тут, впрочем, есть технические тонкости, опять же, невидимые для типичного пользователя, но их сейчас можно пропустить: будем считать, что если в письме нужным способом указан адрес отправителя user@test.ru, то домен-источник – test.ru, для него и публикуются ключи в DNS (они публикуются в TXT-записях для специального имени-селектора).

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

Для того, чтобы администратор почтового домена мог типовым машиночитаемым способом опубликовать рекомендации по обработке поступающих сообщений другими серверами – придумана спецификация DMARC (Domain-based Message Authentication, Reporting, and Conformance). Опять же, это спецификация, описывающая способы публикации политик обработки почты, формат записи и принципы интерпретации. DMARC – это текстовая строка определённого формата, опубликованная в TXT-записи. DMARC предназначается для использования вместе с DKIM и SPF (Sender Policy Framework – здесь не рассматривается). Но, каким бы странным это ни показалось: публикация DMARC никак не зависит от DKIM, и наоборот. Внедрение DKIM на сервере-отправителе, отправка сообщений с DKIM – возможны без публикации DMARC, а публикация DMARC и эффективное использование – возможны без соответствующего по именам внедрения DKIM (пример – см. ниже). Естественно, DMARC и DKIM рекомендуется применять вместе: если вы настроили DKIM, то очень неплохо будет опубликовать и сведения политики в DMARC, поскольку эти сведения могут подсказать принимающему серверу, что ему делать с полученными из вашего домена письмами. Тем не менее, проверка DKIM не требует извлечения сведений DMARC. А DMARC может применяться без фактической поддержки DKIM.

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

Ключевым моментом эффекивности DMARC является не состав политики, а то, поддерживается ли DMARC принимающим сервером, а если поддерживается, то как именно. Сама по себе публикация сведений DMARC не обязывает принимающий сервер не только следовать опубликованным политикам, но даже и запрашивать их из DNS: для приёма и обработки сообщений это не требуется (как не требуется и возможность обработки DKIM). Конечно, грамотно настроенный сервер должен обрабатывать и DKIM, и DMARC, однако такая настройка вовсе не обязательно означает, что письмо без DKIM будет молчаливо отброшено, если принимающий сервер обнаружит политику reject в DMARC. Другими словами: DMARC носит более чем рекомендательный характер, поэтому целиком полагаться на указание политики обработки нельзя.

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

Там присутствует буква ипсилон, снабжённая, кроме знака акцента, двумя “точками” (нет, это вовсе не смайлик). Эти две “точки” называются “трема” (или “диерезис”) и вполне себе используются при записи древнегреческого (и даже английского, см. ниже), обозначая разделение гласных. Однако в данном случае дело явно хитрее. В современной типографике соответствующий фрагмент (середина второй строки) выглядит вот так: μετὰ τὸν πρῶτον ὕπνον, что означает “после первого сна”. Над ὕ должен быть знак придыхания, а на рукописном скриншоте знак ударения присутствует отдельно (сверху), соседних гласных нет, так что назначение второй “точки” не ясно. Тем более, что в этом же манускрипте в других сходных случаях двух точек над υ обычно нет, но иногда – встречаются. Это известное, – но какое-то загадочное, – явление, относящееся ещё и к букве ι в манускриптах на древнегреческом. Кстати, “сон” здесь – это тот самый “гипноз”: знак придыхания над ὕ, который объясняет одну “точку”, как раз трансформировался в русское “ги”. А в английском, например, hypnosis.

Трема/диерезис встречается при записи английского, но является большой экзотикой, о которой мало кто знает. Собственно, “Ё” даже в русском-то сейчас используют редко, зато аналогичное, редкое, сочетание знаков есть в английском. Посмотрите: coöperate, сöworker и reëlect. Здесь трема как раз делает “отделяемым” звук, обозначаемый второй буквой. Этот знак тут нужен для того, чтобы не было reel в reëlect и “коровы” (cow) в co-worker. Сейчас, конечно, приём считается устаревшим, а компенсировать можно дефисом.

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

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

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

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

Если вспомнить математическую часть алгоритма, то речь про вычисление y = A^x (mod M). Обратите внимание на значение A (натуральное число), которое задаёт конкретную схему аппарата для запуска алгоритма Шора! При последовательном вычислении y = A^x (mod M), если показатель x пробегает достаточное количество значений, результат (y) начнёт повторяться, это теоретико-числовая польза от алгоритма, потому что позволяет определить, при каком x A^x == 1 (mod M) и т.д., этому как раз соответствует период данной функции, который мы хотим определить квантовой машиной. Конечно, в случае квантовой машины, никаких подобных вычислений нет: такая машина – супераналоговый прибор, возможно, что ламповый, но скорее холодный, чем тёплый: выход в квантовую ирреальность почему-то требует низких температур. В общем, не предполагается, что происходят какие-то шаги, кто-то переключает реле и сигналы, а на вход “блока функций” поступают разные “иксы”, пусть даже и параллельно. Нет, напротив, подключается несколько миллионов (предположим) загадочных “гейтов”, объединённых в схему, задающую функцию для проверяемого значения A, и всё – предполагается, что в финальном измерении через схему пройдёт поток вероятности, который преобразуется нужным способом и выльется во второй регистр.

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

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

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

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

(См. также про алгоритм Шора и Вселенную кубиками.)

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

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

Пока что с Firefox это не сработало: пользователи всё поняли правильно и даже возмутились. Не факт, что это будет иметь долгий эффект: интернеты становятся “корпоративными”, в том числе, на стороне клиента. Нужно ли ожидать рекламных пауз в ядре Linux? Риторический вопрос.

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

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

За несколько лет я написал некоторое количество полезных статей об интернет-технологиях на сайт ТЦИ, вот ссылки и краткие пояснения:

Certificate Transparency в современном Интернете
Статья о Certificate Transparency (CT). Это довольно техническая статья, которая, впрочем, рассказывает не столько о методах построения CT (про это и так много написано), сколько о не самых очевидных особенностях работы данной технологии на практике: полноте логов, реальному значению технологии в случае малого количества УЦ и т.д. (Отдельно рекомендую почитать, как весьма актуальную, и в стиле “на “Хабре” такого не пишут”.)

Сертификаты удостоверяющих центров TLS
Небольшая статья о том, какие и почему встречаются сертификаты УЦ.

Доступ к скрытым TLS-сервисам: Encrypted Client Hello
Encrypted Client Hello (способ сокрытия метаинформации в TLS) с примерами и описанием принципов построения, назначения, а также перспектив.

DNS в качестве инструмента публикации вспомогательной информации
Использование DNS-записей для публикации информации о настройках и свойствах других интернет-протоколов: типы DNS-записей, примеры и др. Речь про TXT для DKIM/DMARC, про SSHFP и подобные малоизвестные, но весьма полезные, записи.

DNSSEC: доверие по цепочке
Популярное описание DNSSEC, на которое можно ссылаться.

DNS-доступ под защитой: DoT и DoH
Принцип работы и способы применения технологий DNS-over-TLS и DNS-over-HTTPS, их место в общей “парадигме” инструментов защиты информации.

TLS 1.3 на веб-узлах Рунета
Количественная оценка распространённости узлов с корректно настроенным протоколом TLS версии 1.3 и валидным TLS-сертификатом в зонах .RU, .SU и .РФ. Данные актуальны на 2020 год.

Заголовки HTTP и их роль в обеспечении безопасности
Описание HTTP-заголовков, предназначенных для повышения безопасности доступа к сайтам. Content-Security-Policy и др.

ESNI как защита TLS от утечек метаинформации
Подробный рассказ про ESNI. Это 2019 год, с тех пор от ESNI отказались, но статья представляет исторический интерес.