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

Кстати, индекс 0x6399, который позволяет отличить ключи криптосистемы X25519Kyber768Draft00 в TLS-сообщениях, внесён в соответствующий реестр номеров IANA, в раздел под именем TLS Supported Groups. Название раздела – ещё один пример исторически сложившихся особенностей спецификаций: понятно, что X25519Kyber768 – никакая ни группа, а сразу две криптосистемы, построенные на различном математическом аппарате (но, естественно, группы нетрудно найти и в X25519, и в Kyber768). Изначально, упомянутый раздел параметров TLS содержал индексы именованных эллиптических кривых, то есть, сочетаний из параметров, определяющих конкретную кривую в прикладном смысле. Но так как для криптосистем существенны были именно операции в группе, а кроме эллиптических кривых ещё использовались (и используются) мультипликативные группы колец вычетов, то раздел, довольно давно, переименовали в “Поддерживаемые группы”, теперь туда записывают наборы криптосистем.

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

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

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

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

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

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

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

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

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

Картинка ниже иллюстрирует эффект применения таблицы подстановок (π) из состава шифра “Кузнечик”: верхняя часть – это последовательно увеличивающиеся (слева направо или наоборот – как хотите) значения байтов, биты конкретного байта записаны вертикально, синий пиксель – единица (или нуль, но тогда зелёный – единица); нижняя часть – замена по таблице подстановок, где байт в данном столбце заменяется на соответствующее значение из таблицы. Способ применения таблицы максимально простой – значение входного байта заменяется на байт из таблицы, соответствующий по номеру, например, 0x00 заменяется на 0xFC и так далее, для каждого значения от 0x00 до 0xFF. Состав подстановок зафиксирован спецификацией шифра.

Хорошо виден основной эффект: в результате замены, расстояние между байтами возрастающей последовательности увеличивается, а “статистика”, порождаемая алгоритмом (n+1), скрывается. Подобные таблицы замены относятся к основным элементам, используемым при построении современных шифров. Естественно, сама по себе таблица никакой стойкости не обеспечивает, но, например, решает важную задачу “быстрого” размывания последовательностей “близких” значений во входных данных. Значения для замены специально подбираются так, чтобы эффективно решать именно эту задачу. От таблиц замены зависит стойкость шифров, так что исследование их свойств имеет большое значение (в том числе, с точки зрения обнаружения возможных архитектурных бэкдоров), в частности, конкретно с таблицами “Кузнечика” связана целая серия работ, но это тема для другой записки. Возможно, я напишу подробное описание работы шифра “Кузнечик” для dxdt.ru. С цветными картинками. (“Магма”, второй шифр из соответствующих ГОСТ, – достаточно давно подробно описан.)

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

Так, если взять в качестве примера привычную запись текста на естественном языке, то простой шифр алфавитной замены (“А” -> “Д”, “Б” -> “Э” и т.д.: буквы заменяются на буквы по перестановке того же алфавита, ключом является перестановка) не обладает только что описанным свойством: если попросить “коробочку” зашифровать слово “длинношеее”, то результат, очевидно, получится угадываемым (ну, конечно, в той степени, в какой вообще можно поверить в случайные биты).

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

Интересно, что внесение дополнительного слоя сохранения некоторых статистических характеристик является одной из теоретических областей создания алгоритмических закладок/бэкдоров в шифрах. Представьте блочный шифр. То есть, такой шифр, который на вход получает, предположим, строго 256 битов и 256-битный ключ, а выводит тоже строго 256 битов шифротекста. Многие современные шифры так работают. Если шифр идеальный, то вывод будет равновероятным, а для успешного поиска нужно будет перебирать, хотя бы, 2^255 вариантов.

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

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

В статье из 2019 года, посвящённой блокировкам и блокированию протоколов в Интернете, я писал вот что:

Среди перспектив развития систем контроля трафика (именно контроля) можно отметить пропуск только авторизованного трафика. Конечно, такой вариант пока кажется фантастикой. Авторизация трафика — это развитие схемы с белыми списками. В этом случае доступ по спискам IP-адресов и имен не ограничивается, но промежуточные узлы пропускают только трафик, который содержит специальные криптографические маркеры, подтверждающие его легитимность.

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

Криптография, а точнее – криптология, работает, к сожалению, в обе стороны. Так, на первый взгляд, может показаться, что обеспечение строгой конфиденциальности подразумевает невозможность проверки содержания трафика на соответствие политикам блокировок: как же промежуточный узел будет инспектировать зашифрованный трафик, если раскрытие этого трафика нарушит конфиденциальность?

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

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

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

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

Цитата из моего технического описания TLS:

Весьма полезной практикой является разумное выравнивание стойкости используемых криптосистем. Например, в подавляющем большинстве случаев не имеет смысла использовать RSA-ключ длиной в 4096 бит, если ваш TLS-сервер всё ещё поддерживает SSLv3, а в качестве симметричного шифра применяет DES с 56-битным ключом.

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

Дело в том, что аутентификация с использованием ключа из сертификата происходит на начальном этапе. Заметьте, кстати, что в устаревшей схеме с “зашифрованием RSA”, проверка того, что серверу известен соответствующий сертификату секретный ключ, вообще косвенная: предполагается, что раз сервер смог прийти к одинаковым с клиентскими значениям сеансовых ключей, то у сервера сеть доступ к секретному ключу (при использовании современной схемы, с протоколом Диффи-Хеллмана, клиентом проверяется именно подпись, что несколько меняет ситуацию). Так или иначе, но после установления соединения для аутентификации трафика используются уже сеансовые ключи, а если их удалось раскрыть, то активный перехватывающий узел сможет произвольным образом подменить полезные данные внутри сессии, как если бы эти данные передавал подлинный сервер – то есть, подменить источник. Таким образом, хоть формально аутентификация и проводится с другим, стойким ключом, нестойкий сеансовый ключ уничтожает большую часть смысла такой аутентификации. Речь, естественно, про TLS, а за скобками остались пояснения о том, что раскрытие конкретного шифротекста и раскрытие конкретного ключа – разные вещи (это несколько другая история).

В TLS 1.3 криптосистема RSA для зашифрования не используется, а процесс получения сеансовых ключей (за некоторыми исключениями) основывается на протоколе Диффи-Хеллмана и состоит из нескольких этапов. Тем не менее, раскрытие сеансовых симметричных ключей и тут приводит к тому, что активный атакующий может подменить трафик, выступив вместо одной из сторон после того, как соединение установлено.

Случайные числа, – которые, чаще, псевдослучайные, – сейчас нужны всюду. В том числе, при нормальном функционировании операционных систем, что порождает занимательные случаи. Например, мне приходилось сталкиваться со следующим “загадочным явлением”: после установки на достаточно старый, но с некоторыми аппаратными обновлениями (см. ниже, это важный момент), компьютер современной версии ОС на базе 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 должны проводить сами пользователи, по отпечаткам, которые им выводит приложение. Это тоже важный момент.

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

Обычно, протокол Диффи-Хеллмана (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, хоть и использует весьма нетривиальные превращения в качестве основной операции.