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

– Почему криптосистема называется X25519, откуда это 25519?
– Потому что там присутствует 2^255 и 19. Вот только “плюс” или “минус”? А, понятно, конечно, “минус”, поскольку 2^255+19 делится на 3, что очевидно.

Число, являющееся “модулем” в данной криптосистеме, должно быть простым. Соответственно, 2^255 – 19. Но выбор в большей степени обусловлен тем, что такое число имеет удобное двоичное представление: там много единичных битов подряд. Тем не менее, из наблюдения про 2^255 + 19 можно сделать задачу к Новому году: докажите, что 2^2023 + 2023 делится на три.

На тестовом сервере TLS 1.3, который я реализовал и некоторое время поддерживаю по адресу tls13.1d.pw, пришлось тоже перейти на TLS-сертификаты Let’s Encrypt. А это привело к замене цепочки с ECDSA на цепочку с RSA, что, конечно, не очень хорошо. Вообще, так как сервер экспериментальный и полностью самописный, замена сертификатов требует ручного вмешательства, поэтому “долгие” сертификаты удобнее, чем трёхмесячные. Но, в принципе, можно процесс автоматизировать.

Я как-то перестал описывать изменения тестового сервера на dxdt.ru: прошлая записка на эту тему датирована январём 2020 года. При этом сервер продолжают использовать, он даже помогает находить ошибки и неточности в реализациях TLS стороны клиента. Конечно, ошибки обнаруживаются и в самом сервере – их я стараюсь исправлять.

Добавил несколько записок, вышедших в 2022 году, в раздел “Избранное“:

• О визире и слоне
• Модели движения Земли и знания о них
• Триплеты из цифр и системы счисления
• Падение тел в физике Аристотеля
• Нейросети из пикселей

Иногда открытый ключ нужно буквально вводить руками, например, через “воздушный зазор”. Открытый ключ в ECDSA (и, кстати, в ГОСТ-подписи, но не только там) – это точка на кривой, заданной в параметрах. Речь тут про кривые, используемые в криптосистемах на практике, например, P-256. Координаты точки – это два числа X, Y (сторого говоря, два элемента соответствующего конечного поля, но это технические детали). Если разрядность 256 бит, то может показаться, что для передачи ключа придётся руками вводить 2*32 == 64 байта, что в hextext составит аж 128 знаков. Однако обычно можно ограничиться одной координатой X, а Y – вычислить из уравнения кривой. Такой способ кодирования называется сжатым представлением ключа. Единственная хитрость в том, что, так как в уравнение кривой Y входит в квадрате, координат, соответствующих данному X, пара. Это обратные по сложению элементы (всем привычные +/-). Поэтому нужно передать знак элемента, но для передачи знака достаточно одного дополнительного бита. Поэтому сжатое представление в два раза короче, но “разрядность ключа” при этом никак не страдает (страдают вычислительные затраты на принимающей ключ стороне, но этим часто можно пренебречь; иногда, впрочем, приключаются проблемы с обработкой заведомо неверных значений). Кстати, по этим же причинам ключи криптосистем с ed25519 короче в записи – они изначально “в сжатой форме”.

Число 131312346912764927346012345012378501237411298750981000000001, случайно набранное для проверки программы, оказалось простым. Впрочем, оно не очень большое.

Некоторое время назад я написал утилиту, кодирующую произвольные байтовые значения в строки англосаксонских рун. Используется кодирование, эквивалентное Base32, но с алфавитом из рун. Алфавит, понятно, может быть любым, но в случае рун для отображения в привычных компьютерных системах потребуется поддержка Unicode.

Таблицы Unicode – весьма богатое нововведение. Unicode позволяет записывать в тексте числа древними шумерскими цифрами, вот так: 𒁹 𒌍𒐋 𒌋𒌋𒐈. (Если на вашем устройстве эти цифры не отображаются, то, вероятно, устройство не содержит подходящих шрифтов; такое всё ещё возможно; более того, мне пришлось столкнуться с существенными трудностями при размещении этой записки в WordPress – стандартный редактор данной CMS отказывался принимать соответствующие символы, пришлось применять некоторые хитрости).

В принципе, шумерская (вавилонская) система записи – позиционная, по основанию 60, но имеет свои особенности, создающие неоднозначности при интерпретации: там используется плавающая “шестидесятеричная точка”, которая не обозначается; кроме того, в классическом варианте, нет цифры для нуля. 𒁹 𒌍𒐋 𒌋𒌋𒐈, в зависимости от контекста, можно интерпретировать не только очевидным способом, как 5783 (1*60^2 + 36*60 + 23), но и, например, как 96.38333(3) (1*60 + 36 + 23/60). Клинописные цифры, соответствующие числам от 1 до 59, записывались засечками; так, 𒐈 – это 3, а 𒌋𒌋 – это 2*10, то есть, 20 (𒌋 обозначает 10). Unicode, – по крайней мере, в теории, – позволяет все эти засечки напечатать и вывести на экран компьютера в виде текста, благодаря наличию разнообразных кодовых таблиц, среди которых есть и таблица с шумерскими древними цифрами.

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

В ноябре 2012 года, десять лет назад, регистраторы RU-CENTER и R01 включили поддержку DNSSEC для имён в доменных зонах .su, .com, .net. В этом перечне важен домен .su – открытое внедрение DNSSEC в российских реестрах началось именно с него. А включение поддержки означало, что все клиенты даных регистраторов смогут настроить DNSSEC для своих зон. (К сожалению, за прошедшие десять лет слишком многое изменилось, а в результате перемен – утрачена масса полезных исторических веб-страниц, поэтому не могу привести ссылку на текст исходной новости; впрочем, копию пока что можно найти в web.archive.ru.)

Вообще, если посмотреть на сайт под доменом nox.su, то там сказано, что “криптографическая информация, соответствующая домену nox.su, внесена в файл зоны .su 23.11.2011” – то есть, ровно 11 лет назад и годом ранее, чем доступ к DNSSEC появился у упомянутых регистраторов. Это объясняется тем, что с nox.su мне помогли специалисты ТЦИ и RU-CENTER (большая им благодарность!): соответствующую DS-запись в реестр внесли, так сказать, в обход общедоступного интерфейса.

За эти годы DNSSEC не обрела особой популярности. Не только в российских доменах, но и во всей глобальной DNS. Сейчас в зоне .ru лишь около 6 тыс. имён с DS-записью (статистика по другим TLD – картину улучшает не сильно). В моде другие направления и другие этапы доставки данных, а в качестве едва ли не единственного метода защиты информации, на прикладном уровне, используется TLS.

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

В ноябре 2007 года на dxdt.ru выходили записки, касающиеся, например, современности авиации, а также технических аспектов радиолокации. Вот небольшая записка про систему стабилизации NOTAR:

Есть и относительно новая схема стабилизации вращения – NOTAR (от англ. No Tail Rotor), которая, несмотря на то что увековечена в фильмах о Джеймсе Бонде, в широких кругах известна мало.

А вот познавательная заметка про Активные Фазированные Антенные Решётки (АФАР), которая востребована и сейчас:

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

Выпустил ежегодное обновление технического описания протокола TLS. Каких-то больших дополнений в этом году не вышло, но актуализировал весь текст. (Есть, впрочем, очень краткое новое приложение (В), посвящённое ГОСТ-TLS.)