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

Запись чисел при помощи цифр различных систем счисления нередко приводит к недопониманию у тех, кто не очень хорошо представляет себе разницу между числами и их записью. Например, могут предположить, что 11 и 0x11 (в шестнадцатеричной записи, далее такая запись обозначается привычным префиксом) это одно и то же число, ну, как 7 и 0x7. Нетрудно наткнуться и на смешение свойств числа и его записи: то есть, на неверное представление о том, что какие-то свойства чисел соответствуют именно записи (запутывающее сочетание 0x100 == 2^8). Впрочем, всё это не мешает занимательным свойствам позиционных систем счисления интересным образом преобразовываться при переходе от одной системы к другой, сохраняя именно запись (то есть, цифры).

Так, если 1001001 умножить на 321, то получим 321321321. Почему? Очевидно: мы умножаем (10^6 + 10^3 + 10^0) на (10^2*3 + 10^1*2 + 10^0*1), то есть (10^6 + 10^3 + 10^0)*321. Известный, пусть и не очень широко, факт: всякое число, содержащие ровно три одинаковых тройки цифр в своей записи, делится на 333667. Примеры:
321321321/333667 == 963 == 3^2 * 107
111111111/333667 == 333 == 3 * 111
701701701/333667 == 2103 == 3 * 701

(Конструкция, конечно, переносится и на кратные записи, то есть, когда количество триплетов кратно трём.)

Выглядит занимательно. Причина в том, что на 333667 делится 1001001 == 3*333667. А 333667 – простое число. В записи 333667 нетрудно увидеть поразрядные “переносы единицы” при умножении на три. Можно ли найти число с такими же свойствами в шестнадцатеричной записи? Можно. Если в десятичной записи 3*3 == 9 == 10 – 1, где 10 – основание системы, то в шестнадцатеричной аналогом будет 3*5 == 15 == 0x10 – 1. Обратите внимание, что здесь 0x10 шестнадцатеричная запись числа 16, основания системы. Число другое, но нам здесь важны как раз некие свойства записи (а именно – позиция единицы). Искомое число – 0x555aab. Заметьте, что шестнадцатеричное 0xa равно 10 в десятичной системе, то есть, 5*2 (так же как и 3*2 == 6). Проверяем: 0x555aab * 0x3 == 0x1001001 (но это 16781313 в десятичной записи). Поэтому 0x321321321 делится на 0x555aab, а результат равен 0x963 (см. примеры в десятичной системе выше). Однако найденное нами “опорное” число хоть и полностью подходит по “свойствам” записи, но является составным: 0x13*0x25*0x49*0x6d == 0x555aab.

А вот в восмеричной системе ситуация иная. Число 0o1001001 (префикс 0o – обозначает восмеричную запись) – простое, а именно – 262657 == 8^6 + 8^3 + 8^0. Поэтому не получится найти делитель, который подходил бы для построения конструкции, аналогичной десятичной и шестнадцатеричной системам. Интересно, что число 46656216001 == 60^6 + 60^3 + 60^0 тоже простое. Это означает, что и в древней шестидесятеричной системе конструкция не сработает. Что ж, зато в десятичной системе 296296296296296296296296296/333667 == 888000000888000000888. Проверьте на калькуляторе.

Некоторые странные заблуждения из области “научпопа” очень долговечны. Например, если заглянуть в статью про Галилея в русскоязычной “Википедии”, то нетрудно обнаружить типовые суждения в стиле “Галилей опроверг (мета)физику Аристотеля”. “Википедия”, конечно, здесь выступает лишь фольклорным зеркалом истории физики, но тем рельефнее выглядит цитата: “В частности, Аристотель утверждал: скорость падения пропорциональна весу тела; движение происходит, пока действует «побудительная причина» (сила), и в отсутствие силы прекращается”.

Да, Аристотель подобное утверждал, но с очень важной оговоркой, которая полностью меняет ситуацию. Аристотель изучал падение тел в среде и рассуждал о максимальной скорости падающего тела. Утверждения Аристотеля, процитированные выше, хорошо соответствуют эксперименту. Действительно, в воздухе свинцовый шарик и клочок ваты, сравнимого размера, будут падать с разной максимальной скоростью, потому что у них различный вес. Конечно, другое дело – вакуум. Однако Аристотель изучал падение не в вакууме. Понятно, что то же самое относится и к “побудительной силе”, если учитывать реальные условия. Поэтому хорошо бы и формулировать иначе: Аристотель утверждал, что при падении в среде, – например, в воздухе, – максимальная скорость, которой может достичь тело, пропорциональна его весу. Но при такой формулировке исчезает вся сенсационность. Получается, что Галилей не “опровергал физику”, а всего лишь обобщил ограничивающие свойства, обусловленные наличием среды, и предложил другую модель, в чём-то более универсальную. Кроме того, всё это знали другие естествоиспытатели, раньше Галилея. Надо заметить, такая интерпретация сильно богаче с точки зрения философии науки, но менее литературна. Поэтому в “Википедии” читаем: “Галилей сформулировал правильные законы падения: скорость нарастает пропорционально времени”. Занятно выглядит слово “правильные”. Как можно понять, что какие-то законы физики – правильные? А если вы сравниваете разные модели при различных “граничных условиях”? Физика, вообще говоря, не претендует на “правильность законов”.

Ссылка по теме: Aristotle’s Physics: a Physicist’s Look, Carlo Rovelli.

Обычно, протокол Диффи-Хеллмана (DH) описывают на примере вычетов, то есть, арифметики остатков. Это так называемый классический вариант реализации протокола, который тоже используется на практике. При этом, протокол успешно обобщается на другие математические структуры, лишь бы они обладали некоторыми специальными свойствами. Эти свойства весьма важны для применимости протокола на практике.

Посмотрим на классический вариант DH: s = G^ab == G^ba (mod P), а именно – мы выбрали некоторое большое простое число P, выбрали натуральное G < P (это значение называют генератором), а в рамках операций протокола возводим G в секретную степень a или b по модулю P. Другими словами – вычисляем остаток от деления на P. Из привычного свойства степеней выводится нужное равенство, означающее, что стороны придут к одинаковому значению секрета s. Уже при разборе классического варианта можно обнаружить первое важнейшее общее свойство, о котором нередко забывают.

Действительно, стороны обмениваются значениями G^a и G^b по открытому каналу, соответственно, атакующему нужно вычислить a или b, по известному значению G^a или G^b. Почему же атакующий не может просто последовательно возводить G в натуральные степени, чтобы на каком-то шаге получить G^a (или G^b, но для примера возьмём только a), определив, таким образом, секретное значение? Ответ на этот вопрос такой: будем выбирать значение a достаточно большим, чтобы полный прямой перебор оказался вычислительно недоступным. Например, последовательно перебрать уже 2¹²⁸ значений, для нашей задачи, весьма и весьма затруднительно. (Техническая оговорка: классический протокол DH на практике использует значения гораздо большей разрядности – 4096 бит и больше; это связано с особенностями криптоанализа именно классического DH, и не должно нас смущать: 4096 бит, после применения некоторых оптимизаций, как раз превращаются, примерно, в 196 “честных” битов.) Итак, атакующий не может перебрать все показатели степени последовательно, потому что это очень долго. Но как же тогда быть сторонам, использующим DH, они же тоже возводят G в степень большой разрядности? Это и есть первое арифметическое свойство, необходимое для успешного обобщения DH.

Так как каждая сторона протокола знает своё секретное значение, она может воспользоваться тем, что, например, 16 == (2²)². То есть, вместо трёх умножений – ограничиться всего двумя: (2*2)*(2*2). Очевидно, что один раз вычислив 4 == 2*2, можно использовать 4 дальше. Зная нужное значение показателя, процесс вычисления нетрудно разбить на повторное “удвоение” (здесь – в смысле степени, но это весьма важный и более общий термин) и умножение на основание: 3⁵ == 3²*3²*3 == 243. Существенная экономия вычислительных ресурсов, которая выводится из того, что умножение в целых числах не зависит от расстановки скобок: a×a×a×a×a == (a×a)×(a×a×a) == a×(a×a×a×a). Вместо того, чтобы 128 раз умножать 3 на 3, вычисляя 3¹²⁹, можно поступить проще: 3¹²⁹ == 3¹²⁸*3 == (3⁶⁴)²*3 и т.д., рекурсивно. Всё это может показаться очевидным для целых чисел, особенно, если учесть тот факт, что описанный метод естественным образом отображается на двоичное представление, привычное для компьютерных вычислений. Однако при обобщении протокола DH данное свойство трансформируется: необходимо, чтобы арифметические операции в новой структуре позволяли выполнять “быстрое удвоение”. “Быстрое” – в смысле количества вычислительных операций.

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

Итак, следующая особенность DH – это протокол достаточно высокого уровня, чтобы его можно было переносить на другие структуры, с подходящей арифметикой. Обычно – на группы. Естественным препятствием здесь является наличие сложности решения обратной задачи. Если у нас есть функция DH с параметром, отображающая элемент новой структуры в другой элемент, задаваемый параметром, то эту функцию должно быть сложно обратить. В случае классического варианта протокола, скажем, что параметр – это показатель степени, а функция может быть представлена как S = G^x. Тогда обратная задача – это задача дискретного логарифмирования: нужно отыскать x, по известным G и S. Для эллиптической кривой обратная задача, обеспечивающая возможность переноса обобщённого DH, это задача вычисления показателя кратности (скаляра) x по двум известным точкам: S = xG. Например, в случае суперсингулярных (не будем вдаваться в технические подробности) эллиптических кривых протокол ECDH может оказаться уязвимым, поскольку существуют практические методы быстрого решения задачи дискретного логарифмирования для некоторых из этих кривых (методы эти позволяют свести задачу к вычетам, то есть, к области классического DH, но это детали). Как ни странно, это совсем не означает, что суперсингулярные эллиптические кривые не годятся для реализации DH.

Примером использования DH в совсем другом математическом окружении является постквантовый протокол CSIDH. С одной стороны, этот протокол работает на весьма экзотических объектах из области теоретической математики, а именно, на кольцах эндоморфизмов (и изогениях) эллиптических кривых (опять же, не обязательно понимать, что это такое), с другой стороны, применяемый алгоритм на уровне логики полностью аналогичен классическому DH, хоть и использует весьма нетривиальные превращения в качестве основной операции.

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

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

Итак, список свойств. Некоторые из них совсем очевидны, некоторые – очевидны в меньшей степени, есть и неочевидные.

1. Ни в каком виде не должно быть авторизации по телефонному номеру. Тем более – привязки аккаунта к телефонному номеру. Телефонный номер – это ресурс оператора связи. Следует считать, что оператор связи решает собственные задачи и вовсе не собирается участвовать в обеспечении безопасности очередного “безопасного” мессенджера.

2. Не должно быть централизованного инструмента для “восстановления аккаунта”. То есть, если пользователь совсем потерял все свои реквизиты доступа, то, к сожалению, это означает, что он потерял и доступ, без возможности восстановления. Дело в том, что наличие централизованного инструмента восстановления аккаунта (типа, “получите код в SMS”), означает, что внутри мессенджера встроен механизм перехвата аккаунтов. Ключевое понятие здесь: “централизованный”. Это, естественно, не отменяет дополнительных резервных реквизитов и защищённых распределённых инструментов восстановления доступа.

3. Идентификация аккаунта проводится по отпечатку некоторого криптографического ключа (или “токена”), секретная часть которого находится у пользователя. Этот принцип соблюдается далеко не всегда, но только такой вариант позволяет разделить “адресацию” на уровне сообщений пользователей и всю прочую адресацию (IP-адреса узлов, доменные имена, телефонные номера и пр.). Привязка идентификатора к реальному пользователю происходит за пределами мессенджера.

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

5. Должно быть опубликовано подробное описание используемого протокола (протоколов) обмена сообщениями, охватывающее, кроме прочего, все базовые логические блоки в деталях. При этом требуется встроенный в протоколы механизм проверки того, что приложение работает именно по этим протоколам.

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

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

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

9. Предпочтительно должна использоваться распределённая схема доставки сообщений. Дело в том, что доступность – один из основных критериев супербезопасного мессенджера. Обеспечить гарантированную доступность через центральный сервер весьма сложно (скорее – невозможно): на этом сервере всегда можно отключить, заблокировать кого-то из пользователей. Опять же, это весьма и весьма трудный в реализации пункт, хоть и популярный.

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

Вообще, уравнение пятой степени x⁵ – 15x⁴ + 85x³ – 225x² + 274x – 120 == 0, например, имеет рациональные корни: 1, 2, 3, 4, 5 (проверьте), а корень уравнения x⁵ – 5 == 0 нетрудно записать “в радикалах” (5^1/5). Когда здесь говорят о “неразрешимости в радикалах”, то речь идёт о том, что существуют уравнения (степени n >= 5), для которых нельзя записать формулу, выражающую все корни через коэффициенты “в радикалах” (и, вообще говоря, таких уравнений очень много – примеры, которые приведены выше, это как раз редкие исключения). Интересно, что центральным моментом тут является как раз возможность записать – именно от неё можно начинать разбор ситуации. С одной стороны, можно представить себе некоторый калькулятор, который выполняет с комплексными числами четыре привычных действия (+, -, *, ÷) и позволяет извлекать корни (√ – это и есть “радикалы”). Комплексные числа тут необходимы потому, что без них достичь универсальности не выйдет даже для кубических уравнений с рациональными корнями – ведь комплексные числа и были обнаружены в ходе построения универсальных формул решения кубических уравнений (формула Кардано). С другой стороны, конечно, никакой реальный калькулятор не может считать даже в действительных числах, что уж там говорить про комплексные, где с радикалами возникают дополнительные проблемы.

Поэтому про формулу “в радикалах” лучше всего думать в том ключе, что она позволяет корни записать точно. Например, написать √2 или ∛5. Потому что точно выписать значение √2 в десятичной, например, системе нельзя, а вот обозначить число, квадрат которого равен двум, символом √2 – можно, и это будет точное обозначение. Например, если число ∛5 возвести в третью степень, то получится рациональное число 5, то есть, значение как бы запрыгивает в рациональные числа. Это важное для теории наблюдение: коэффициенты уравнения тоже рациональные, а выражение их в радикалах подразумевает, что существует способ запрыгнуть в рациональные через возведение в степень. Этому соответствует обратная операция – извлечение корня n-й степени. Собственно, вся классическая теория строится вокруг этого факта, но соответствующие симметрии оказываются весьма сложными для понимания: заметьте, что корни должны переставляться, сохраняя истинность некоторых соотношений между ними. Так, если уравнение квадратное, а корни a и b, то такие соотношения это (a + b) и a*b (формулы Виета). Неразрешимость в радикалах означает, что “радикальных формул”, позволяющих точно записать корни, не существует совсем. Для уравнений степени меньше пяти – такие формулы есть, и они даже универсальные, то есть, подходят для произвольного уравнения. А вот для степени пять и выше – нельзя выписать не только универсальную формулу, но даже и “специальную” для каждого (произвольного) уравнения.

Техническая оговорка, которую можно пропустить, тут состоит в том, что препятствие на уровне пятой степени возникает из-за особенной симметрии, соответствующей перестановкам пяти корней уравнения: нельзя спуститься от пятой степени к четвёртой, сохраняя “коммутативность” перестановок в общем виде; а вот от четвёртой – спуститься уже можно.

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

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

Утверждение, что “параллельные прямые пересекаются” сейчас нередко встречается даже в более или менее серьёзных источниках. Например:

“Представим себе двумерное пространство — это легко. Например, бесконечную плоскость, где также справедливы аксиомы Евклида. […] Но можно легко представить и иной вариант — сферу. Это замкнутое конечное пространство, где параллельные прямые пересекаются, а сумма углов треугольника больше 180°”

Это цитата из статьи под названием “Космологический ликбез. Что такое Вселенная“, опубликованной на сайте издания “Троицкий вариант. Наука”.

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

Как ни странно, тут можно вспомнить европейскую живопись 16-17 вв., которая развивалась вместе с проективной геометрией. Способы построения художественной перспективы, определяющие то, как именно трёхмерная сцена сужается в двумерное полотно картины, требуют для изображений различных параллельных линий общей точки, принадлежащей недостижимому горизонту. Это лучше всего видно на тех картинах, где сюжет содержит какую-нибудь подходящую плоскость, замощённую прямоугольниками (или даже квадратами). Я в качестве примера взял работу Бартоломеуса ван Бассена (1651), где описанный только что принцип иллюстрируют сразу и пол, и флаги, и стены.

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

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

Сложно сказать, насколько сильно история изобразительного искусства повлияла на популярное суждение про “пересекающиеся параллельные прямые”, но знакомство с полотнами голландских живописцев свою роль тут наверняка сыграло.

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

Руны входят в таблицы Unicode. (“Обобщённые” символы Unicode тоже называют рунами, но в нашем случае – речь про конкретное подмножество, про англосаксонские руны.) Используемое кодирование (представление Unicode) занимает по три байта на каждую руну. При этом для записи 40 битов (пять байтов) в Base32 используется 8 символов: каждый символ несёт пять битов, откуда, собственно, число 32 == 2^5. То есть, получается, что Base32 на основе рунического письма в Unicode превращает пять байтов исходных данных в 24 байта (восьмибитных) закодированного текста. Не очень-то экономно. Оригинальный вариант Base32, построенный на латинском ASCII-алфавите и ASCII-цифрах, даёт результат лучше: пять байтов кодируются восемью байтами (если при кодировании текста используется привычное, 8-битное, представление байта). Но руны выглядят интереснее, что подтверждается скриншотом ниже, на котором запечатлён TLS-сертификат, записанный в runic32.

Примеры использования утилиты, написанной на Go, приведены на странице репозитория Runic32 в GitHub.

Спутниковая система интернет-доступа Starlink включает весьма продвинутые наземные терминалы, оснащённые АФАР (если судить по опубликованной информации о внутреннем устройстве терминалов, там установлена именно активная решетка – см. познавательный обзор по ссылке в конце записки). Некоторое время назад я уже писал, что, в теории, огромная спутниковая группировка Starlink может являться фундаментом для мощного орбитального радара, подобных которому ещё не было. Если к этой гипотезе присоединить множество наземных станций (терминалов), которые также управляются центрально и имеют общий источник синхронного времени, то возможности этого комплекса, как радара, взлетают, так сказать, до небес.

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

Другими словами, мощные наземные терминалы, – без которых, понятно, Starlink, как система связи, не имеет смысла, – расширяют и возможности “побочного” применения этого уникального комплекса. На картинке ниже – внешний вид антенной решётки терминала Starlink, а ссылка ведёт на подробный разбор (в прямом смысле) этого интересного устройства (англ. Youtube.com).

(Starlink Dishy Teardown.)

Немного занимательных математических основ криптографии.

Российская криптосистема электронной подписи (ГОСТ 34.10-2012) работает в группе точек эллиптической кривой над конечным полем, как и криптосистема ECDSA, широко используемая в TLS и в других протоколах защиты информации. Можно ли устроить так, чтобы открытый и секретный ключи для ГОСТ-подписи и ECDSA – совпадали? Дело в том, что если ключи одинаковые, то это добавляет удобства: например, можно использовать некие унифицированные сертификаты. Естественно, это чисто теоретической вопрос, но он довольно занятный. Если вынести за скобки криптографические параметры и способ интерпретации битовых строк, то главное отличие между ГОСТ-подписью и ECDSA состоит в уравнениях, используемых этими криптосистемами. Упростим ситуацию и рассмотрим лишь уравнения вычисления значения подписи:

ECDSA: s = k^(-1)(h + rd)

ГОСТ: s = (rd + kh)

Здесь использованы общие буквенные обозначения: h – это подписываемое значение (можно считать, что это значение хеш-функции от сообщения – натуральное число); k – случайный параметр (натуральное число); r – значение х-координаты вычисляемой на основе k “случайной” точки кривой (это элемент конечного поля, но и его в нашем случае можно понимать как натуральное число), d – секретный ключ (натуральное число). Здесь везде опущены упоминания того, что значения вычисляются по модулю порядка группы точек, связанной с точкой-генератором G, но, опять же, это нисколько не помешает изложению.

Итак, сразу видно, что секретные ключи d для обоих вариантов математически эквивалентны, так как секретный ключ – это натуральное число. Это так и есть на практике, с оговоркой, что значение секретного ключа должно лежать в некотором интервале, но это технические детали. На практике, вряд ли имеет смысл использовать небольшое значение d, которое может оказаться угадываемым. То есть и для ГОСТ-подписи, и для ECDSA в качестве секретного ключа можно использовать одно и то же значение. Если оно находится в подходящем интервале, то в работе алгоритмов, реализующих криптосистемы, равным счётом ничего не поменяется.

Как быть с соответствующими открытыми ключами? С открытыми – уже не так просто. Открытый ключ в обоих криптосистемах – это точка кривой, полученная в результате “умножения” точки-генератора G на число d (значение секретного ключа): открытый ключ Q == dG. “Умножение” здесь взято в кавычки по той причине, что для точек кривой никакого умножения не определяется, но есть “повторное сложение” точек: так, 3*A == A + A + A, где A – точка кривой. Повторное сложение и позволяет ввести умножение на скаляры (на целые числа). Итак, открытый ключ – точка кривой Q – это пара координат (x, y). Значения координат, x и y, – элементы поля, над которым рассматривается кривая. Именно здесь и кроется отличие: штатно, обсуждаемые криптосистемы используют разные кривые и разные поля, поэтому полученные значения открытого ключа будут различными, если, конечно, мы хотим сохранить корректность прочих операций (а корректность сохранить необходимо).

Таким образом, из-за использования разных криптографических параметров (уравнения кривой, базового поля, точки-генератора), для одного и того же значения секретного ключа значения открытых ключей, вообще говоря, в ECDSA и ГОСТ-подписи не совпадут. Однако, если использовать одно и то же поле, одну и ту же кривую и генератор, то и значения открытых ключей будут равны, поскольку и в одной, и в другой криптосистеме – открытый ключ Q == dG. Обе криптосистемы могут работать на общей кривой – математические операции не отличаются. Понятно, что так как уравнения подписи разные, то подписи для одного и того же значения не будут совпадать, даже если ключи удалось привести к “единому формату”. (Естественно, подписи для сообщений могут отличаться и из-за использования разных хеш-функций.) Однако все операции (вычисление подписи, проверка) останутся корректными и для ECDSA, и для ГОСТ-подписи. Поэтому использовать, буквально, одну и ту же пару ключей (секретный – для вычисления подписи, а открытый – для проверки) уже окажется возможным.

Конечно, так как практические криптосистемы включают в свой состав не только математические операции, но и конкретные значения параметров, подобное объединение ключей вряд ли реализуемо за пределами занимательного упражнения.