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

Ещё о пресертификатах в Certificate Transparency (CT) и странных “свойствах”, которые возникают вокруг. TLS-сертификаты превращаются в пресертификаты после того, как добавлено специальное расширение Poison. Может показаться, что с этим расширением тоже связана проблема “курицы и яйца”, поскольку нарушать процесс валидации poison-расширение должно потому, что оно помечено как Critical (критическое), но имеет тип, неизвестный валидатору – неизвестные критические типы, согласно рекомендациям, должны приводить к тому, что сертификат считается невалидным (а вот расширения неизвестного типа, которые не помечены как критические, можно игнорировать). Если же валидатор знает тип poison-расширения, то флаг Critical уже не должен препятствовать валидации. Это так, однако проблемы тут нет: в том случае, когда валидатор распознал poison-расширение, он не должен принимать сертификат на правах валидного, так как, грубо говоря, видит, что это пресертификат (ну или можно интерпретировать иначе: наличие poison-расширения означает, что сертификат не должен использоваться так же, как и сертификат без Poison). В общем, всё же появляется неплохой шанс выстроить однозначный процесс валидации.

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

При вычислении подписи для пресертификата сервис CT-лога использует в качестве входных данных не весь сертификат, а только его “содержательную часть” (некоторое зафиксированное в структуре подмножество полей), из которой, к тому же, удаляется poison-расширение. Это, что называется, первый “сюрприз”: poison-расширение должно присутствовать в составе поступающего пресертификата не только потому, что оно и делает сертификат пресертификатом, но и потому, что иначе не сойдётся подпись УЦ на пресертификате, а подпись должен проверить сервис лога. Дописать какие-то данные в сертификат не выйдет. Однако поскольку в сертификате Poison удаляется, то и подпись в SCT нужна на данных без poison-расширения. Второй “сюрприз”: при проверке подписи SCT в сертификате – нужно восстановить содержательную часть пресертификата в точно таком виде, какой передавался в сервис CT-лога, но с учётом удаления Poison – то есть, нужно удалить “лишние” расширения (SCT-метки), а те расширения, которые останутся, должны совпасть с конфигурацией пресертифката. А поскольку такое преобразование снова удаляет из состава сертификата значение подписи, к данным сертификата, перед проверкой, вместе с другими служебными параметрами SCT, нужно присоединить отпечаток открытого ключа УЦ. Понятно, что то же самое делается и на стороне CT-лога, при формировании SCT. Так что общий алгоритм местами “макаронный”, но, тем не менее, используется. Не удивительно, что в новой версии CT пресертификатов нет.

Омоглифы – это символы, совпадающие по начертанию, но различные по значению (интерпретации). Например, Н, H и Η, а именно – заглавная кириллическая “н”, заглавная “h” английского алфавита и заглавная “η” греческого алфавита. Пришлось тут столкнуться с забавной “программной” интерпретацией данного явления. Пакет Gitea (это пакет для работы с исходным кодом в git, с веб-интерфейсом и прочими полезными функциями) при попытке посмотреть некий русскоязычный текстовый файл из репозитория на сервере – показывал мне в браузере предупреждение, что “This file contains ambiguous Unicode characters!” (“Этот файл содержит “неоднозначные” символы Unicode!”). И действительно, встроенный фильтр подсвечивал буквы вроде “a”, “T” и “о”, но не во всех случаях. Так, целиком подсвечивалось сочетание букв “То” из “То есть”. А в другом месте этого же текста подсвечивалась одинокая буква “а”, при помощи которой обозначался союз “а”.

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

(Уточнение: под “словами” подразумеваются последовательности омоглифов, обособленные пробелами.)

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

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

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

Наберём в консоли (в терминале) ping 010.010.010.010 и запустим выполнение – что произойдёт? Результат теперь многим и многим, – далеко не пользователям, а даже системным администраторам, – кажется неожиданным: “пинги” отправляются на один из адресов Google – 8.8.8.8. Проверьте самостоятельно (в экзотических ОС результат может отличаться, но в привычных линуксах, например, – всё вполне корректно, а экзотические ОС ещё предстоит подобрать).

Почему так вышло? Потому что старое системное соглашение, о котором нынче забывают, гласит: если запись октета IP-адреса (здесь – четвёртой версии) начинается с символа нуля и не содержит, следом, буквы, то это запись в восьмеричной системе! (Относится, конечно, не только к ping и не только к IP-адресам.) 10 в восьмеричной системе – это восемь, так что: 8.8.8.8. Неплохо взглянуть и на другие варианты: ping 010.8.010.8, например. А попытка вызвать ping 010.080.010.010 приведёт, скорее всего, к сообщению о том, что адрес для имени обнаружить не удалось (или Name or service not known – в типичном случае).

А оговорка насчёт буквы в предыдущем параграфе, конечно, это для 0x08, например. Но такая запись мало кого вводит в заблуждение.

Генераторы текстов на заданную тему сейчас вновь популярны. Пример, естественно, ChatGPT. Можно ли автоматическим способом и с высокой точностью определить, что некоторый обозримый текст на естественном языке написан таким качественным компьютерным генератором, а не человеком?

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

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

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

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

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

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

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

Всякое нечётное простое число можно записать как 11. Главное – правильно выбрать основание системы счисления. Например, 11 в двоичной – это три, простое число. (Заметьте, что запись чисел текстом предоставляет удобный способ избежать указания на основание и используемую систему, а вот запись текстом значений цифр – не позволяет такого.) В шумерской (вавилонской) системе, по основанию шестьдесят, цифра для 1 другая, но её можно вывести при помощи Unicode: 𒁹. Кстати, число, записываемое при помощи 67 (десятичная система) символов шумерских единиц с пробелами, которые обособляют разряды, полупростое:
𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹 𒁹
– а именно:
10942346421770308578818295975662675564975953490189742748487096625851 *
211919687148608455429372273841730969897555787140311 ==
2318898630373258980428992200086672458938582331333684067796610169491525423728813559322033898305084745762711864406779661

Пробелы нужны вот почему: 𒁹 𒁹 𒁹 == 3661 == 60^2 + 60^1 + 1; однако 𒁹𒁹𒁹 == 3.

Предположим, что мы зашифровали некоторый небольшой текст (десяток слов) на естественном языке, используя самый обычный способ – кодирование UTF-8 и какой-нибудь стойкий симметричный шифр, например, AES с 256-битным ключом (32 байта). Но ключ выбран специальным способом: 30 байтов из 32 зафиксированы и известны, а два байта (то есть, 16 бит) выбираются случайно. Потом получившийся шифротекст отправляется в некоторую программу, программа перебирает значения двух “секретных” байтов ключа и пытается расшифровать данные, каждый раз проверяя, получились ли в результате словарные слова в кодировке UTF-8 (если хотите более “криптологический” вариант, то можно брать биграммы/триграммы – это как раз детали, которые здесь не важны). Если получились слова, похожие на ожидаемый язык, то программа считает, что удалось успешно расшифровать данные и выдаёт открытый текст.

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

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

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

Разгадка cледующая. SSH-серверу просто не хватало локальной случайности – то есть, системного источника случайных чисел (/dev/random). Дело в том, что ядро (Linux) собирает энтропию для процесса, генерирующего (псевдо)случайные числа, так сказать, с доступной аппаратуры. В более или менее современных системах проблем с обильными источниками аппаратной энтропии нет, так или иначе, а вот если в очень старую систему на процессоре Intel поставить вместо шпиндельного винчестера SSD-накопитель, да отключить клавиатуру и видеокарту, то энтропии становится мало и её съедает само ядро при загрузке себя и сопутствующих модулей (напомню, что там есть всякие хитрые методы “рандомизации адресации”, направленные, как бы, на запутывание атакующих). Так как SSH-сервер использовал блокирующий вызов для получения случайных чисел (/dev/random вместо неблокирующего /dev/urandom), то ему приходилось ждать, пока накопится достаточно энтропии. SSH-серверу случайные числа нужны для криптографических операций, поэтому он и не мог принять входящее соединение. А вот если кто-то подключил клавиатуру, да ещё повозился в консоли, то энтропии становилось больше, хватало и для SSH. Чинится это либо установкой специального пакета типа haveged, который генерирует дополнительную энтропию программно (или программно-аппаратно, если хотите), либо добавлением аппаратного источника энтропии. Сейчас проблема менее актуальна: в дистрибутивы для платформ, где с получением энтропии трудности, haveged или подобное решение стали включать автоматически.

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

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

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

Telegram использует “классический” (или “мультипликативный”) вариант DH, работающий в мультипликативной группе конечного поля (сейчас такой вариант принято обозначать FFDH – от Finite Field). Если обойтись без строгих научных терминов, то этот вариант DH не “эллиптический” (например), а “обычный”, работающий в арифметике остатков. Про “эллиптический” вариант многие слышали применительно к TLS – там он называется ECDH(E). То, что в Telegram не используется современный вариант на эллиптической кривой – всегда выглядело несколько странно. Скорее всего, этому есть очень простое объяснение, связанное с историей появления протокола MTProto, но, так или иначе, эти детали остаются за рамками данной заметки, которая посвящена свойствам модулей DH и небольшому фрагменту исходного кода приложения, связанному с проверкой этих свойств.

Чтобы определить конкретные параметры протокола DH (FFDH, но не только) – требуется задать достаточно большое простое число. В случае “классического” варианта битовая разрядность этого числа, по современным представлениям, должна быть хотя бы 2048 бит. Telegram требует строго 2048 бит (см. ниже). Данное простое число задаёт базовую структуру для арифметики протокола и называется модулем. От свойств модуля зависит надёжность реализации. Так, слишком маленькая разрядность, – например, 256 бит, – позволяет очень быстро решать обратную задачу (находить дискретный логарифм) и вычислять по открытой информации секретное значение, которым обмениваются стороны. (Дежурное замечание: пример про 256 бит – не относится к разрядности ECDH, там другие алгоритмы и структуры.)

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

Перейдём к особенностям кода. Telegram – среди тех немногих приложений, разработчики которых заявляют так называемую “воспроизводимую сборку“: действительно, публикация исходного кода, сама по себе, не гарантирует, что исполняемое приложение, распространяемое в собранном виде, соответствует опубликованным исходникам. Telegram предлагает описание того, как можно самостоятельно проверить соответствие сборки исходникам. Это хорошо (если работает – я не проверял). Я рассматриваю некоторый исходный код, доступный на GitHub-е по опубликованной ссылке.

Простое число P, представляющее собой модуль DH, поступает с сервера в ответе на запрос getDhConfig, в виде массива байтов. Свойства проверяются в telegram/messenger/SecretChatHelper.java вызовом функции Utilities.isGoodPrime(P, G); (G – это генератор, второй параметр протокола.)

if (!Utilities.isGoodPrime(res.p, res.g)) {
 acceptingChats.remove(encryptedChat.id);
 declineSecretChat(encryptedChat.id, false);
 return;
}

Вся содержательная проверка – внутри isGoodPrime() (telegram/messenger/Utilities.java). Эта функция начинается следующим фрагментом:

if (!(g >= 2 && g <= 7)) {
 return false;
}

if (prime.length != 256 || prime[0] >= 0) {
 return false;
}

BigInteger dhBI = new BigInteger(1, prime);

Первый if проверяет интервал значений генератора.
Следующий if – контролирует разрядность переданного модуля. 256 байтов – это 2048 бит. prime[0] >= 0 – тут проверяется, что старший бит установлен в единицу. Этот оборот может показаться не самым очевидным: тип byte в Java определён со знаком, соответственно, если значение больше либо равно нулю, это означает, что старший бит – нулевой (знак записи числа “плюс”); представление целых чисел большой разрядности (BigInteger – см. следующие строки) здесь использует запись, в которой старший байт – байт с нулевым индексом. Таким образом, prime[0] >= 0 проверяет, что получающееся число будет не меньше, чем 2^2047. new BigInteger(1, prime) – создаёт объект BigInteger и загружает в него значение модуля из массива prime. Единица в левом параметре конструктора – обозначает, что число положительное. Зачем нужен выше фрагмент с if, проверяющий длину и значение старшего бита? Например, сервер мог бы передать 256 байтов, в которых старшие значения были бы нулевыми, тогда длина массива соответствовала бы заданному требованию, но реальная разрядность получившегося в BigInteger числа оказалось бы меньше, так как нулевые байты слева не учитывались бы.

Дальше следует блок (здесь пропущен) из нескольких if..else if, которые, в соответствии со значением генератора, проверяют остатки по простым 3, 5, 7 и некоторым степеням 2. Этот фрагмент, наверное, можно рассмотреть в отдельной заметке из области занимательной математики. Цель проверки – контроль свойств полученного модуля (этим фрагментом вся проверка “доверия серверу” исчерпывается).

А следующая пара строк в telegram/messenger/Utilities.java довольно занимательная (приведено с сокращениями, см. детали ниже):

String hex = bytesToHex(prime);
if(hex.equals("C71CA...")) {
 return true;
}

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

Непосредственно в коде зашит вот такой модуль (переносы строк добавлены для удобства – это одно число):

C71CAEB9C6B1C9048E6C522F70F13F73980D40238E3E21C14934D037563D930F
48198A0AA7C14058229493D22530F4DBFA336F6E0AC925139543AED44CCE7C37
20FD51F69458705AC68CD4FE6B6B13ABDC9746512969328454F18FAF8C595F64
2477FE96BB2A941D5BCD1D4AC8CC49880708FA9B378E3C4F3A9060BEE67CF9A4
A4A695811051907E162753B56B0F6B410DBA74D8A84B2A14B3144E0EF1284754
FD17ED950D5965B4B9DD46582DB1178D169C6BC465B0D6FF9CA3928FEF5B9AE4
E418FC15E83EBEA0F87FA9FF5EED70050DED2849F47BF959D956850CE929851F
0D8115F635B105EE2E4E15D04B2454BF6F4FADF034B10403119CD8E3B92FCC5B

Это простое число (ну, с точностью до детерминированной проверки в SAGE и вероятностной проверки в Mathematica, конечно; но это означает, что простое). То есть, в этом фрагменте – код строго верит в один конкретный модуль. Для других модулей предусмотрена проверка простоты (и статуса safe prime):

BigInteger dhBI2 = dhBI.subtract(BigInteger.valueOf(1)).divide(BigInteger.valueOf(2));
return !(!dhBI.isProbablePrime(30) || !dhBI2.isProbablePrime(30));

Здесь, с помощью вероятностного теста (это единственный способ – известные детерминированные алгоритмы слишком ресурсоёмкие), проверяется, что модуль P простое число и что (P-1)/2 – тоже простое. Обычная практика. На этом проверки заканчиваются (естественно, здесь не может быть никакой аутентификации и тому подобных дополнительных шагов).

Нужно отметить, что сравнение получившихся ключей в Telegram должны проводить сами пользователи, по отпечаткам, которые им выводит приложение. Это тоже важный момент.

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

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

Открытый исходный код на языке высокого уровня нужно воспринимать как удобный комментарий к внутреннему устройству того или иного программного пакета. Речь здесь о пакетах, которые распространяются среди конечных пользователей. То есть не о сервисах, работающих где-то в Интернете.

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

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

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

Другой момент, о котором постоянно забывают: а если в качестве открытых исходников опубликован код на ассемблере – это сильно помогает в поиске уязвимостей или уже меньше? Ассемблер, даже как явление, сейчас известен меньшему кругу специалистов, это да. Но можно же обфусцировать исходный код на С, да ещё так, что понять его будет посложнее, чем соответствующий кусок в машинных кодах x86.

Вообще, трудность в понимании записи произвольного, заранее не известного, алгоритма настолько фундаментальная, что, похоже, именно она и является причиной формулирования знаменитой проблемы P≟NP. Из этого, впрочем, следует вывод, что и в обратную сторону, – то есть, для превентивного выявления закладок/уязвимостей, – публикация исходников работает не так эффективно, как принято думать: дефекты не просто всегда есть, но они и могут долго оставаться незамеченными, к сожалению. Однако открытые исходники – там, где их возможно открыть – конечно, лучше, и публикация исходников, сама по себе, не делает программу или программную систему, которая распространяется по конечным пользователям, “более уязвимой”.