Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Ещё немного историй про монеты, которые имеют большое значение как некоторый “фокальный объект”. Если посмотреть на почти современные греческие монеты (конец прошлого века), то нетрудно заметить интересную особенность – она хорошо видна на иллюстрации ниже.
На этой иллюстрации – аверсы двух монет в 10 греческих драхм. Однако на левой монете, датированной 1988 годом, написано ΔΡΑΧΜΕΣ, а на правой, которая из 1976 года, ΔΡΑΧΜΑΙ. И то, и другое слово – это множественное число для драхм. Отличие лишь в двух последних буквах: эпсилон-сигма сменяют альфа-йоту. Почему? Может, это опечатка, и тогда одна из монет представляет собой редкость?
Нет. Это не опечатка. Это физическое воплощение весьма мощного для новогреческого языка социального явления, которое известно как греческая диглоссия или “языковой вопрос”. Дело в том, что в современной Греции почти пару сотен лет, – с восемнадцатого века и до середины двадцатого, – шла активная борьба за сохранение “книжного языка” (καθαρεύουσα, “кафаревуса”) в качестве языка официального, в противовес разговорному языку греческого народа (δημοτική γλώσσα, “народный язык”, или просто “димотика”). То есть, в противовес тому языку, которому, с начала двадцатого века, обучали в начальной школе (например).
Под “официальным языком” тут имеется в виду язык, на котором составлялись важные документы и которым могли пользоваться чиновники в государственных учреждениях. Последний момент, кстати, приводил к тому, что даже не все грамотные и образованные греки могли понять, что именно пишут – или, реже, говорят – в том или ином учреждении на “книжном языке”, на “кафаревусе”, который был ближе к древнегреческому.
Результатом этого процесса стал окончательный переход к димотике, и в качестве “официального языка” тоже. Это произошло в 1976 году (дата на монете справа).
Так что разная запись, – с сигмой или с йотой, – это отражение перехода на димотику, в которой пишут ΔΡΑΧΜΕΣ. Поэтому и на монетах стали чеканить форму с эпсилон-сигмой. Но чеканить такие монеты начали позже 1976 года, а именно – с 1982.
А схематическое изображение атома на аверсе этих монет присутствует тоже не просто так: монеты посвящены Демокриту – его портрет отчеканен на реверсе.
Комментировать »
Добавил на страницу “Избранные записки” ещё десять записок:
Комментировать »
Нередко приходится слышать, в качестве ответа на критику очередного “опуса”, сгенерированного ИИ, что, мол, люди тоже публикуют всякие “бесполезные наборы слов”. Поэтому процитирую весьма занятный фрагмент из недавней публикации известного британского физика Джонотана Оппенгейма (Jonathan Oppenheim). Прямо по этой же теме. Контекст – рассуждения (англ.) о научной публикации в Physics Letters B, которая, как заявлено, основана на “идее, сформулированной ИИ Chat GPT-5”. (Сама работа, при ближайшем рассмотрении экспертом, оказывается и бесполезной по основной идее, и ошибочной по содержанию; однако выяснить это непросто, откуда и популярный нынче термин AI slop – “ИИ-помои”.)
Конечно, исследователи-люди тоже выпускают “помои” (slop): лишь небольшая доля публикаций интересна. Да, нам точно нужны более высокие стандарты публикации, и мы должны писать меньше работ. Однако разница между “помоями”, созданными человеком, и “помоями” ИИ состоит в том, что “помои” от людей помогают поддерживать исследовательское сообщество. И это сообщество исследователей нужно нам: оно позволяет обучать студентов, служит “институциональной памятью”, действует как распределённая сеть знаний и коллективного чувства стиля. Это то самое большее исследовательское сообщество, что создаёт и поддерживает (sustain) великих учёных. А у “помоев”, которые производит ИИ, нет никакой выгоды, насколько я вижу.
/Of course, human researchers also produce slop – only a small percentage of papers are interesting. And yes, we should definitely have higher standards for publication, and write fewer papers. But the difference between human slop and AI slop, is that human slop helps sustain a community of researchers. And we need this community of researchers, to train students, serve as institutional memory, and act as a distributed network of knowledge and collective taste. It is this wider community of researchers which sustain the great scientists. While the slop that AIs produce have no benefit as far as I can see./
Комментировать »
В The Register пишут про не самый обычный прототип высокоскоростного (5.2 Gbps) канала связи, который японская корпорация Kyocera устроила на основе лазера. Якобы, схема подходит для подводной связи. Конечно, если бы было так, да без очевидных ограничений, то это оказалось бы прорывной технологией. К сожалению, прототип работает лишь на дистанции около метра, а тот вариант, который показали журналистам, ещё и через специально очищенную воду, без учёта возможных “турбулентностей” (ну, как говорится, это “такие себе” ограничения – пока что они сводят возможный практический эффект примерно к нулю).
Не сказать, что подобная высокоскоростная схема, начни она работать даже и на полтора метра, но через реальную морскую воду в море-океане, – совсем бесполезна. Нет. Можно использовать для того, чтобы очень быстро передать накопленные данные (видеозаписи, например) с подводного дрона, который подошёл к подводному узлу связи, установленному на дне (ну или это может быть плавучий буй, с тем же, в общем-то, эффектом). Всё же, возможность локально передать большой массив информации без необходимости кабельной стыковки – это полезно. Но, конечно, без увеличения дистанции – технология получается очень специализированная, не решающая основной проблемы связи с подводными аппаратами.
В DARPA, кстати, некоторое время назад запускали программу, в которой высокоскоростной канал связи реализуется при помощи плавучего оптического кабеля.
Комментарии (2) »
Я в ноябре выступил с небольшим докладом на Пиринговом форуме. Кроме прочего, в докладе показал и неравенство треугольника для Anycast (см. ниже фото, из официальных).
Вообще, неравенство треугольника здесь – это очень полезная иллюстрация, которая показывает, что только из конкретных BGP-таблиц какие-то данные о реальной связности получить нельзя, а содержательные показатели образуются тогда, когда мы начинаем “склеивать” сведения из разных BGP-таблиц (то, что называется View). Другими словами: именно на пересечении, на склейках, и образуется модель Интернета, как схемы, существующей между IP-сетями.
Комментировать »
В продолжение предыдущей записки. Ещё один занятный момент про сверхкороткие TLS-сертификаты.
Понятно, что если сертификаты действуют недолго, то на заданном интервале времени сертификатов будет больше. Например, больше сертификатов будут попадать в логи Certificate Transparency (CT-логи). Возникнет дополнительное зашумление: если для домена example.com за месяц выпущено десять сертификатов вместо двух, как раньше, то запутаться с обработкой и мониторингом проще.
Если вы вдруг посчитали, что этот эффект надуман, да и вообще – быть такого не может, чтобы мониторы CT-логов что-то потеряли, то вспомните недавнюю весьма странную историю с сервисом 1.1.1.1 и Cloudflare. В той истории CT-логи непосредственно самой корпорации Cloudflare получили от внешнего удостоверяющего центра (УЦ) информацию о том, что – без санкции Cloudflare! – этим УЦ выпущены TLS-сертификаты для 1.1.1.1 (а это важнейший сервис Cloudflare), но даже корпорация Cloudflare, – без всякого сраказма: технологический лидер направления, – целый год ничего подозрительного в тех самых своих CT-логах каким-то образом не замечала. А теперь представьте, что сертификатов стали выпускать в десятки раз больше.
Так вот, если предположить, что где-то выпускаются подменные сертификаты, для активного перехвата трафика, и делается это при участии УЦ, то подменный сертификат тоже выпускается на короткий срок (несколько дней), и это теперь не выглядит необычным. Как не выглядит необычным и то, что в сертификате нет информации о проверке его статуса (отозван или нет). УЦ может подписывать такой перехватывающий сертификат, что называется, на лету.
Сейчас тут обычно приводят в качестве препятствия всё ту же технологию Certificate Transparency. И действительно, если клиент проверяет метки CT (SCT) в сертификатах, то эти метки должны быть и в подменном сертификате. Вот только получение меток не требует размещения сертификата в публичных логах. Это, как раз, очень распространённая ошибка – считать, что SCT-метки гарантируют размещение в логах. Нет. Для вычисления валидной метки нужен только сам сертификат и секретный ключ оператора CT-лога. Так что, для подменного сертификата, могут генерироваться только метки, без размещения в логах. Это будет нарушением соглашений с браузерами. Но, как бы, в CT-логах, как мы только что выяснили, и так много “коротких” сертификатов для разных имён, и за ними никто особо не следит.
Комментировать »
TLS-сертификаты в современном вебе неуклонно превращаются в токены, разрешающие доступ клиентов к веб-сайтам. Я неоднократно об этом писал раньше, но есть смысл вернуться к данному процессу, посмотрев на него подробнее. Тем более, что это касается не только веба.
Основных признаков – два: быстрое сокращение допустимого срока действия TLS-сертификата и отказ от механизмов отзыва. По срокам действия: уже принят план, по которому к 2029 году максимальный срок действия валидного сертификата не должен превышать 47 суток. “Валидного” – означает, что сертификаты, в которых указан более долгий срок действия, будут автоматически считаться клиентом невалидными, только на основании этого срока действия, вне зависимости от того, сходится подпись удостоверяющего центра (УЦ) или нет. Скорее всего – максимальный срок действия ещё заметно подсократят, не дожидаясь 2029 года.
Отказ от механизмов отзыва: в предельном случае – просто не будет способа отозвать сертификат. Получаем безотзывный токен. Это уже так для сверхкоротких сертификатов (со сроком действия меньше десяти дней). Сейчас для публикации статуса выпущенных сертификатов (действует/отозван), как минимум, есть списки отзыва (CRL). Следует ожидать, что для сертификатов-токенов – ничего подобного не будет.
Итак, представим, что TLS-сертификаты для доменных имён и IP-адресов выпускаются со сроком действия три дня максимум (сейчас уже есть шестидневные сертификаты). Что это означает с технической точки зрения? Например, штатно работающий браузер не станет показывать пользователю контент на веб-сайте, у которого, – внимание! – на сервере не установлен TLS-сертификат с подходящим сроком действия (до подписей мы ещё не добрались даже).
Тут можно возразить, что браузер и так имеет возможность заблокировать любой сайт, просто по имени хоста сервера, по URL, ещё как-то. Получается, ничего нового, в плане возможностей, для пользователя и браузера не появляется. Это не совсем так.
Прежде всего, чтобы подобная фильтрация работала в браузере – нужно, чтобы разработчики браузера обеспечили хранение где-то списка веб-узлов, к которым браузеру нельзя подключаться. И этот список – нужно либо передавать в конкретные экземпляры браузера целиком, либо обеспечивать онлайн-интерфейс (такие схемы есть и иcпользуются: см. Safe Browsing и т.д.). В случае же с TLS – получение нужного токена полностью уходит на сторону веб-сервера (понятно, при периодическом участии УЦ). То есть, схема оказывается “открытой” и поэтому не требует ресурсов на перечисление узлов и построение списков: всё работает в другую сторону и вместо внесения в список запретов – веб-узлу требуется самостоятельно получить разрешение на доступ.
И, ещё раз, не следует забывать и о том, что TLS – это далеко не только веб. Однако принципы валидации из веба и веб-браузеров, обычно, позже распространяют и на другие сценарии использования.
Чтобы получить сертификат, разрешающий доступ, сервер должен обратиться к тому или иному УЦ. Понятно, что обновление сертификатов раз в несколько дней означает, что это обновление должно происходить автоматически. Да, есть протокол автоматизации ACME, а получение сертификата можно встроить непосредственно в веб-сервер. Что получается? Получается, что веб-сервер периодически отмечается в некотором центральном сервисе (ACME-УЦ), который выдаёт токен (сертификат), подтверждающий обращение и предназначенный для предъявления клиентам, которые подключаются к этому веб-серверу. Если токен-сертификат получить не удалось, пользователи к веб-сайту подключиться не смогут. Как только токен стал короткоживущим – мы получили не просто схему аутентификации узла, но и схему авторизации доступа, в которой роль авторизующей стороны играет удостоверяющий центр. Безотзывность токена нужна тут для того, чтобы не тратить ресурсы на сопровождение механизма отзыва, который с необходимостью будет “разбухать”: ведь токены выпускатся очень часто.
Можно возразить, что, мол, за вычетом отзыва, всё так было и раньше: если мы хотим, чтобы доверенным образом работал HTTPS, то всё равно нужно было получать сертификат от УЦ. Но в этой “старой схеме” и сертификат действовал, предположим, год, и получение нового сертификата не было встроенно в веб-сервер. То есть, техническая конфигурация становится совсем другой.
Конечно, у схемы с короткоживущими токенами доступа вместо TLS-сертификатов есть свои преимущества: например, её можно быстрее адаптировать к изменениям в составе криптосистем или к изменениям в формате сертификата. Но не следует забывать, что такая схема приносит с собой совсем новую парадигму управления доступом.
Комментировать »
Let’s Encrypt начали поэтапно сокращать максимальный срок действия выпускаемых TLS-сертификатов с 90 дней (как сейчас) до 45 дней (в 2028 году обещают). Так что, скорее всего, браузеры тоже подтянутся и – сокращать срок действия придётся всем остальным УЦ. Сертификаты движутся по пути превращения в короткоживущие токены, разрешающие клиентам доступ к веб-ресурсу.
Комментировать »
“Envelopes at sixpence a packet. Particular man in his stationery.”
Arthur Conan Doyle
The Sign of the Four
(Это дополненная версия статьи, которую я ранее опубликовал на “Хабре”.)
Исторический анекдот гласит, что в тридцатых годах прошлого века в Великобритании наблюдалась сезонная нехватка шиллингов в обращении. Почему? Потому что много монет находились внутри газовых счётчиков и счётчиков электроэнергии. Такие счётчики были в ходу ещё и в шестидесятых годах. Если вы смотрели старые британские фильмы, то там нередко показаны ситуации, когда для того, чтобы включилось электричество в квартире или домашнее отопление, нужно опустить монетку-шиллинг в специальный счётчик, установленный тут же. Получив монетку, счётчик включает газ или электричество на какое-то время. Собранные монеты из счётчика периодически забирал специальный сотрудник компании-поставщика энергии. Зимой, естественно, и электричество, и тепло востребованы больше, поэтому больше монет оседало внутри счётчиков.
Шиллинги регулярно задействует Шерлок Холмс в классической советской серии телефильмов: два шиллинга за информацию о лодке, 56 шиллингов за возможность просмотреть вчерашнюю порцию бумажного мусора в нескольких гостиницах. Шиллинг сюда, шиллинг – туда. Собрался целый фунт, даже больше. Но монеты в один фунт не было. Да, был соверен – 20 шиллингов, что соответствует одному фунту по количеству, но, тем не менее, это соверен, а не фунт. В современной Великобритании, несмотря на Шерлока Холмса, шиллинги не ходят. Они довольно давно исключены из оборота. Куда же исчез шиллинг? Оказывается, он превратился в пять пенсов.
Комментировать »
В IETF и вокруг сейчас происходит небольшой технический скандал, непосредственно связанный с внедрением рекомендаций по использванию негибридных криптосистем ML-KEM в TLS.
Если очень кратко, то переход на постквантовую криптосистему ML-KEM, как единственный механизм получения сеансового секрета, может восприниматься как попытка протолкнуть в TLS некий бэкдор, который отсутствует в X25519 (сейчас X25519 используется вместе с ML-KEM, в составе гибридной криптосистемы, поэтому бэкдор в ML-KEM, для гибрида, только лишь снизит стойкость в два раза).
На днях появилась весьма занятная публикация, непосредственно касающаяся технической части этого скандала: ML-KEM Mythbusting (“Разрушение мифов об ML-KEM”, англ.). Самый удивительный аспект этой публикации в том, что автор прямо утверждает: “в ML-KEM нет бэкдора, это можно доказать”. Вообще, доказать отсутствие бэкдора в криптосистеме не просто сложно, а, часто, невозможно. Особенно, если речь идёт об асимметричных схемах инкапсуляции ключа. Видимо поэтому в публикации по ссылке утверждение заметно более размытое: делается попытка доказать, что это в параметрах ML-KEM недостаточно энтропии для того, чтобы встроить качественный бекдор. (“Качественный” тут – это доступный только держателю секретного ключа от бэкдора, как в DUAL EC DRBG.)
Что имеется в виду? Вот что: якобы, если множество вариантов параметров криптосистемы достаточно маленькое, чтобы перебрать его за обозримое время, то бэкдор там негде прятать – его можно будет обнаружить простым перебором. И вот в ML-KEM, как бы, это множество – всего 34 бита. Как бы, утверждение верное, вот только оно сильно слабее, чем предположение о бэкдоре: бэкдор может находиться непосредственно в алгоритмах, поэтому, для его обнаружения прямым перебором, нужно будет мощность множества параметров возвести в некоторую большую степень (это, примерно, как идея моделирования квантовых вычислений, когда у вас все 2^34 варианта участвуют в расчётах на каждом шаге).
Также упомянут заложенный в алгоритм отказ с ошибкой при обработке корректного шифротекста. Малая расчётная вероятность такой ошибки, – которая вероятность, кстати, прямо связана с выбором параметров, но про это ничего в публикации не сказано, – сравнивается с возможностью аппаратного сбоя: вероятность сбоя, – например, перещёлкивания битов под воздействием космического излучения, – оказывается выше, чем расчётная вероятность штатного сбоя ML-KEM. Но, всё же, аппаратный сбой в результате “пролёта нейтрона”, это совсем не то же самое, что и идеальная ошибка, заложенная прямо в алгоритм. Я, кстати, писал об этом моменте, именно в части ML-KEM.
Вообще, конечно, история, в которой ML-KEM почему-то начинают тщательно “обелять”, доказывая, что там нет бэкдора – несколько подозрительная.
Комментировать »
Новый 