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

Дистрибутивность умножения относительно сложения означает, что a*(b + c) = a*b + a*c. В действительных числах, по определению, умножение дистрибутивно относительно сложения. Запишем это на Pyhton и посмотрим, что напечатает простая программа.

import math

q = 11*(math.sqrt(5) + math.sqrt(17))    # q = a*(b + c)
p = 11*math.sqrt(5) + 11*math.sqrt(17)   # p = a*b + a*c
print(p == q)                            # q == p => (q - p) == 0

q = 34*(math.sqrt(5) + math.sqrt(17))
p = 34*math.sqrt(5) + 34*math.sqrt(17)
print(p == q)                            # ???

Запускаем (Python 3.11.2) и смотрим:

True
False

В коде, в первом случае, написано:

p = 11*(√5 + √17),
q = 11*√5 + 11*√17.

Значения p, q сравниваются. Программа выводит True – значения равны. Что и следовало ожидать, если бы это были действительные числа: по определению, q и p – это одно и то же число.

Во втором случае написано всё то же самое, алгебраически, но другой множитель:

p = 34*(√5 + √17),
q = 34*√5 + 34*√17.

Удивительно, но результат сравнения p и q теперь False – числа не равны.

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

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

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

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

Почему это важно? Потому что алгоритм, построенный “в действительных числах” с дистрибутивностью, не будет правильно работать на реальном компьютере. Во float возникает плохое “ветвление”: например, там, где по определению действительных чисел должен быть всегда нуль, внутри float получаем нуль в одних точках, ненулевой результат – в других. Скажем, если вернуться к примеру выше, будем вычитать q из p. Ещё актуальный пример: представьте, что программа какой-нибудь нейросети обрабатывает миллиарды коэффициентов, но разработчик принял, что эта программа “работает в действительных числах” и поэтому разработчик не то что не учитывает, но даже и не рассматривает возникающие искажения.

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

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

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

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

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

С этими ИИ-LLM, “которые заменят всё и вся”, сейчас больше всего не радуют следущие моменты.

1.

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

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

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

2.

Большое количество явно сгенерированных LLM текстов, которые выдают за “оригинальные тематические статьи” – с примерами кода (неверного), с “математическими” утверждениями, очевидно абсурдными, но записанными при помощи терминов из техничного языка (сам техничный язык – не наследуется).

Как ни странно, но тексты, сгенерированные современными продвинутыми LLM, нередко узнать даже проще, чем результаты работы старинных “генераторов рефератов”: это связано с тем, что современные LLM выдают в тексте структуры “большего объёма” – оформление, построение блоков текста, все эти навязчивые, регулярные разбивки на “Почему {подставить описание}” – следует три описания “причин”, с обязательным оформлением в виде списка и “типографским” выделением фрагментов. При этом тексты написаны неплохим языком, но содержат фактические выдумки – даже не ошибки (“Not even wrong!”). Старые “генераторы рефератов” выдавали менее структурированный мусор, который больше похож на неудачный, но подлинный текст, написанный не слишком подготовленным человеком.

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

3.

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

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

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

И это вот одна из явных угроз ИИ: в какой-то момент скажут, что всякая выдача LLM является верной, и даже уточнять эту выдачу может только другая LLM, но не человек, который, как давно написано в газетах, “ничего понять не сможет”.

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

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

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

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

Но, всё же, нетрудно найти и конкретные примеры, когда возможности физического эксперимента по быстрому завершению процесса превосходят возможности классических компьютеров по моделированию исхода этого же эксперимента. У Ричарда Борчердса есть прекрасная иллюстрация (YouTube, англ.): квантовые вычисления на фарфоровом чайнике. Фарфоровый чайник, упавший на бетонный пол, разбивается существенно быстрее, чем суперкомпьютер успевает предсказать конфигурацию осколков чайника. Но только лишь из этого наблюдения – не следует обратное: что, мол, можно подключиться к сверхмощному вычислителю внутри чайника, чтобы использовать его для решения других задач.

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

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

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

Такие вычисления могли бы выполняться быстрее, чем на суперкомпьютере в той же симуляции, поскольку суперкомпьютер обсчитывается более медленными фрагментами кода на стороне гипервизора. Почему это так? Потому что суперкомпьютер построен из отдельно моделируемых кусочков – транзисторов внутри симуляции и тому подобных элементов. Реализация каждого элемента требует ресурсов. Это как модель компьютера на “редстоун-релюшках” в Minecraft: работает, но очень медленно. А вот вычисление конфигурации осколков чайника – вселенский гипервизор реализует непосредственно, на своей аппаратуре. Могли бы это и быть “квантовые вычисления”? Да, вполне.

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

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

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

(Это версия статьи, которую я вчера разместил на “Хабре”.)

Современное объединение вычислительных IP-сетей, ранее известное как “Интернет”, обладает интересными особенностями, которые прямо связаны с практической трактовкой термина “сетевая прозрачность” разработчиками приложений.

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

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

Теперь не просто уровни перемешиваются (я как-то про это писал отдельно), но особенности, проявляющиеся в результате анализа поведения сети за сокетом, на низком уровне, просачиваются на уровень верхний, который ранее считался “абстрактным”.

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

(Это дополненная и скорректированная версия статьи, которую я некоторое время назад публиковал на “Хабре”.)

Данные в запросах и ответах классической DNS никак не защищены, передаются в открытом виде. DNS-over-TLS (DoT, RFC 7858) предоставляет один из инструментов защиты информации, а именно: защиту DNS-запросов и DNS-ответов от прослушивания на промежуточных узлах.

DoT использует TLS для зашифрования DNS-транзакций, передаваемых между узлами, но не защищает сами DNS-данные. Под “DNS-данными” тут подразумевается состав ответов и запросов DNS: имена и записи. То есть, если ваш локальный компьютер использует DoT для работы с DNS-сервером, то передаваемые DNS-данные не видны “на транзите” (как объясняется ниже, сам факт обмена DNS-данными обычно всё равно виден) и нельзя простым способом узнать, для какого узла и какие DNS-запросы направлялись. Однако, если DNS-сервер, к которому запросы отправлялись с защитой DoT, возвращает неверные, искажённые DNS-данные, – например, подставляет собственный IP-адрес для, условно, example.com, – то DoT ничего с этим поделать не может – тут уже нужно использовать DNSSEC.

На всякий случай, замечу: DoT – это технология, которая никак не связана с DNS-over-HTTPS (DoH). Архитектура DoT довольно логичная: TLS здесь используется в качестве инструмента создания защищённого “сокета” между DNS-клиентом и DNS-сервером. Через “сокет” передаются те же DNS-запросы/DNS-ответы, как они передавались бы на уровне обычного UDP или TCP. То есть “сокет” с TLS тут нужно считать туннелем, работа которого прозрачна для уровня DNS. Естественно, чтобы использовать DoT в таком прозрачном режиме, нужна поддержка TLS и на клиенте, и на сервере. Однако, поскольку спецификация отводит TLS обособленный уровень (в отличие от DoH), ничто не мешает поднять TLS-соединение между узлами какими-то другим способом, установив тем самым туннель, а запросы/ответы от неподдерживающих TLS клиентов/серверов перенаправлять без изменений через этот туннель.

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

Типовой сценарий работы DNS это так называемый рекурсивный опрос, в котором специальный DNS-сервер (резолвер) производит обход других DNS-серверов (которые называются “авторитативными”), следуя по веткам дерева делегирования с целью поиска данных, соответствующих некоторому ключу. Хрестоматийный пример: в качестве ключа выступает имя хоста (example.com), а целевыми данными является IP-адрес (значение адресной A-записи), то есть, “хотим найти IP-адрес для имени сервера”. DNS правильно рассматривать именно как специальную распределённую базу данных и сервис поиска в этой базе данных. Собственно, сама аббревиатура DNS может расшифровываться двумя способами: Domain Name System и Domain Name Service. DoT – относится к транспорту для сервиса поиска и позволяет защитить трафик каждого DNS-запроса на каждом отрезке. (А криптографическая система на уровне базы данных DNS – это как раз DNSSEC, но DNSSEC не зашифровывает данные.)

Рекурсивный DNS-резолвер, если подходящий ответ отсутствует в кеше, обращается к разным авторитативным серверам Интернета по некоторому довольно сложному алгоритму и, при штатной работе системы, либо получает от сервера нужный ответ о целевом имени, либо получает так называемый делегирующий ответ, который содержит имена других авторитативных серверов и позволяет резолверу продолжить поиск, обращаясь уже к каким-то из этих серверов (откуда и появляется “рекурсия” в названии процесса). При этом рекурсивный резолвер обычно находится за пределами “локальной машины”. В качестве рекурсивного резолвера может выступать сервер провайдера интернет-доступа или публичный сервис типа Google Public DNS 8.8.8.8. На локальной машине DNS-запросы обрабатывает более простая программа – stub-резолвер, который только перенаправляет запросы рекурсивному резолверу (иногда его ещё называют “рекурсор”) и принимает от него ответы. DoT может использоваться на любом участке работы DNS: не только на “последней миле”, то есть на отрезке от локального stub-резолвера к рекурсивному резолверу, но и между авторитативными серверами. Кстати, эта “последняя миля” в современных браузерах как раз часто защищена при помощи DNS-over-HTTPS.

Итак, общая логика работы DoT следующая:

1) произвольный DNS-клиент, если он поддерживает TLS, устанавливает TLS-соединение, подключившись по TCP к DNS-серверу (для UDP есть отдельный вариант – DNS-over-DTLS, здесь можно считать, что он работает так же, как и DoT);
2) DNS-клиент может провести аутентификацию сервера различными способами (см. ниже);
3) если TLS-соединение установлено, то DNS-клиент переходит к отправке DNS-запроса обычным способом, но уже через TLS-соединение;
4) ответ DNS-сервера доставляется в рамках того же TLS-соединения; при этом формат DNS-ответа и прочие свойства – не изменяются, если сравнивать с работой DNS непосредственно по UDP или TCP, без TLS-туннеля (см. ниже);
5) TLS-соединение закрывается, если клиент не планирует использовать его далее.

Для DoT выделен номер порта 853 (классический номер порта DNS – 53). Поэтому клиенты могут сразу пробовать использовать DoT, подключаясь по TCP на номере порта 853. Так как DoT – универсальная спецификация, то такое подключение можно устанавливать и к авторитативным серверам. Но сейчас поддержка DoT на авторитативных серверах является большой редкостью. Тем не менее, DoT поддерживают, например, серверы DNS-зон facebook.com и wikimedia.org.

Практика

Воспользуемся утилитой dig из пакета BIND и посмотрим, как DoT работает вживую на авторитативных серверах. В качестве источника примеров используем зону wikimedia.org, авторитативные серверы имён которой поддерживают DoT.

Утилита dig – это один из типовых инструментов из области DNS. В более или менее современной версии dig умеет в DoT сразу из коробки: нужно просто указывать опцию +tls при вызове. Я здесь использую версию 9.18.33-1 под Raspberry Pi OS (Debian 12).

Сначала определим, на какие серверы делегирована зона wikimedia.org (пока что без DoT), это делается запросом NS-записей (-t NS):

$ dig -t NS +short wikimedia.org
ns1.wikimedia.org.
ns2.wikimedia.org.
ns0.wikimedia.org.

(+short здесь – это краткий формат вывода.)

Наша цель – отправить запрос AAAA-записи (IPv6-адрес) через DoT и получить ответ, посмотрев, с помощью tshark, что происходит в трафике. Кроме того, мы извлечём серверный TLS-сертификат с авторитативного сервера и глянем, что там, в сертификате, написано. Будем использовать авторитативный сервер ns1.wikimedia.org. Однако сначала определим его IPv4-адрес, чтобы DNS-запросы отправлять непосредственно серверу.

$ dig -t A +short ns1.wikimedia.org.
208.80.153.231

Запросили A-запись – получили IPv4-адрес в ответ. Теперь включаем DoT (и тут вообще будет опций побольше, но все они объяснены ниже):

$  dig -t AAAA @208.80.153.231 +tls +nocookie +norec wikimedia.org

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> -t AAAA @208.80.153.231 +tls +nocookie +norec wikimedia.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44438
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; TCP KEEPALIVE: 157.0 secs
; PAD: (388 bytes)
;; QUESTION SECTION:
;wikimedia.org.			IN	AAAA

;; ANSWER SECTION:
wikimedia.org.		300	IN	AAAA	2a02:ec80:300:ed1a::1

;; Query time: 300 msec
;; SERVER: 208.80.153.231#853(208.80.153.231) (TLS)
;; WHEN: Sun Mar 16 18:18:01 MSK 2025
;; MSG SIZE  rcvd: 468

(Опции: +tls - используем DoT, +nocookie - без куки-меток, чтобы не перегружать вывод (DNS-куки не относятся к DoT и тут не рассматриваются: про них планирую отдельную записку опубликовать), +norec - не устанавливаем флаг рекурсии.)

Здесь уже в нижнем информационном блоке видно, что запрос и ответ передавались с использованием TLS, через TCP-соединение на номере порта 853. То есть, это DoT.
Дополнительно подтвердить, что трафик ходил через TLS, можно при помощи tshark, посмотрев в дамп, записанный tcpdump (это два основных инструмента).

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

# tcpdump -i eth0 -w pcap-dns.pcap

Парсинг дампа при помощи tshark:

$ tshark -r pcap-dns.pcap -o tls.keylog_file:keylog.log -O tls,dns -S "-----PACKET-----" -x

Здесь: -r - входной PCAP-файл; -o tls.keylog_file:keylog.log - это импорт сессионных ключей TLS, они потребуются для раскрытия DNS-трафика (про способ экспорта кратко рассказано ниже); -O tls,dns - перечень протоколов для парсера; -S "..." - разделитель "пакетов" в распечатке дампа, можно использовать любую удобную строку; -x - выводить hex-дамп тоже.

В распечатке дампа находим примерно следующее:

Internet Protocol Version 4, Src: 192.168.1.13, Dst: 208.80.153.231
Transmission Control Protocol, Src Port: 36461, Dst Port: 853, Seq: 1, Ack: 1, Len: 303
Transport Layer Security
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 298
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 294
            Version: TLS 1.2 (0x0303)

Это часть сообщения ClientHello, направленного утилитой dig авторитативному DNS-серверу. Соответствующее серверное сообщение ServerHello, которое можно найти в дампе, вместе с возможностью расшифровывать трафик, означает, что узлы успешно установили соединение TLS 1.3. Внутри TLS-соединения передан DNS-запрос и получен DNS-ответ.

Чтобы посмотреть прикладной трафик внутри TLS, нужно экспортировать сессионные ключи - то есть, симметричные секреты, которые стороны использовали для зашифрования трафика. Конкретный способ экспорта зависит от параметров сборки dig и системного окружения, но обычно достаточно установить переменную окружения SSLKEYLOGFILE, чтобы dig, при использовании TLS, выводила ключи в файл или в STDERR (откуда их можно точно так же скопировать). Механика экспорта TLS-ключей не относится к теме данной статьи, поэтому детали остаются за скобками. А вот выдачу tshark для расшифрованного DNS-трафика - посмотрим. Запрос:

Transport Layer Security
    TLSv1.3 Record Layer: Application Data Protocol: Domain Name System
        Opaque Type: Application Data (23)
        Version: TLS 1.2 (0x0303)
        Length: 61
        [Content Type: Application Data (23)]
        Encrypted Application Data: [...]
        [Application Data Protocol: Domain Name System]
Domain Name System (query)
    Length: 42
    Transaction ID: 0xad96
    Flags: 0x0020 Standard query
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..1. .... = AD bit: Set
        .... .... ...0 .... = Non-authenticated data: Unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        wikimedia.org: type AAAA, class IN
            Name: wikimedia.org
            [Name Length: 13]
            [Label Count: 2]
            Type: AAAA (IPv6 Address) (28)
            Class: IN (0x0001)
[...]

Здесь и далее часть данных (опции EDNS и пр.) удалена, чтобы не слишком растягивать распечатку. В блоке Flags можно видеть параметры запроса, как его сформировала утилита dig. А в блоке Queries (сам запрос) - имя wikimedia.org. и состав запроса IN AAAA. Обратите внимание на поле [Application Data Protocol: Domain Name System]. Вообще, то, что TLS-сессия используется для DoT, видно не только по номеру порта, но и по идентификатору протокола уровня приложений, который dig передаёт в составе начального TLS-сообщения ClientHello. Выглядит это вот так:

Extension: application_layer_protocol_negotiation (len=6)
  Type: application_layer_protocol_negotiation (16)
   Length: 6
    ALPN Extension Length: 4
    ALPN Protocol
     ALPN string length: 3
     ALPN Next Protocol: dot

ALPN - это Application Layer Protocol Negotiation, расширение ClientHello, которое позволяет сразу сообщить серверу, какой именно прикладной протокол будет использован поверх этого соединения. Для DoT зарезервирован идентификатор 0x646F74 (то есть, строка "dot" в ASCII). Расширение передаётся в открытом виде, поэтому системе, инспектирующей трафик, нетрудно классифицировать TLS-сессию как сессию DNS: номер порта и идентификатор протокола - этого вполне достаточно. Понятно, что ни TLS, ни DoT и не ставят своей целью сокрытие факта соединения.

Просматривая выдачу tshark далее, находим DNS-ответ:

Transport Layer Security
    TLSv1.3 Record Layer: Application Data Protocol: Domain Name System
        Opaque Type: Application Data (23)
        Version: TLS 1.2 (0x0303)
        Length: 487
        [Content Type: Application Data (23)]
        Encrypted Application Data: [...]
        [Application Data Protocol: Domain Name System]
Domain Name System (response)
    Length: 468
    Transaction ID: 0xad96
    Flags: 0x8400 Standard query response, No error
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .1.. .... .... = Authoritative: Server is an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... 0... .... = Recursion available: Server can't do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... ...0 .... = Non-authenticated data: Unacceptable
        .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 1
    Queries
        wikimedia.org: type AAAA, class IN
            Name: wikimedia.org
            [Name Length: 13]
            [Label Count: 2]
            Type: AAAA (IPv6 Address) (28)
            Class: IN (0x0001)
    Answers
        wikimedia.org: type AAAA, class IN, addr 2a02:ec80:300:ed1a::1
            Name: wikimedia.org
            Type: AAAA (IPv6 Address) (28)
            Class: IN (0x0001)
            Time to live: 300 (5 minutes)
            Data length: 16
            AAAA Address: 2a02:ec80:300:ed1a::1
    Additional records
        : type OPT
            Name: 
            Type: OPT (41)
[...]
            Option: EDNS TCP Keepalive
                Option Code: EDNS TCP Keepalive (11)
                Option Length: 2
                Option Data: 0622
                Timeout: 1570
            Option: PADDING
                Option Code: PADDING (12)
                Option Length: 388
                Option Data: 00…
                Padding: 00…

Это исходник DNS-ответа, который был отображён dig (см. распечатку выше). Обратите внимание на секцию "опций", вот её копия из выдачи dig:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; TCP KEEPALIVE: 157.0 secs
; PAD: (388 bytes)

Здесь мы, например, без труда видим, что параметр TCP Keepalive имеет значение 157 секунд, как и в распечатке tshark, а дополнение (padding) совпадает по длине (388 октетов). Как нетрудно догадаться по названию, TCP Keepalive содержит указание на интервал времени, в течение которого сервер (в данном случае) готов поддерживать контекст TCP-соединения, чтобы клиент мог реализовать конвейеризацию запросов. К DoT это относится весьма косвенно, но зато служит прекрасным примером реальной сложности современных DNS-протоколов (про Keepalive в DNS тоже можно написать отдельную статью, как ни странно).

А вот дополнение (padding) к DoT относится в большей степени, чем Keepalive, хоть и так же находится за пределами конкретно DoT. Идея использования дополнения здесь в том, чтобы можно было изменять длину блоков данных, содержащих DNS-транзакции, не влияя на сами транзакции. Если длину блоков выравнивать, то это позволяет сделать семантически разные блоки неразличимыми по длине. Что, кстати, особенно важно, если блоки зашифрованы. Проще говоря, наблюдая трафик, состоящий из разных по длине блоков данных, где длина определяется форматом, можно выстроить корреляцию с конкретными DNS-запросами и ответами по порядку их следования. Ведь параметры известны: длина доменного имени, длина "флагов" и заголовков, количество DNS-записей в ответах и т.д. Это позволит сделать предположения о составе наблюдаемого трафика, даже без раскрытия самого его содержания. Если же вы наблюдаете только ровный конвейер блоков одинаковой длины, в стиле "запрос-ответ, всё в одинаковых коробках", то извлечь дополнительную информацию гораздо сложнее. Естественно, можно при помощи дополнения варьировать длину и так, чтобы, напротив, блоки не были одинаковыми по количеству байтов. Заметьте, что аналогичный механизм выравнивания длины записей с помощью дополнения есть и в TLS 1.3.

TLS-сессия использует серверный сертификат. Для авторитативного сервера ns1.wikimedia.org. TLS-сертификат можно получить из дампа трафика (но, так как там TLS 1.3, придётся расшифровать отдельно), а можно воспользоваться утилитой s_client из OpenSSL: TLS в DoT точно такой же, как и в других случаях, так что s_client сработает прекрасно, нужно лишь подключиться по номеру порта 853, вот так:

$ openssl s_client -connect 208.80.153.231:853

Cертификаты в TLS нужны для аутентификации узлов, то есть для установления подлинности этих узлов. Однако в DoT с сертификатами связаны свои особенности.

Во-первых, спецификация не указывает методов аутентификации, которые обязательно должны использоваться. Основное предназначение TLS-сертификата в том, чтобы привязать открытый ключ сервера к сетевому илмени или адресу. Однако сам TLS-сертификат далеко не всегда полезен для DNS: например, можно ли требовать, чтобы имя авторитативного сервера соответствовало имени в сертификате (как это делается для веба)? В DNS сложно строго сопоставить имена серверов: конкретный контекст DNS-запроса никакого имени сервера не предусматривает - запрос отправляется по IP-адресу. Да, можно наследовать имя из предыдущих запросов и ответов, но получится не самый строгий результат. Поэтому имя из сертификата можно использовать, а можно и игнорировать. Зато TLS-сертификаты для IP-адресов подошли бы неплохо.

Технически, ничто не мешает выпустить сертфикат для IP-адреса. Если говорить про имеющиеся "хорошо известные УЦ", то сертификаты для IP-адресов пока что выпускают неохотно, так как есть трудности с надёжной проверкой права управления адресом, а также с сопровождением. Впрочем, Let's Encrypt обещают довольно скоро сделать автоматические короткоживущие TLS-сертификаты на IP-адреса для всех, используя механизм подтверждения управления адресом чисто по TLS. Это должно позволить в прозрачном режиме привязать ACME-проверку к DoT, не поднимая ненужного, в данном случае, веб-сервера.

Во-вторых, в DoT можно применять дополнительные методы аутентификации, которые не связаны с привычной по вебу инфраструктурой УЦ: например, проверять отпечаток серверного ключа подписи, а не сверять подписи в сертификатах.

В-третьих, DoT использует "приспособительный" подход и к аутентификации, и к TLS в целом. Это то, что в англоязычной традиции называется Opportunistic Security - "если удалось, то обязательно будем аутентифицировать и зашифровывать, а если нет - тогда ладно".

Может показаться, что если серверный сертификат не проверять, то от TLS для DNS нет никакого толку: промежуточный узел может перехватить соединение и подставить свой, произвольный сертификат, подходящий по формату. Однако в случае DoT схема, как минимум, всегда защищает от пассивного прослушивания трафика. Пассивное прослушивание реализовать гораздо проще, чем активный перехват, а защита от утечек через "пассивные" каналы и является основной для DoT. Тем более, если речь идёт о работе с авторитативными DNS-серверами. Защита же от активной атаки может быть реализована на "последней миле", где клиенту, обычно, заранее известны некоторые данные о сервере: имя, ключ и так далее.

Кстати, посмотрим на имена и на интервал валидности сертификата, который вернул сервер ns1.wikimedia.org.:

        Serial Number:
            05:f7:71:aa:08:8e:32:88:0a:71:9c:2d:f3:98:17:e1:d6:aa
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = E5
        Validity
            Not Before: Mar 16 05:02:56 2025 GMT
            Not After : Jun 14 05:02:55 2025 GMT
        Subject: CN = ns0.wikimedia.org

[...]
            X509v3 Subject Alternative Name: 
                DNS:ns0.wikimedia.org, DNS:ns1.wikimedia.org, DNS:ns2.wikimedia.org

Это сертификат, выпущенный Let's Encrypt. Subject пропускаем, смотрим в Subject Alternative Name, где указаны все три имени для трёх авторитативных серверов зоны wikimedia.org., которые мы нашли в самом начале этого экскурса в DoT силами dig.

DoT уже поддерживается основными программными пакетами авторитативных серверов и рекурсивных резолверов. Например, BIND и Unbound. Так что протокол можно внедрять не только на "последней миле", но и на авторитативных серверах, защищая трафик резолверов к этим серверам (и обратно).

Подведём итог. DoT, используя TLS, защищает данные от пассивного прослушивания третьей стороной. Если клиент применяет тот или иной метод аутентификации сервера, то DoT может защитить от активного перехвата и подмены данных. Но всё это работает только на том отрезке, где применяется DoT, а защита TLS не распространяется на сам состав DNS-данных. Чтобы защитить содержательную часть DNS, необходимо использовать DNSSEC, а эту технологию тоже можно изучать при помощи dig на практических DNS-зонах.

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

Способ первый – это требование наличия адресных записей в апексе почтовой зоны. Речь вот о чём: представьте, что доставляющий релей принёс письмо из домена example.com, а принимающий почтовый сервер требует, чтобы для этого example.com была указана A-запись (либо AAAA – не важно). То есть, принимающий сервер смотрит в DNS, обнаруживает, что в example.com нет A-записи и отбрасывает письмо. (Просто закрыть SMTP-сессию в самом начале этот сценарий не позволяет: нужно дождаться, когда клиент скажет, из какого домена, – якобы! – он принёс письмо.) Очевидно, данный способ предполагает, что “настоящие” доменные зоны не могут работать без адресных записей, а если такой записи нет, то и письмо – “подспуфлено”. Но это далеко не всегда так. Почтовый домен – это почтовый домен. Необязательно держать под тем же именем веб-сайт, предположим. Конечно, способ обоснован: пусть спецификация такого и не предписывает, но ведь можно потребовать, чтобы в почтовом домен был опубликован какой-то способ доставки почты, однако просто требовать наличия адресных записей – это слишком строго. Да, при отсутствии MX-записей почта может доставляться по A-записям. Это верно, но это не означает, что наличие Α-записи обязательно, если есть MX-записи. А вот легитимные письма, приходящие из чисто почтового и корректно настроенного домена, оказываются отброшены. Это плохо.

Данная проверка при фильтрации разумна только в том случае, если для почтового домена-отправителя не удалось найти MX-ы. Но обратите внимание, что, вообще говоря, наличие MX-записей, технически, не является обязательным при отправке сообщений: логика фильтрации тут строится на том, что если для почтового домена, из которого, якобы, пришло письмо, не опубликовано методов доставки сообщений, то и письмо-то какое-то липовое. Но наличие DNS-записей не гарантирует, что письма будут приняты. Есть и специальные адреса в стиле no-reply, и прочий /dev/null. Как говорится, ладно, допустим – однако отсутствие-то A-записи при наличии MX уж точно не может служить основанием для отбрасывания письма.

Вообще, изобретательная защита от нежелательных сообщений – мера вполне оправданная. Главное, не переусердствовать. Особенно, в эпоху развитого DKIM и SPF. Эти две упомянутых технологии вполне себе позволяют предоставить достаточные доказательства того, что письмо отправлено с привязкой именно к тому домену, который указан в качестве “источника”. “Источника” тут в кавычках потому, что схема доставки сообщений электронной почты вообще не подразумевает доменов-источников – источником всегда является ближайший к получателю почтовый релей, который, что называется, “приносит письмо по SMTP”. В этом сила email. И этот же момент приводит к перегибам, с которыми приходится встречаться на практике. Всё дело в разнообразных дополнительных проверках, применяемых SMTP-сервером получателя к SMTP-клиенту, который принёс письмо.

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

В только что описанной схеме фильтрации может ещё проверяться состав IP-адресов, полученных в результате резолвинга имён из MX-записей. И если адреса – это какой-нибудь localhost или 0.0.0.0, то письмо, опять же, отбрасывается.

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

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

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

Заметьте, что упомянутые выше SPF и DKIM уже дают довольно строгое “подтверждение домена”. Оно уж точно строже, чем состав списка MX-ов и, тем более, наличие A-записей.

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

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

Всё то же самое применимо и к симметричным алгоритмам: можно построить некоторое ожидание стойкости – например, 64-битный симметричный ключ для какого-то алгоритма можно считать стойким в течение недели. Опять же, условная оценка – многое как раз зависит от алгоритма, от доступных оптимизаций. 2^64 это не так мало, как может показаться: представьте, что специализированный вычислитель проверяет 1000 значений за один такт и работает на тактовой частоте 5 ГГц (зедесь и 1000, и гигагерцы – это всё время), тогда для перебора 2^64 значений потребуется полтора месяца. (А если проверка одного значения занимает много тактов, то и полный перебор сильно затянется для 2^64.)

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

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

Но всё это – время, и в случае утечек оно играет даже две роли одновременно: утечка “по каналу времени” позволяет сократить время перебора.

В продолжение предыдущей записки, про LLM и математические задачи. Google пока тоже не публикует технических подробностей о том, кто там и как перебирал и форматировал решения задач Международной математической олимпиады, чтобы получилась “золотая медаль”, однако, в отличие от OpenAI, в официальном новостном сообщении, есть, хотя бы, небольшие и довольно занятные намёки.

Во-первых, пишут, что использовалась некоторая “параллельная обработка” (parallel thinking) внутри модели, но, насколько можно понять, для подбора готовых решений. Цитата: “Эта конфигурация позволяет модели одновременно рассматривать и комбинировать многие возможные решения до выдачи окончательного ответа, вместо того, чтобы действовать по единственной, линейной цепочке рассуждений”. (This setup enables the model to simultaneously explore and combine multiple possible solutions before giving a final answer, rather than pursuing a single, linear chain of thought.)

Во-вторых, для получения решений провели “дополнительное обучение”, подстроенное для подходящих типов задач, и ввели инструкции, подобранные конкретно под задачи ММО (видимо, этого года – иначе нет смысла уточнять дважды). Цитата: “Мы также предоставили Gemini доступ к корпусу специально отобранных высококачественных решений математических задач и добавили в инструкции некоторые подсказки и советы общего характера о том, как решать задачи ММО”. (We also provided Gemini with access to a curated corpus of high-quality solutions to mathematics problems, and added some general hints and tips on how to approach IMO problems to its instructions.) Это самый интересный кусок из официального сообщения. Его можно понимать и так, что добавили базу с содержанием решений задач именно такого типа, как потом спрашивали, а позже ввели “советы” с ответами конкретных задач. А можно понять и так, что в процессе “настройки” корректировали входные данные, направляя вывод генерации к текстам верных доказательств (перечитайте в исходнике: a curated corpus of high-quality solutions).

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

В продолжение предыдущей записки, про решение задач с Международной олимпиады средствами LLM: самое забавное, что, например, решение для первой задачи ММО-2025, которое сгенерировала “экспериментальная модель”, почему-то содержит ответ в самом начале – то есть, буквально, написано: смысл решения – доказать, что правильный ответ – правильный. Вот этот фрагмент, в виде скриншота (потому что там нужно “рендерить” LaTeX и Markdown):

Далее там идёт очень большой и не очень внятный сгенерированный текст доказательства, перегруженный отступлениями, понимать который довольно сложно, но не потому, что задача сложная, а потому, что много лишнего в “рассуждениях”. Сомневаюсь, что полезно делать его полный разбор. (Нет, сама исходная задача не требует таких больших объёмов для записи решения.)

Небольшое техническое пояснение: первая задача IMO 2025 это комбинаторная геометрия, нужно посчитать возможные варианты покрытия целых точек на решётке прямыми – это один из самых популяных “сеттингов” для олимпиадных задач; соответственно, набор возможных вариантов – {0, 1, 3} – появляется в процессе решения, поскольку составляет основную содержательную часть этого решения: надо понять, что других чисел (это количество подходящих прямых) там не может появиться; и то, что отсутствует 2, это, вообще говоря, не самый тривиальный момент (но и не самый сложный). Так что то, что решение от LLM OpenAI построено на доказательстве верности состава ответа, без указания на то, как этот состав получен, – почему, хотя бы, там не {1, 2, 3}, – выглядит весьма странно.

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

Слушать эфир можно как каким-то одним из имеющихся радиотрактов (WiFi, Bluetooth/BLE, GNSS, GSM и т.д.) или всеми сразу. Современные радиомодули очень чувствительные и избирательные. Если использовать непосредственно функции прошивки радиомодуля, то, вообще говоря, принимать можно далеко не только “логический WiFi”, но и разнообразные другие сигналы, в том числе, сигналы радаров, спутниковых передачиков (подтверждается Starlink) и т.д., и т.п. Да, приниматься могут быть гармоники побочных утечек, но для данной задачи это не важно. Если сомневаетесь, то вспомните историю появления такого направления, как RTL-SDR – там аппаратной основной вообще послужил бюджетный ТВ-тюнер. (Замечу, в скобках, что даже если в пользовательском интерфейсе смартфона указано, что соответствующие радиомодули “отключены”, это не означает, что они реально отключены – реально отключить можно было бы только в специальной архитектуре, аппаратной кнопкой, но таким практически никто не пользуется, да и кнопка не даёт полной гарантии.)

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

Теперь на сервере, зная возможности приёма и принципы распространения радиоволн, можно вычислять где какие метки в эфире были видны – то есть, выполнять геолокацию идентификаторов. Устройства-наблюдатели ведь будут видеть и друг друга, и базовые станции сетей мобильной связи. Сопоставляя данные от разных мониторов, географические координаты которых известны точно, получится определить, где находились и устройства-наблюдатели, и источники радиосигналов, которые эти наблюдатели обнаружили в эфире. Метод основан на переборе конфигураций, в которых многие наблюдатели могли принимать одни и те же сигналы, чтобы в итоге получилась такая же картина, как та, что поступила с нескольких мониторов.

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

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