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

В прошлой заметке я написал, что уже давно не приходится использовать C для того, чтобы “что-то написать”, а только для того, чтобы вносить исправления в “старый” (или чужой) код. Записка опубликована вчера, а уже сегодня я сообразил, что вот же – пишу код для некоторых хитрых часов, работающих на Arduino. Естественно, этот код я пишу на C/C++ (от “плюсов” – там очень немного), так как именно такой вариант предлагает типовая среда разработки. Внёс пояснение в прошлую записку. Кстати, для AVR/Arduino я тоже иногда использую ассемблер – см. криптографическую библиотеку.

Поделюсь текущим состоянием набора “инструментальных” языков программирования, которые использую сейчас. Речь тут именно об использовании на практике. И основной сейчас – Golang, но встречается и Python (см. пояснения ниже), заметное место занимает JavaScript (как ни странно), а вот Perl – напротив, уже не заметен (но всё ещё встречается). А что касается языков уровнем ниже, то ассемблер тоже всё ещё иногда требуется (пример: реализация шифров).

Некоторые детали: Go оказался настолько удобным по конструкциям и сопутствующим инструментам, что заменил (для меня) даже Perl как язык для сиюминутной обработки наборов данных; то есть, Go играет и роль “скриптового языка”, но не только, поскольку на Go написал немало “долгоиграющих” модулей и утилит, в том числе, касающихся приложений криптографии (один из примеров – тестовый сервер TLS 1.3).

Python, фактически, входной язык SAGE (это система компьютерной алгебры, которую я постоянно использую), поэтому сопутствующие вычисления тоже приносят за собой данный язык, но этим объём применения Python, в моём случае, практически полностью исчерпывается. А вот место JavaScript обусловлено клиентскими веб-приложениями, исполняемыми в браузере. Кроме перечисленного, регулярно встречаюсь с Bash (как воплощением shell-скриптов) и Lua. Что касается исчезновения Perl: в своё время я достаточно много кода написал на C, но вот уже лет семь необходимости писать на этом языке не возникало (edit 05/01/23: естественно, кроме Arduino/AVR и пр. – здесь я использую C/C++), за исключением мелких правок кода (это именно в плане что-то заметное написать; читать и немного править написанное на C – приходится постоянно); с Perl-ом, похоже, складывается такая же история.

(Edit 05/01/23: почему-то забыл упомянуть PHP.)

Немного поправил внутренний код и CSS темы оформления WordPress, которая используется на dxdt.ru сейчас. Визуальных изменений очень мало, но если показывается неправильно (что-нибудь уехало и т.д.) в браузере, то нужно нажать Ctrl+F5 или Ctrl+Shift+R (относится только к десктопным браузерам, понятно).

Кстати, нередко для обновления страницы предлагают использовать Ctrl+R (F5). Но, в случае изменений на строне разработки, это не лучший вариант, по крайней мере, для Firefox и Chrome: Ctrl+R действительно вызывает повторную загрузку страницы, но разрешает использование собственного кеша браузера, так что какие-то элементы могут читаться из кеша. А вот Ctrl+F5 или Ctrl+Shift+R – это загрузка страницы со сбросом состояния кеша.

(А вёрстку, конечно, нужно существенно переделать, с учётом изменений, которые произошли в веб-разработке за минувшие годы.)

Всякий художник может нарисовать зайца. Дюрер нарисовал зайца. Верно ли, что всякий заяц нарисован Дюрером? Нет, не верно, потому что даже заяц Дюрера нарисован красками.

Традиционная записка к Новому году. WordPress показывает, что на dxdt.ru сейчас опубликовано 2646 записок. Это означает, что получился некоторый прирост по сравнению с прошлым годом. Несколько ссылок:

• О визире и слоне
• Падение тел в физике Аристотеля
• Браузеры и перехват TLS без участия УЦ

С наступающим Новым годом! Спасибо, что читаете.

Добавил (некоторое время назад) в DNS-зону dxdt.ru HTTPS-запись. Название записи может показаться странным в контексте DNS, тем не менее, именно так новая запись, описанная в черновике RFC, и называется. Я кратко упоминал эту запись в статье об использовании DNS для публикации вспомогательной информации:

Например, идёт работа над черновиком (draft) спецификации для DNS-записей с рабочим названием SVCB/HTTPS. Предполагается, что эти записи будут использоваться для публикации данных, определяющих начальные настройки доступа к интернет-ресурсам под данным доменным именем. Отличие от уже имеющихся типов записей (например, от адресных записей) весьма существенное: записи SVCB/HTTPS позволят публиковать сразу набор сведений о нескольких «фронтендах», ответственных за соответствующий сервис (например, веб) под заданным именем; в этот набор включаются разнообразные дополнительные параметры, например, определяющие нестандартные номера портов TCP/UDP, на которых отвечают серверы, или криптографические ключи, позволяющие установить соединение со скрытым сервисом.

Так как dxdt.ru не использует сложных настроек и каких-то дополнительных сервисов для доставки веб-страниц, то и соответствующая HTTPS-запись получилась максимально простой: она всего лишь информирует, что к веб-узлу следует сразу подключаться по HTTPS. То есть, клиент, который поддерживает SVCB/HTTPS, при получении ссылки на сайт с протоколом HTTP, не будет пытаться установить небезопасное подключение, чтобы прочитать HTTP-перенаправление на HTTPS, а сразу использует безопасный протокол. По крайней мере, такова цель размещения HTTPS-записи – реально, мало кто их пока что поддерживает.

А основные SVCB-записи, конечно, гораздо богаче по предоставляемым возможностям. В основном, из-за того, что позволяют публиковать криптографические ключи и сведения о точках входа, которые могут быть использованы для установления соединения в режиме “максимального сокрытия” метаинформации. Это развитие технологии ESNI.

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

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

Десять лет назад, 9 декабря 2012 года, на dxdt.ru появилась заметка-прогноз о дронах-наблюдателях в крупных мегаполисах: “летающие роботы, дроны, также оснащённые камерами и патрулирующие в определённых районах, а также, что самое интересное, следующие за какими-то там “подозрительными лицами”. Это всё тщательно описано в фантастических произведениях”.

Что тут можно заметить? Например, что такие дроны стали массово использоваться где-то в 2020 году. Сейчас, в конце 2022 года, подобными сообщениями в новостях СМИ никого уже не удивить. В заметке обозначен 2018 год, так что довольно точно совпало.

– Почему криптосистема называется 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 короче в записи – они изначально “в сжатой форме”.