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

В Chrome свежих версий добавлена экспериментальная поддержка “постквантового алгоритма” получения общего симметричного секрета для TLS 1.3 – X25519Kyber768. Это гибридный вариант, в котором в дополнение к “обычной” схеме X25519 используется криптосистема Kyber с заявленной высокой стойкостью ко взлому на гипотетическом универсальным квантовом компьютере (естественно, в дополнение к классической стойкости).

Технически это работает следующим образом: при установлении TLS-соединения Chrome добавляет в начальное сообщение ClientHello клиентскую часть данных X25519Kyber768 (и, естественно, индекс данной криптосистемы указывается в перечне поддерживаемых), если TLS-сервер может использовать данную криптосистему, то он выбирает соответствующий ключ из ClientHello, вычисляет симметричный секрет и использует его на дальнейших этапах. Это работает для TLS 1.3, при этом никак не изменяет каких-то других аспектов процесса установления соединения – не влияет на сертификаты и ключи к ним, не меняет шифров и т.д. На серверной стороне – обещают поддержку от Cloudflare и на некоторых узлах Google. Не вдаваясь в детали, можно смело считать, что X25519Kyber768 – это просто присоединение байтов секрета, полученного Kyber768, к байтам секрета, полученного X25519, на входе функции вычисления ключей для симметричного шифра, в полном соответствии с имеющейся схемой преобразования симметричных ключей TLS 1.3. То есть, схема, как минимум, не хуже криптосистемы X25519, которая уже давно используется, но не обладает постквантовой стойкостью (поскольку это вариант протокола Диффи-Хеллмана с логарифмированием в группе точек эллиптической кривой).

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

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

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

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

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

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

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

Пишут, что в Microsoft не сумели корректно поменять SPF-запись для hotmail.com, а поэтому почта из данного домена попадает в категорию “Спам”. Детали я не проверял, но, похоже, IPv6-блоков в SPF там сейчас нет совсем. SPF – среди магических методов Нового Средневековья.

(Update: починили, через полсуток.)

Что касается STARTTLS. Для доставки электронной почты между почтовыми серверами в Интернете повсеместно используется протокол SMTP. SMTP – это “текстовый протокол”, то есть, его работа основана на командах, отправляемых в виде человекопонятного текста (ну, с точностью до числовых кодов состояний, которые, впрочем, тут тоже записываются ASCII-текстом) через любой подходящий транспорт. Многие достаточно древние протоколы в Интернете – текстовые. Потому что текстовые протоколы – это очень удобно и понятно. Там, где применимо. Сейчас, постепенно, этот подход возвращается (примеры: текстовые, REST-подобные API с JSON и др.), но, конечно, не везде.

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

Для перехода к TLS, если сервер поддерживает STARTTLS, клиент просто отправляет команду STARTTLS (в виде текстовой строки, в открытом виде). Если сервер подтверждает, что готов к TLS, клиент в этом же “транспортном” сокете отправляет начальный пакет TLS-соединения (ClientHello, начинает “хендшейк”), после чего стороны могут согласовать защищённый сокет. Далее, если процесс установления TLS-соединения успешно завершился, SMTP-сессия начинается, фактически, заново, в текстовом формате, но уже внутри защищённого TLS транспорта. То есть, на логику SMTP использование STARTTLS влияет минимальным образом.

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

Поскольку сам SMTP полностью открыт, его не так уж трудно проксировать с изменениями, даже подменяя IP-адреса узлов. Серверное сообщение о поддержке STARTTLS можно просто вырезать из соответствующего ответа – если клиент допускает доставку без TLS, то он уже не будет пытаться установить TLS-соединение, а перейдёт к доставке в открытом виде. Это давно известная особенность, указанная в RFC.

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

Сервис audit.statdom.ru проверяет разнообразные настройки по доменному имени и выводит отчёт. В том числе, проверяются настройки электронной почты (по MX-записям). Недавно добавили проверку TLS для STARTTLS. STARTTLS в SMTP означает возможность использовать TLS при доставке сообщений на сервер. О поддержке STARTTLS сервер может заявить в перечне опций, который передаёт клиенту в ответ на начальную команду EHLO. Собственно, раньше сервис audit.statdom.ru проверял только наличие флага STARTTLS, но не пытался установить TLS-соединение. В очередном обновлении – добавили фактическую проверку наличия TLS и сопоставление имён из сертификата, если сертификат сервера удалось получить. (Вообще, в практике SMTP, проверка соответствия имени в TLS-сертификате имени хоста не относится к необходимым процедурам: уже хорошо, что сервер хоть какой-то всё ещё валидный сертификат прислал – это позволяет перейти к защищённому соединению, а это часто лучше, чем открытый канал. Но, конечно, ещё лучше, если сертификат соответствует по имени.)

Ссылка: audit.statdom.ru

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

Подборка ссылок: “Тысячи спутников или орбитальный радар”, “Спутниковая группировка Starlink от SpaceX как замена GPS”, “Инфракрасные сенсоры на орбите”, “Наземные терминалы Starlink как элементы радара”; и не совсем по этой теме, но тоже занимательная записка из 2010 года: “Воскресный юмор: глобальная навигация на очень чужих планетах”.

(Источник картинки: NSF’s National Optical-Infrared Astronomy Research Laboratory/CTIO/AURA/DELVE, Wikimedia.)

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

YandexGPT, через интерфейс под названием “Алиса”, сообщило, в частности, следующее: “число делится на 2 и на 11, а значит, делится и на 3”. Конечно, это всего лишь автоподстановщик-синонимайзер, но вокруг более развитого варианта, – ChatGPT, – тем не менее, накручивают целое “научное направление” по защите от угроз “сверхразумного” ИИ.

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

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

Посмотрите на две строки: “биткойн.рф” (1) и “биткойн.рф” (2) – они должны выглядеть одинаково. Эта одинаковость обманчива, потому что в первом случае “й” записано как U+0438 + U+0306 – буква “и” + “знак бреве”, два значения; а во втором случае – это просто буква “й” (U+0439, одно значение), где, так сказать, всё включено.

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

Возвращаемся к IDN. Эта технология требует преобразования кодов Unicode к DNS-записи, алфавит которой допускает (без учёта регистра) для подстрок имён хостов символы [a-z] (от “a” до “z”), [0-9] и “минус” “-” (точки тут не считаем). Для кодирования этими ASCII-символами байтовых значений Unicode используется алгоритм, называемый Punycode. Принцип тут аналогичен тому, как работает, например, Base32 (или “кодирование в рунах”), детали отличаются, но нам это здесь не так важно. Важно, что Punycode ничего не знает про особенности Unicode и просто отображает в подмножество ASCII значения unicode-байтов (и обратно), то есть, разные кодовые записи одной буквы отобразятся в разные punycode-последовательности. Что не так трудно продемонстрировать на нашем примере: “биткойн” == “qsa11dvaajue4a”, а “биткойн” == “90aoddqe0a” (выглядит занятно, да).

Однако с точки зрения DNS “qsa11dvaajue4a” и “90aoddqe0a” – разные значения, поэтому имена, их содержащие, тоже будут разными. Разный способ записи одного и того же графического представления для целей DNS не подходит – в реестрах имён, на серверах имён, первоочередное значение имеет ASCII-представление. Поэтому и используется процесс, называемый нормализацией, который описывает соглашение о том, как разные “чёрточки” так приклеить к буквам, чтобы привести всё к одной последовательности кодов, а уже её использовать, например, в DNS. Естественно, unicode-нормализация важна не только в DNS, но подробное описание принципов остаётся за рамками этой записки – его можно найти в соответствующем документе. Отмечу, что современные библиотеки для работы с IDN, обычно, позволяют прозрачно использовать нормализацию, нужно только не забыть её правильно включить при вызове функций преобразования. И, вообще говоря, алгоритмов нормализации – несколько, что делает ситуацию интереснее. А полагать, что столкнуться с подобным на практике невозможно, будет ошибкой – копирование символов иностранных письменностей в составе имён, которые не удалось ввести с клавиатуры, вполне себе встречается.

Вот так представляется бот, собирающий веб-страницы для разновидностей ChatGPT: “Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.0; +https://openai.com/gptbot)”. В августе бот почему-то особенно активен на dxdt.ru, где, собственно, и был мной замечен в логах.