Предыдущая страница реферата | 5  6  7  8  9  10  11  12  13  14  15 | Следующая страница реферата

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

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

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

Предположим, что наша схема рассчитана на 2L сообщений. Обозначим через  i-тую комбинацию l-того уровня. Если нумерацию комбинаций и уровней начинать с нуля, то справедливо следующее условие: 0 Ј i < 2L–l, а i-ая проверочная комбинация l-того уровня рассчитана на 2l сообщений с номерами от iЧ2l до (i+1)Ч2l–1 включительно. Число комбинаций нижнего, нулевого уровня равно 2L, а самого верхнего, L-того уровня – одна, она и является контрольной комбинацией всех 2L сообщений, на которые рассчитана схема.

На каждом уровне, начиная с первого, проверочные комбинации рассчитываются по следующей формуле:

,

где через A||B обозначен результат конкатенации двух блоков данных A и B, а через H(X) – процедура вычисления хэш-функции блока данных X.

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

Пример организации проверочных комбинаций в виде двоичного дерева в схеме на восемь сообщений приведена на рисунке 4.1. Так, при передаче сообщения № 5 (контрольная комбинация выделена рамкой) вместе с его подписью должны быть переданы контрольная комбинация сообщения № 4 (C4(0)), общая для сообщений №№ 6–7 (C3(1)) и общая для сообщений №№ 0–3 (C0(2)), все они выделены на рисунке другим фоном.

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

C=C0(3)=H(C0(2)||H(H(C4(0)||C5(0))||C3(1))).

Необходимость отправлять вместе с подписью сообщения дополнительную информацию, нужную для проверки подписи, на самом деле не очень обременительна. Действительно, в системе на 1024=210 подписей вместе с сообщением и его подписью необходимо дополнительно передавать 10 контрольных комбинаций, а в системе на 1048576=220 подписей – всего 20 комбинаций. Однако, при большом числе подписей, на которые рассчитана система, возникает другая проблема – хранение дополнительных комбинаций, если они рассчитаны предварительно, или их выработка в момент формирования подписи.

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

Первый подход предполагает затраты дисковой памяти, так как необходимо хранить 2L+1–2 значений хэш-функции всех уровней, а второй требует большого объема вычислений в момент формирования подписи. Можно использовать и компромиссный подход – хранить все хэш-комбинации начиная с некоторого уровня l*, а комбинации меньшего уровня вычислять при формировании подписи.

В рассмотренной выше схеме подписи на 8 сообщений можно хранить все 14 контрольных комбинаций, используемых при проверки (всего их 15, но самая верхняя не используется), тогда при проверке подписи их не надо будет вычислять заново. Можно хранить 6 комбинаций начиная с уровня 1 (C0(1), C1(1), C2(1), C3(1), C0(2), C1(2)), тогда при проверке подписи сообщения № 5 необходимо будет заново вычислить комбинацию C4(0), а остальные (C0(2),C3(1)) взять из таблицы, и т.д.. Указанный подход позволяет достичь компромисса между быстродействием и требованиям к занимаемому количеству дискового пространства.

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

Атаки на ЭЦП

Стойкость большинства схем ЭЦП зависит от стойкости ассиметричных алгоритмов шифрования и хэш-функций.

Существует следующая классификация атак на схемы ЭЦП:

атака с известыи открытым ключем.

Атака и известными подписанными сообщениями – противник, кроме открытого кюча имеет и набор подписанных сообщений.

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

Направленная атака с выбором сообщения

Адаптивная атака с выбором сообщения.

Каждая атака преследует определенную цель, которые можно разделить на несколько классов:

Рекомендуем скачать другие рефераты по теме: рефераты баллы, шпаргалки бесплатно.



Предыдущая страница реферата | 5  6  7  8  9  10  11  12  13  14  15 | Следующая страница реферата

Поделитесь этой записью или добавьте в закладки