В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 7. Коды аутентичности сообщений горитм UMAC скорее напоминает бегового скакуна, чем рабочую лошадку. Он развивает хорошую скорость, но может пригодиться только в особых об- стоятельствах. 7.6.4 Нехватка анализа Еще одной проблемой алгоритма UMAC является недостаточный объем криптоанализа, которому была подвергнута его структура. Как уже отмеча- лось, существует доказательство безопасности UMAC, но оно не заменяет со- бой проведения анализа, исходя из позиций злоумышленника. Довольно мно- го систем, имевших доказанную безопасность, впоследствии были взломаны. К сожалению, подобный недостаток присущ всем новым алгоритмам, таким, как AES, SHA-256, или некоторым конструкциям, предлагаемым в данной книге. Среди них наибольшего внимания со стороны криптоаналитиков, по- жалуй, удостоился AES. (Мы это знаем, потому что сами принимали участие в его анализе.) Функция SHA-256 была разработана Управлением националь- ной безопасности США (NSA), предыдущие наработки которого были весьма неплохи. В NSA также работает большое количество экспертов. Некоторые из них, несомненно, анализировали функцию SHA-256 перед тем, как предоста- вить ее на суд широкой общественности. Новые конструкции, предложенные в этой книге, еще не были проанализированы другими экспертами на пред- мет возможности нападения. Тем не менее структура наших конструкций крайне консервативна, а многие из них, как минимум, не хуже стандарт- ных конструкций, используемых на протяжении многих лет. UMAC же име- ет весьма агрессивный дизайн, который напрямую зависит от доказательства безопасности. Давайте посмотрим на вещи с оптимистической точки зрения и предположим, что вероятность полноты и правильности доказательства безопасности алгоритма UMAC составляет 95%. Однако в 5% случаев можно предположить, что UMAC не имеет доказательства безопасности, и такого рода вероятность нас совершенно не привлекает. 7.6.5 Зачем тогда нужен UMAC? “Если нам не нравится UMAC, то зачем же так много о нем говорить?” — спросите вы. Вообще-то мы думаем, что разработчики UMAC двигались в правильном направлении. Идея использовать неопределенность относитель- но значения K для того, чтобы ускорить вычисление MAC, крайне ценна. Нам бы хотелось проделать еще ряд исследований в этой области. Где-то обязательно должна отыскаться функция вычисления MAC, которая будет более быстрой, чем функция хэширования, и вместе с тем такой же надежной и гибкой, как современные блочные шифры. 7.7. Какую функцию вычисления MAC выбрать 129 7.7 Какую функцию вычисления MAC выбрать Как вы, наверное, уже догадались, мы отдаем предпочтение комбинации HMAC-SHA-256, т.е. алгоритму HMAC, в котором в качестве функции хэ- ширования используется SHA-256. Мы бы действительно хотели, чтобы код аутентичности сообщения был 256-битовым. В большинстве систем, однако, используются лишь 64- или 96-битовые значения MAC, и даже тогда мно- гие жалуются на большие расходы. Добавление к каждому сообщению по 32 байт (256 бит) ни в коей мере не принесет популярности вашему проекту. Насколько мы знаем, для функции вычисления MAC не существует атак на основе коллизий, если использовать ее в классическом понимании, поэтому надеемся, что усечение результата алгоритма HMAC-SHA-256 до 128 бит не должно навредить безопасности системы. Еще раз подчеркнем, что применять в качестве функции хэширования HMAC функцию SHA d -256 нет смысла, так как в алгоритме HMAC уже учте- на проблема удлинения сообщения. Тем не менее для достижения 128-битово- го уровня безопасности в HMAC следует использовать 256-битовую функцию хэширования, поэтому SHA-1 нам не подходит. Нельзя сказать, что алгоритм HMAC полностью нас устраивает. Мы ве- рим в существование более быстрых функций вычисления MAC, но подходя- щих вариантов пока что не появилось. 7.8 Использование MAC Правильно использовать MAC намного сложнее, чем кажется. Давайте посмотрим, в чем же состоят основные проблемы. Когда пользователь Б получает значение MAC ( K, m ) , он знает, что кто- то, кому известен ключ K , подтвердил правильность сообщения m . Меж- ду тем это отнюдь не обеспечивает действительной корректности сообщения. Злоумышленник Е мог записать сообщение, отправленное пользователем А пользователю Б, и затем послать копию этого сообщения пользователю Б ко- гда-нибудь позднее. Если система последнего не имеет специальной защиты от такого типа атак, пользователь Б примет эту копию как корректное сооб- щение от пользователя А. Аналогичные проблемы возникают, если пользова- тели А и Б применяют один и тот же ключ K для аутентификации трафика сообщений в обоих направлениях. Злоумышленник Е может послать запи- санное им сообщение обратно пользователю A, и тот поверит, что сообщение было отправлено пользователем Б. Довольно часто пользователям А и Б нужно аутентифицировать не толь- ко сообщение m , но и некоторые дополнительные данные d . Это может быть |