книги / Практическая криптография

порождает всю группу Z*. И р и д являются открытыми константами этого протокола, поэтому предполагается, что они известны всем участникам об­ щения, включая и злоумышленников. Схема обмена ключами приведена на рис. 12.1. Это один из общепринятых способов схематического изображения криптографических протоколов. У нас есть два участника: пользователь А и пользователь Б. Шкала времени направлена сверху вниз. Вначале поль­ зователь А выбирает случайное число х из множества Z*, что эквивалентно выбору случайного числа из диапазона 1 ,... ,р — 1. Пользователь А вычисля­ ет дх mod р и отсылает результат пользователю Б, который, в свою очередь, выбирает из множества Z* случайное число у. Он вычисляет ду mod р и отсы­ лает результат пользователю А. Окончательное значение секретного ключа выглядит как дху. Пользователь А может вычислить это значение, возведя число ду, полученное от пользователя Б, в известную ему степень х. (Еще раз вспомним школьный курс математики: (ду)х = дху.) Аналогичным образом пользователь Б может вычислить значение ключа к как {дх)у. Оба пользова­ теля получат одно и то же значение к, которое может применяться в качестве секретного ключа.

А что же наш злоумышленник? Он может перехватить значения дх и ду) но не знает х или у. Задача вычисления дху по заданным дх и ду известна как проблема Диффи-Хеллмана (сокращенно DH). Если числа р и д вы­ браны должным образом, тогда эффективного алгоритма вычисления дху не существует, по крайней мере нам таковой не известен. Наилучший из суще­ ствующих методов состоит в том, чтобы вначале вычислить х по известному дх, после чего подсчитать значение к как (ду)х — именно так, как это делает пользователь А. На множестве действительных чисел вычисление х по задан­ ному дг* называется функцией логарифма. Ее можно найти на любом инже­ нерном калькуляторе. В конечном поле Z* эта функция называется дискрет­ ным логарифмом (discrete logarithm). В общем случае задача вычисления х по заданному дх над конечной группой известна как проблема дискретного логарифма, или DL.

Первоначальная версия протокола DH имеет множество способов приме­ нения. Мы рассмотрели ее на примере обмена сообщениями между двумя участниками. Еще один возможный вариант — обратиться к каждому по­ тенциальному участнику общения с просьбой выбрать случайное х и опуб­ ликовать свое значение дх mod р в цифровом эквиваленте телефонной кни­ ги. Теперь, если пользователь А захочет пообщаться с пользователем Б, он находит в телефонной книге значение ду и подсчитывает дху для своего х. Пользователь Б может точно так же подсчитать значение дху без какого-ли­ бо предварительного взаимодействия с пользователем А. Такую схему удоб­ но использовать в окружениях наподобие системы электронной почты, где участники общения не взаимодействуют напрямую.

12.3Атака посредника

К сожалению, базовый протокол Диффи-Хеллмана не защищен от так называемой атаки посредника (man-in-the-middle attack). Давайте еще раз взглянем на протокол. Пользователь А знает, что он с кем-то общается, но не знает, с кем именно. Злоумышленник Е может вклиниться в протокол, имитируя пользователя Б при общении с пользователем А, а также имити­ руя пользователя А при общении с пользователем Б. Схема этого процес­ са приведена на рис. 12.2. Для пользователя А данный протокол выглядит точно так же, как настоящий протокол Диффи-Хеллмана. Пользователь А никак не сможет определить, что он общается со злоумышленником Е, а не с пользователем Б. Это же справедливо и по отношению к пользователю Б. Злоумышленник Е сможет поддерживать видимость такого общения столько, сколько захочет. Представим себе, что пользователи А и Б начали общаться друг с другом, используя секретный ключ, который, как им кажется, они выбрали вдвоем. Все, что требуется от злоумышленника Е, — это послушно пересылать сообщения, отправленные пользователем А пользователю Б и на­ оборот. Разумеется, злоумышленник Е должен расшифровывать сообщения, полученные от пользователя А, который зашифровал их с помощью ключа к, а затем заново зашифровывать эти сообщения с помощью ключа к1, чтобы отослать пользователю Б. Аналогичные операции нужно проделывать и над трафиком, идущим в другом направлении, однако больших усилий это не потребует.

Осуществить атаку посредника на цифровую телефонную книгу гораздо сложнее. Если лицо, опубликовавшее телефонную книгу, проверяет личность каждого человека, который присылает свое значение дх, пользователь А мо­ жет быть уверен в том, что он использует значение дх пользователя Б. Позд-

Рис. 12.2. Атака посредника на протокол Диффи-Хеллмана

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

Существует одно окружение, которое позволяет противостоять атаке по­ средника без внедрения какой-либо дополнительной инфраструктуры. Если ключ к применяется для шифрования телефонных разговоров или видео­ связи, пользователь А может поговорить с пользователем Б и узнать его по голосу. Пусть h — это некоторая функция хэширования. Если пользова­ тель Б прочитает пользователю А несколько первых разрядов значения h(k), пользователь А сможет проверить, действительно ли он использует тот же секретный ключ, что и пользователь Б. Данное решение приносит хорошие результаты, однако только в тех ситуациях, когда знание ключа к можно связать с реальным человеком, находящимся “по ту сторону общения”. Одна­ ко большинство компьютерных коммуникаций не предоставляют такой воз­ можности. Кроме того, злоумышленник Е может создать синтезатор речи, имитирующий голос пользователя Б. И наконец, самый большой недостаток этого решения — необходимость соблюдения пользователями строгой дисци­ плины. Но, как известно, пользователи сплошь и рядом игнорируют правила безопасности.

12.4 “Подводные камни” реализации

Реализация протокола DH может таять в себе массу подвохов. Например, если злоумышленник Е вмешивается в общение и заменяет оба числа дх и ду единицей, у пользователей А и Б оказывается ключ к = 1. В результате мы получаем протокол согласования ключей, который безупречен во всем, кроме одного: злоумышленник Е знает секретный ключ. Это, конечно же, очень плохо, а значит, нам нужно каким-либо образом предотвратить подобную атаку.

Еще одна распространенная проблема возникает тогда, когда образую­ щий элемент д не является примитивным элементом группы Z*, а порож­ дает лишь небольшую подгруппу. Пусть порядок д равен одному миллиону. В этом случае множество { 1,д, д2, ..., дч~1} содержит лишь миллион элемен­ тов. Поскольку в этом множестве оказывается и ключ к, злоумышленник Е сможет легко перебрать все варианты в поисках подходящего ключа. Оче­ видно, одно из требований состоит в том, чтобы у числа д был более высокий порядок. Но кто выбирает р и д? Все пользователи работают с одними и теми же значениями р и д, поэтому большинство из них получают эти значения от кого-нибудь другого. Для обеспечения безопасности общения они должны убедиться в том, что значения р и д выбраны правильно. Каждый из пользо­ вателей А и Б должен проверить, что р является простым числом и что д — это примитивный элемент группы по модулю р.

Отдельную проблему образуют подгруппы по модулю р. Пользователь Б может легко распознать атаку злоумышленника Е, заменившего дх на 1; для этого достаточно лишь проверить соответствующее число. Но злоумышлен­ ник Е может заменить дх числом h, имеющим низкий порядок. В этом случае ключ, сгенерированный пользователем Б, будет принадлежать множеству, порожденному элементом h. Поскольку количество элементов этого множе­ ства невелико, злоумышленник Е сможет легко перебрать все значения, что­ бы найти к. (Разумеется, эта же атака может быть осуществлена и по отно­ шению к пользователю А.) По этой причине пользователям А и Б необходимо проверять, не порождают ли полученные ими числа подгрупп с малым коли­ чеством элементов.

Давайте еще раз взглянем на подгруппы. При работе по модулю просто­ го числа все (мультипликативные) подгруппы могут быть порождены одним элементом. Вся группа Z* состоит из элементов 1,... , р - 1. Каждая подгруп­ па может быть представлена в виде 1, Л, /г2, h3, ... ,Л9-1, где h — некоторый элемент группы Z*, a q — порядок h. Как уже отмечалось, оказывается, что q должно быть делителем р — 1. Другими словами, размер любой подгруп­ пы должен быть делителем р - 1. Справедливо и обратное утверждение: для любого числа d, являющегося делителем р — 1, существует одна подгруппа

размера d. Если мы хотим, чтобы в группе не было подгрупп малых размеров, следует избегать чисел р - 1, имеющих малые делители.

Проблема заключается вот в чем. Если р — это большое простое число, тогда р—1 всегда будет четным, а значит, будет делиться на 2. Таким образом, у нас всегда будет присутствовать подгруппа, состоящая из двух элементов: 1 и р — 1. Тем не менее, за исключением этой подгруппы, можно избежать наличия других подгрупп малых размеров, требуя, чтобы число р —1 не имело других малых делителей.

12.5 Надежные простые числа

Наше решение состоит в том, чтобы использовать в качестве р надежное простое число (safe prime). Это достаточно большое простое число вида 2</+1, где q — также простое число. В этом случае мультипликативная группа Z* будет иметь следующие подгруппы:

•тривиальная подгруппа, состоящая только из числа 1;

•подгруппа размером 2, состоящая из элементов 1 и р — 1;

•подгруппа размером q;

•подгруппа размером 2q.

Первые две подгруппы тривиальны, и справиться с ними совсем неслож­ но. Третья — это и есть та группа, которую мы хотим использовать в схеме Диффи-Хеллмана. Последняя подгруппа, которая и является полной груп­ пой ZJ, обладает одним существенным недостатком. Рассмотрим множество всех чисел по модулю р, которые являются квадратом какого-нибудь друго­ го числа (разумеется, по модулю р). Оказывается, что половина всех чисел 1,... ,р - 1 являются квадратами, а половина — не являются. Любой прими­ тивный элемент, порождающий всю группу, не может быть квадратом. (Если бы он был квадратом, тогда возведение этого числа в степень всегда давало бы квадрат, а значит, мы бы никогда не смогли породить элементы группы, которые не являются квадратами.)

В математике существует функция, называемая символом Лежандра (Legendre symbol). Она позволяет определить, является ли число по моду­ лю р квадратом, не находя самого квадратного корня. Существуют эффек­ тивные алгоритмы для вычисления символа Лежандра. Таким образом, ес­ ли образующий элемент g не является квадратом и мы посылаем р1, тогда любой наблюдатель (например, злоумышленник Е) сразу же сможет опреде­ лить, что за число х — четное или нечетное. Если х четное, тогда дх являет­ ся квадратом. Если х нечетное, тогда дх не является квадратом. Поскольку злоумышленник Е может использовать символ Лежандра, чтобы определить,

является ли число квадратом, он может узнать, что за число х — четное или нечетное. Перед нами случай исключительного поведения: злоумышленник Е не может узнать значение х, за исключением наименее значимого бита. Что­ бы избежать этой проблемы, необходимо использовать только квадраты по модулю р. Последние и образуют ту самую подгруппу порядка q. Еще од­ но замечательное свойство состоит в том, что q — простое число, а значит, вложенных подгрупп у нас не будет.

Вот как использовать надежное простое число. Выберите пару (р, q), та­ кую, что р = 2q + 1 и оба числа р и q являются простыми. (Для этого можно воспользоваться функцией ISPRIME и методом проб и ошибок.) Выберите случайное число а в диапазоне 2 ,... ,р - 2 и установите д = a2(mod р). Убе­ дитесь, что д ф 1 и д ф р —1. (Если д будет равно одному из этих запрещен­ ных значений, выберите другое а и повторите попытку.) Полученный набор параметров (р, q, д) вполне годится для использования в протоколе ДиффиХеллмана.

Каждый раз, когда пользователь А (или Б) получает значение, которое, как предполагается, является степенью д, он должен проверить, действитель­ но ли полученное значение попадает в подгруппу, порожденную числом д. Ес­ ли вы используете надежное простое число так, как было описано выше, для проверки членства в подгруппе можно воспользоваться символом Лежандра. Существует также более простой, хотя и более медленный метод. Число г является квадратом тогда и только тогда, когда г9 = l(modp). Мы также рекомендуем запретить использование числа 1, потому что оно всегда при­ водит к проблемам. Тогда окончательный вариант условия будет выглядеть следующим образом: г ф 1 A г9mod р = 1.

12.6Использование подгрупп меньшего размера

Недостаток использования метода надежных простых чисел — низкая эф­ фективность. Если длина простого числа р равна п бит, тогда длина q равна я —1 бит, а значит, все показатели степеней будут иметь длину п —1 бит. Сред­ няя операция возведения в степень будет включать в себя около Зтг/2 умно­ жений по модулю р. Для больших чисел р такой объем работы выглядит достаточно громоздким.

Стандартным решением этой проблемы является использование подгрупп меньшего размера. Вот как это делается. Вначале в качестве q выбирается 256-битовое простое число. (Другими словами, 2255 < q < 2256.) Затем необ­ ходимо найти намного большее простое число р, такое, что р = Nq + 1 для некоторого произвольного N. Для этого выберем случайное число N из под­ ходящего диапазона, вычислим значение р как Nq + 1 и проверим, является

ли р простым. Поскольку р должно быть нечетным, очевидно, что N должно быть четным. Длина простого числа р будет составлять несколько тысяч бит.

Теперь нужно найти элемент порядка q. Это делается точно так же, как

ив методе надежных простых чисел. Выберем случайное а из группы 2*

иустановим д = aN. Теперь убедимся, что д ф 1 и gq = 1. (Случай д = р -1 охватывается вторым условием, потому что q — нечетное.) Если полученное значение д не удовлетворяет этим условиям, выберите другое а и повторите попытку. Полученный набор параметров (р, д, д) пригоден для использования в протоколе Диффи-Хеллмана.

Когда используется подгруппа меньшего размера, значения, которыми об­ мениваются пользователи А и Б, всегда попадают в подгруппу, порожденную д. Между тем злоумышленник Е может вмешаться в процесс общения и за­ менить дх абсолютно другим значением. Таким образом, каждый раз, ко­ гда пользователь А или Б получает значение, которое, как предполагается, должно находиться в подгруппе, порожденной д, он должен проверить, дей­ ствительно ли это так. Выполнение проверки происходит точно так же, как

ив методе надежных простых чисел. Число г находится в нужной подгруппе, если г ф 1Дг9mod р = 1. Разумеется, следует проверить и то, не попадает ли

гза пределы диапазона чисел по модулю р, поэтому полное условие проверки должно выглядеть как 1 < г < р А г 9 = 1.

Для всех элементов г подгруппы, порожденной д, справедливо равенство rq = 1. Таким образом, чтобы возвести число г в некоторую степень е, доста­ точно подсчитать re modя. Это может значительно сократить объем работы, особенно если е намного больше, чем q.

Насколько эффективен метод подгрупп? Длина большого простого чис­ ла р составляет, как минимум, 2000 бит. В методе надежных простых чисел вычисление дттребует около 3000 умножений. При использовании подгрупп это число сокращается примерно до 384, так как значение х можно взять по модулю q, в результате чего длина х составит лишь 256 бит. Как видите, во втором случае для вычисления дх выполняется почти в 8 раз меньше дей­ ствий, чем в первом. Чем больше значение р, тем больше экономия усилий. Вот почему подгруппы так широко применяются в криптографии.

12.7Размер р

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

242 Глава 12. Алгоритм Диффи-Хеллмана

мере развития компьютерных технологий можем выбирать ключи все боль­ шего и большего размера.

Лучшие оценки того, какой длины должно быть число р, содержатся в работе [62]. Согласно предположениям ее авторов, простое число длиной 2048 бит сможет обеспечить защиту данных до 2022 года, число длиной 3072 бит — до 2038 года, а число длиной 4096 бит — до 2050 года. Упоминав­ шееся нами число 6800 было получено с использованием все тех же формул, приведенных в [62]. Именно этот размер р гарантирует, что для осуществле­ ния атаки злоумышленнику придется выполнить 2128 шагов.

Будьте крайне осторожны с прогнозами подобного рода. Разумеется, все они имеют под собой серьезные основания, однако попытки предсказания будущего всегда небезопасны. Мы можем сделать некоторые осмысленные предположения относительно размеров ключей на протяжении следующих 10 лет, однако всякие рассуждения о том, как будут обстоять дела через 50 лет, достаточно наивны. Сравните хотя бы текущее положение дел в ком­ пьютерной индустрии и криптографии с тем, что наблюдалось 50 лет назад. Прогнозы, приведенные в [62], — это лучшие оценки на сегодняшний момент, однако безоговорочно доверять им тоже не стоит.

Так что же нам делать? Как разработчики криптографических систем, мы должны выбрать размер ключа, который сможет обеспечить безопас­ ность системы на протяжении по крайней мере следующих 20 лет. Очевидно, 2048 бит — это нижняя граница. Чем больше, тем лучше; но использование ключей большего размера значительно повышает затраты. Учитывая такую неопределенность ситуации, мы предпочитаем скептическую точку зрения. Наш совет выглядит следующим образом: используйте 2048 бит в качестве абсолютного минимума. (И не забывайте, что с течением времени этот ми­ нимум будет повышаться.) Если позволяет производительность системы, ис­ пользуйте 4096 бит или около того. И еще: обязательно убедитесь, что ваша система способна работать с параметрами размером до 8192 бит. Это спасет положение в случае неожиданного усовершенствования атак на системы с от­ крытым ключом. Новые достижения криптоанализа практически неминуемо приведут к осуществлению успешных атак на ключи меньших размеров. Пе­ реход на ключи ббльших размеров можно проводить прямо во время работы системы. Разумеется, это определенным образом скажется на производитель­ ности, однако основная функциональность системы будет сохранена. Это на­ много лучше, чем полная потеря безопасности и необходимость переделывать всю систему, что потребуется, если система не поддерживает ключи большего размера.

Некоторые приложения требуют, чтобы секретность их данных сохраня­ лась намного дольше 20 лет. В этом случае большие ключи необходимо ис­ пользовать уже сейчас.