Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Обнаружились подозрительные TLS-сертификаты, валидные для IP-адреса 1.1.1.1 (в поле SAN), но, видимо, выпущенные без согласия компании Cloudflare, являющейся оператором адреса. Один из сертификатов довольно свежий – 26 августа этого года. Выпущены эти сертификаты УЦ (Удостоверяющим Центром), ключи которого, как пишут, входят в список доверенных Microsoft Windows (но не Mozilla, и не Google Chrome).
Эти сертификаты могут быть тестовыми – на такую мысль наводят использованные в них имена доменов. IP-адрес 1.1.1.1 кто-то мог ввести в качестве заглушки: по “старинной традиции” этот адрес многие воспринимают как “невозможный”. В любом случае – УЦ должен проверять право управления для всех имён и адресов, указываемых в сертификате, так что, если это тест, то он, к сожалению, не прошёл.
Такой сертификат, при наличии секретного ключа, позволяет незаметно для пользователя перехватить TLS-трафик в сторону IP-адреса 1.1.1.1, который соответствует нескольким глобальным сервисам Cloudflare (DNS-резолвер и VPN-сервис, как минимум). Чтобы перехват сработал – клиентское ПО должно считать ключи УЦ доверенными, так что, получается, в такой конфигурации сработает только для Windows (ну или только в браузере Edge, если он использует отдельный набор корней, а сама ОС этому УЦ не верит).
Комментировать »
В свежей версии браузера Chrome (140) включен механизм сокрытия IP-адреса при помощи прокси-серверов. Пока что доступно только в режиме Incognito, и лишь для некоторых имён хостов (это важный аспект – см. ниже), которые, в контексте веб-страницы, являются “третьей стороной”: то есть с этих узлов загружаются какие-нибудь дополнительные ресурсы, а основной домен просматриваемого веб-узла при этом другой.
Проксирование предоставляет Google. Идея в том, чтобы помешать внешним веб-узлам отслеживать пользователей через подобные запросы (IP-адрес всё ещё остаётся важным источником меток для идентификации). Я писал об этой технологии Google пару лет назад – по сути, это наложенная сеть для доступа к вебу.
Интересно, что сейчас применение маскирования IP обещают по списку доменов, который доступен на Github; в этом списке, на момент написания записки, значится почти весь “официальный” веб от “Яндекса” (yandex.ru, mc.yandex.com, yandex.st и др.), а кроме того: vk.com, mail.ru и прочие, хорошо узнаваемые в Рунете, доменные имена.
Комментарии (4) »
Опубликовал тут на “Хабре” популярный обзор про время в прикладной криптографии. Это, можно сказать, по мотивам недавней записки на ту же тему.
Комментировать »
Сейчас, когда говорят про генерирование силами LLM текстов студенческих работ, называют этот процесс “использованием ИИ”, но при этом, помимо проведения аналогий с калькуляторами, нередко сравнивают ситуацию с тем, как студенческую работу, вместо нерадивого студента, пишет кто-то ещё, третье лицо: мол, всё равно же такая практика существует. Да, такое случается, факт. Случается, но точно не одобряется. Да. В отличие от интенсивно навязываемого “использования ИИ”. И вот в случае с интерпретацией этого использования уже наблюдаются странные обратные моменты: сравнивать-то с написанием работ чужими силами – сравнивают, но при этом преподносят использование ИИ уже как одобряемую и необходимую тактику; про выдачу текста в обмен на “промпт” – говорят, но уже утверждают, что это работа искусственного интеллекта и “современные методы”, а вовсе и не генерирование текста перебором в синонимайзере.
Комментировать »
Добавил в перечень избранных записок (за все времена dxdt.ru) ещё десять:
Комментировать »
Дистрибутивность умножения относительно сложения означает, что 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 работает в действительных числах”.
Комментировать »
В августе 2010 года, пятнадцать лет назад, в небольшой заметке про DNSSEC, я, действуя несколько неосторожно, предположил буквально следующее:
До нового Интернета остались такие шаги (думаю, в таком порядке, как они перечислены дальше): DNSSEC на клиентах (года два на выполнение), строгое подписывание анонсов BGP и криптографическое удостоверение AS-ок (три-пять лет), переход подавляющей части трафика на IPv6 (пять-семь лет). А может даже и раньше.
Интересно сравнить с реальностью в 2025 году.
DNSSEC на клиентах
Да, тут было очень активное движение в обозначенную сторону. Сделали плагины для браузеров, например. Даже сперва всё уложилось в те самые два года, но, к сожалению, распространения не случилось и постепенно тема замылилась, пусть и не погасла совсем. То есть, что уж там в 2012, но сказать, что DNSSEC повсеместно внедрена на клиентах даже в 2025 году, конечно, нельзя: ландшафт тут вообще перекосило в другую сторону (см. ниже), а технология-то DNSSEC и в DNS-зонах не получила распространения, куда уж там клиентам.
Однако настроить клиентскую поддержку всё же можно, да и движение с переносом валидации на клиента, пусть и самое минимальное, но пока сохраняется: см. например, systemd-resolved в современных линуксах. Что ещё по этой теме есть сейчас? Ну, в те же браузеры собственный интерфейс “DNS-резолвинга” таки встроили, но это DNS over HTTPS/DNS over TLS, где проверка DNSSEC оставлена внешнему провайдеру. Это не очень-то хорошо, но что же поделать? Как минимум, TLS тут даёт какой-то инструмент для трансляции доверия. В общем, если вычесть всякие технологические оговорки, массовое внедрение “DNSSEC на клиентах” не случилось, сейчас его нет, так что прогноз про два года, строго говоря, не оправдался. Да и DNSSEC, из-за своей хрупкости, вообще не пользуется спросом в непростое время сегментации интернетов.
Строгое подписывание анонсов BGP и криптографическое удостоверение AS
“Подписывание анонсов” – это имеется в виду “сквозной” и строгий вариант sBGP, когда каждый “хоп” ставит проверяемую подпись. Не случилось. Подвижки тут тоже есть (BGPsec, SIDR Ops и др.), но пока даже нет причин говорить, что реализация как-то близка. Причины банальные, как ни странно: мало кому это нужно; как и в случае с DNSSEC – технология хрупкая, это многих пугает; большой риск централизации – тоже не особо хорошо в ситуации, когда идёт битва за банхаммер.
Сейчас одна деятельная сторона, – которая есть исторически сложившаяся, старая часть основателей интернетов, – укрепляется во мнении, что “это наша сеть, в которую мы если разрешаем подключиться кому-то ещё, то только тем, кто себя ведёт так, как мы считаем правильным, и при этом не топчет мрамор пола пусть и чистыми, но всё равно же – лаптями”, а главное – сохранить возможность разрешать подключение на основании детектирования типа обуви. Другая деятельная сторона – ещё хитрее: эта сторона использует глобальность Сети для создания собственных “больших интранетов”, чему немало способствует деятельность стороны первой: потому что вы не можете строить локальный сегмент, когда нет нужной глобальности, относительно которой сегмент и определяется, как локальный. В общем, битва кита со слоном и океан замутила, и на суше подняла пыль: ситуация в целом не очень-то хорошая складывается, так что не до подписывания анонсов BGP. Подписывания нету, и в этой части – прогноз не сработал совсем.
Зато вот с “криптографическим удостоверением AS”, которое есть RPKI (удостоверение при помощи цифровой подписи права быть источником (origin) для IP-префикса), прогресс за пятнадцать лет очень большой: поддержка RPKI для IP-префиксов не только перестала быть исключительной редкостью на стороне AS, но даже и для фильтрации реально используют (но не все, не везде). Вероятно, так случилось потому, что RPKI – несколько более централизованная технология. Так что в этой части, хоть и не через “три-пять” лет, но прогноз близок к реальности.
IPv6 как транспорт для подавляющей части трафика
Тут я уже осторожно указал дистанцию в пять-семь лет по времени, и через пятнадцать лет у нас трафик по IPv6 в Интернете большой, но не подавляюще большой. Популярность IPv6 выросла очень сильно, факт, но этот протокол “всё ещё продолжает идти на смену IPv4” (как вы знаете, адреса для последнего за это время успели закончиться раз пять или семь, как раз по числу лет в интервале ожидания моего прогноза). В общем, нельзя сказать, что совсем не сработал этот прогноз – использование IPv6, как и количество передаваемого по этой версии IP-трафика, в 2017 году относительно 2010 возросло в разы, а ещё больше – сейчас, в 2025. Однако не похоже, что прогноз сработал полностью: для dxdt.ru всё ещё нет AAAA-записи (но есть один авторитативный NS с AAAA).
Интернет сильно поменялся. Особенно, за пять лет периода 2020-2025. Но эта записка посвящена ретроспективе заметок dxdt.ru, так что обсуждение прочих изменений – оставим для других записок.
Комментировать »
Один из очень мощных методов обработки радиосигналов, повышающей возможности радаров, это синтезирование апертуры антенны. Общие приципы этого метода я описывал на dxdt.ru. Вот, например, записка 2008 года. Если совсем кратко, то идея синтезирования апертуры такая: станем записывать сигналы в разных точках некоторой траектории, а потом синхронно обработаем результаты записи, учитывая координаты точек, для которых отдельные элементы были записаны. При выполнении некоторых условий – полученный результат будет близок к результату физической антенны, размер которой соответствует дистанции, пройденной при записи. То есть, пролетел отдельный приёмник с малой антенной двадцать метров – результаты синтезирования позволяют получить виртуальную двадцатиметровую антенну.
С синтезированием апертуры связан ещё один интересный аспект: для синтезирования необходимо движение, но двигаться может не только радар. Напротив, двигаться, относительно радара, – и, обычно, некоторого “фона”, подстилающей поверхности, – может наблюдаемая цель, а её движение как раз создаст “базу” для синтезирования сигнала. Это метод обратного синтезирования апертуры. Алгоритмы используются существенно более сложные, но метод неплохо подходит для распознавания и классификации типов движущихся целей. Особенно, на море, в отношении больших кораблей. Поэтому использованием обратного синтезирования особенно известен штатовский P-8 Poseidon – морской самолёт радиолокационного наблюдения, на котором применяется специальная, подвешиваемая под фюзеляж, наружная система РЛС AN/APS-154 (AAS).
Обратное синтезирование позволяет получить достаточно высокую разрешающую способность, которая, при этом, ещё и мало зависит от дальности до цели. Представьте, что радар принимает сигнал, отражённый некоторым объектом, имеющим достаточно большие линейные размеры. Пусть на объекте установлены какие-то мачты или башенки. Не так важно, что именно – главное, чтобы были геометрически обособленные элементы. Если этот объект движется относительно приёмника радара, то в разные моменты времени углы, под которыми со стороны приёмника видны эти элементы, будут меняться. Ещё лучше, если объект вращается: тогда и скорость изменения углов вырастет, и существенная разность возникнет для многих элементов. И изменение углов, и относительное движение элементов объекта, возникающие в системе координат, привязанной к приёмнику радара, означают, что во времени будут изменяться характеристики отражённого разными элементами зондирующего сигнала: будет сдвигаться фаза, изменяться частота (доплеровский сдвиг).
Синтезирование апертуры подразумевает запись сигналов на протяжении некоторого интервала времени – интервала синтезирования. Отдельные элементы реальных объёктов – это их, так сказать, упрощённое “пиксельное” представление, используемое в расчётах: в современной вычислительной радиолокации, естественно, нет никаких непрерывных областей пространства или непрерывных сигналов – всё разбивается на дискретные элементы, как по времени, так и по частоте. Соответственно, вычислитель приёмника, синтезируя записанные сигналы, использует изменения фазы и частоты, чтобы при помощи цифровой обработки собрать размытые сигналы в общий результат, с высокой разрешающей способностью.
Вообще, при обычном (прямом) синтезировании, достаточно быстро движущиеся цели дают “растянутые” вдоль некоторой траектории отметки, поскольку на интервале синтезирования успевают изменить пространственное положение (за этим эффектом стоит несколько способов селекции движущихся целей). И вот обратное синтезирование позволяет такие отметки собрать в единое изображение с дополнительными деталями. Современные радары – вычислительные, так что методы прямого и обратного синтезирования могут применяться РЛС параллельно и синхронно (см. ниже).
Понятно, что многие типы целей заведомо содержат элементы, за которые можно хорошо “зацепиться” при обработке: летательные аппараты, находящиеся в воздухе, активно маневрируют, а вертолёты ещё и быстро вращают лопастями. Корабли – раскачиваются на волнах, это эквивалентно вращению, а надстройки, мачты, антенны – всё, таким образом, даёт сильные “разностные” сдвиги: при определённых ракурсах наблюдения и движении корабля – разные отметки, соответствующие элементам конструкции, могут вообще двигаться в разных направлениях (относительно приёмника, конечно).
Проблему представляет определение параметров движения: всякое синтезирование апертуры требует некоторого опорного базиса, чтобы можно было вычислять изменения. Если это “обычное” синтезирование, то собственное положение и приёмника, и передатчика могут с высокой точностью записываться. Но когда речь про обратное синтезирование, да ещё и в отношении произвольной цели, которая свою траекторию не собирается передавать наблюдателю, возникают трудности.
Характеристики движения наблюдаемой цели можно измерить дополнительно: да, какую-то информацию даёт доплеровский сдвиг, но доплеровский эффект и так используется при синтезировании, так что возможности не так уж велики. Однако никто не запрещает определять базовые параметры движения при помощи дополнительных сигналов, а в случае достаточно продвинутых РЛС – пытаться вычислительно оптимизировать сигнал, фактически, перебирая разные варианты в поисках минимальных расхождений между базовыми точками, которые, для того же объекта, наблюдаются вспомогательными приёмниками. Можно также использовать сигнал от подстилающей поверхности в качестве опорного, вычисляя разность “от фона”. Так как наблюдаемый объект, в подавляющем большинстве случаев, и достаточно жёсткий (то есть, “хвост” не изгибается до “носа”), и несравнимо больше длины электромагнитной волны зондирующего излучения (типичная длина волны здесь – это сантиметры), то определять характеристики движения можно точно даже без высокого разрешения по углу. Почему – без? Потому что именно получение высого углового разрешения в рамках изображения одного объекта и является конечной целью обратного синтезирования апертуры: получив “картинку” с характерным силуэтом можно автоматически распознать тип наблюдаемого объекта.
Комментировать »
Пишут (англ.), что Google собирается для всех разработчиков приложений под Android на google-сертифицированных устройствах потребовать регистрацию аккаунта и регистрацию ключей подписи. Регистрация, конечно, должна быть в корпорации Google. Иначе приложения невозможно будет устанавливать (механизм реализации запрета пока не описан, но это ведь детали). Разработчик должен регистрироваться и получать разрешение даже в том случае, если приложение не распространяется через Google Play, а публикуется каким-то сторонним сервисом. Фактически, всё идет к тому, что самостоятельно разработанное приложение нельзя будет без регистрации аккаунта разработчика установить на самостоятельно же приобретённое устройство (такое вот очередное подтверждение того, что “собственный” смартфон вовсе и не принадлежит, как система, купившему его пользователю).
Этого, конечно, следовало ожидать: эффективны именно ограничения по конкретным источникам исходного приложения, а не по “витринам-магазинам” (к которым относится и Google Play). “Витрины-магазины” можно обойти, как-то ещё раздавать код, другими способами. Но если в процессе подтверждения подпись от ключа разработчика проверяется всегда относительно некоторого центра доверия, встроенного в систему, то уже нет разницы, откуда взят сам код приложения.
Сверять цепочки подписей с “регистрацией”, конечно, будет вовсе не пользователь устройства, а центральный системный сервис. А отключение разработчиков от этого сервиса возможно, в том числе, по результатам очередных “широких санкций”: например, сервис ранней регистрации, который предлагает Google для этой программы, похоже, с российских IP-адресов уже сразу недоступен.
В статье Ars Technica (по ссылке выше) пишут, что Google, якобы, не планирует проверять само приложение (как в случае с Google Play). Но это вряд ли, что оно так будет. По крайней мере, в сопроводительных документах Google написано, что для бесплатных аккаунтов введут ограничения и по количеству приложений, и по количеству установок. Дело в том, что, технически, цифровой подписью всегда подписывается конкретная сборка (нельзя подписать произвольный идентификатор, который автоматически привяжется ко всем возможным вариантам – такого не предусмотрено). Поэтому и провайдер системного сервиса проверки вполне может регистрировать в центральном репозитории тоже только конкретные сборки, по отпечатку. А это эквивалентно проверке кода приложения: по результатам – можно отключить и аккаунт, и сами приложения удалить с пользовательских устройств.
Комментировать »
Я использую для чтения RSS полезный инструмент Tiny Tiny RSS, который работает в контейнере на внешнем сервере. И вот с некоторых пор пропал с этого сервера доступ к feeds.feedburner.com: где-то кто-то заблокировал, похоже. Из иностранных сетей доступ есть, но упомянутый сервер в российской сети, с российским IP. Проблема тут в том, что на feedburner.com “редиректит” трансляции своих корпоративных блогов Google. Непонятно зачем. А так как нынче в интернетах блокируют со всех сторон, то сразу и не скажешь – где именно оно закрыто, но возможно, что это для российских IP на стороне feedburner.com (который тоже Google, так что ничего удивительного, если так).
(Update, 28/08/2025: похоже, всё же, что вряд ли именно это – блокировка на стороне Google, по географической принадлежности IP: потому что из других россиских сетей доступ есть. Детали выяснить так и не удалось.)
Комментарии (3) »
Новый 