Автор: Андрей Винокуров

Второй недостаток данной схемы, быть может, менее заметен, но зато гораздо более серьезен. Дело в том, что пара ключей подписи и проверки в ней одноразовая! Действительно, выполнение процедуры подписи бита сообщения приводит к раскрытию половины секретного ключа, после чего он уже не является полностью секретным и не может быть использован повторно. Поэтому для каждого подписываемого сообщения необходим свой комплект ключей подписи и проверки. Это исключает возможность практического использования рассмотренной схемы Диффи–Хеллмана в первоначально предложенном варианте в реальных системах ЭЦП.

В силу указанных двух недостатков предложенная схемы до сравнительно недавнего времени рассматривалась лишь как курьезная теоретическая возможность, никто всерьез не рассматривал возможность ее практического использования. Однако несколько лет назад в работе [7] была предложена модификация схемы Диффи–Хеллмана, фактически устраняющая ее недостатки. В настоящей работе данная схема не рассматривается во всех деталях, здесь изложены только основные принципы подхода к модификации исходной схемы Диффи–Хеллмана и описания работающих алгоритмов.

2.6. Модификация схемы Диффи–Хеллмана для подписи битовых групп.

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

Таким образом рассмотренная модификация схемы Диффи–Хеллмана делает возможным подпись не одного бита, а целой битовой группы. Это позволяет в несколько раз уменьшить размер подписи и ключей подписи/проверки данной схемы. Однако надо понимать, что увеличение размера подписываемых битовых групп приводит к экспоненциальному росту объема необходимых вычислений и начиная с некоторого значения делает работу схемы недопустимо неэффективной. Граница «разумного размера» подписываемой группы находится где-то рядом с восемью битами, и блоки большего размера все равно необходимо подписывать «по частям».

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

Размер ключа подписи и проверки подписи можно дополнительно уменьшить следующими приемами:

1. Нет необходимости хранить ключи подписи отдельных битовых групп, их можно динамически вырабатывать в нужный момент времени с помощью генератора криптостойкой гаммы. Ключом подписи в этом случае будет являться обычный ключ использованного в схеме подписи блочного шифра. Для ГОСТа 28147–89 этот размер равен 256 битам, поэтому если схема подписи будет построена на ГОСТе, размер ключа подписи будет равен тем же 256 битам.

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

Таким образом, проблема размера ключей и подписи полностью решена, однако, главный недостаток схемы – одноразовость ключей – не преодолен, поскольку это невозможно в рамках подхода Диффи–Хеллмана. Для практического использования такой схемы, рассчитанной на подпись N сообщений, отправителю необходимо хранить N ключей подписи, а получателю – N ключей проверки, что достаточно неудобно. Однако эта проблема может быть решена в точности так же, как была решена проблема ключей для множественных битовых групп – генерацией ключей подписи для всех N сообщений из одного мастер-ключа и свертывание всех проверочных комбинаций в одну контрольную комбинацию с помощью алгоритма выработки хэш-кода. Такой подход решил бы проблему размера хранимых ключей, однако привел бы к необходимости вместе подписью каждого сообщения высылать недостающие N–1 проверочных комбинаций, необходимых для вычисления хэш-кода от массива всех контрольных комбинаций отдельных сообщений. Ясно, что такой вариант не обладает преимуществами

по сравнению с исходным. Однако в [7] был предложен механизм, позволяющий значительно снизить остроту проблемы. Его основная идея – вычислять контрольную комбинацию (ключ проверки подписи) не как хэш от линейного массива проверочных комбинаций всех сообщений, а попарно – с помощью бинарного дерева. На каждом уровне проверочная комбинация вычисляется как хэш от двух проверочных комбинаций младшего уровня. Чем выше уровень комбинации, тем больше отдельных ключей проверки в ней «учтено». Предположим, что

Заключение.

Стойкость предложенной схемы цифровой подписи определяется стойкостью использованного блочного шифра, а устойчивость ко вскрытию переборными методами –наименьшим из чисел n, nK. Ключевой комплект в данной схеме рассчитан на определенное число подписей, что, с одной стороны, может восприниматься как недостаток схемы, но с другой позволяет лицензировать количество подписей, облегчая тем самым ее коммерческое использование. Рассматриваемая схема подписи не соответствует стандарту России на цифровую подпись, а алгоритм вычисления MDC – стандарту на выработку хэш-кода массива данных, что делает невозможным аттестацию в соответствующих организациях устройств и программных продуктов, их реализующих. Однако изложенные схемы вполне могут быть использованы там, где спорные вопросы не могут быть вынесены на уровень арбитражных и судебных разбирательств, например, в системах автоматизации внутреннего документооборота учреждений, особенно если электронный документооборот не заменяет бумажный, а существует в дополнение к нему для ускорения прохождения документов.

В качестве приложения к настоящей статье приведены исходные тексты на языке ассемблера для процессоров клона Intel 8086 функции вычисления MDC для блоков данных и функции, реализующие алгоритмы описанной схемы цифровой подписи. Функция выработки хэш-кода (MDC) написана таким образом, что позволяет обрабатывать блоки данных по частям, то есть за несколько вызовов. Все функции используют в качестве основы алгоритм зашифрования по ГОСТ 28147–89. Также прилагаются тексты тестовых программ на языке Си для проверки неизменности файлов на основе MDC и цифровой подписи.

Литература.

• А.Ю.Винокуров. ГОСТ не прост...,а очень прост, М., Монитор.–1995.–N1.
• А.Ю.Винокуров. Еще раз про ГОСТ., М., Монитор.–1995.–N5.
• А.Ю.Винокуров. Алгоритм шифрования ГОСТ 28147-89, его использование и реализация для компьютеров платформы Intel x86., Рукопись, 1997.
• А.Ю.Винокуров. Как устроен блочный шифр?, Рукопись, 1995.
• М.Э.Смид, Д.К.Бранстед. Стандарт шифрования данных: прошлое и будущее. /пер. с англ./ М., Мир, ТИИЭР.–1988.–т.76.–N5.
• Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования ГОСТ 28147–89, М., Госстандарт, 1989.
• Б.В.Березин, П.В.Дорошкевич. Цифровая подпись на основе традиционной криптографии//Защита информации, вып.2.,М.: МП "Ирбис-II",1992.
• W.Diffie,M.E.Hellman. New Directions in cryptography// IEEE Trans. Inform. Theory, IT-22, vol 6 (Nov. 1976), pp. 644-654.
• У.Диффи. Первые десять лет криптографии с открытым ключом. /пер. с англ./ М., Мир, ТИИЭР.–1988.–т.76.–N5.