В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 7. Коды аутентичности сообщений битового уровня безопасности мы бы рекомендовали использовать HMAC только с 256-битовой функцией хэширования, например SHA-256. Поскольку в HMAC уже учтены слабые места функции SHA-256, использовать SHA d -256 в данном случае необязательно. 7.5.1 HMAC или SHA d ? Как уже отмечалось, функция вычисления MAC, определенная как h ( K k m ) , хороша настолько, насколько хороша соответствующая функция хэширо- вания h . В качестве хорошей функции хэширования предлагалась SHA d -256. Тогда функцию вычисления MAC можно переписать следующим образом: ( K, m ) 7→ SHA − 256( SHA − 256( K k m )) . Между тем в предыдущем разделе мы рекомендовали воспользоваться ал- горитмом HMAC с функцией хэширования SHA-256. Это можно записать так: ( K, m ) 7→ SHA − 256(( K ⊕ a ) k SHA − 256(( K ⊕ b ) k m )) . Почему же мы рекомендуем использовать HMAC, если первая конструк- ция проще? Это хороший вопрос. Ответ на него достаточно тонок. Алгоритм HMAC был ориентирован на несколько иную модель затрат, требующихся для осу- ществления атаки. Предположим, пользователь А применяет функцию вы- числения MAC в целях аутентификации. Мы считаем только количество ша- гов, которые необходимо проделать злоумышленнику, и не учитываем разные тонкости наподобие того, требует ли каждый шаг взаимодействия с пользо- вателем А или нет. В отличие от нас, разработчики HMAC сочли выполнение автономных атак (т.е. не требующих взаимодействия с атакуемой системой) более простым, чем выполнение оперативных атак (т.е. основанных на взаи- модействии с атакуемой системой), и приняли особые меры, чтобы в первую очередь защитить свой алгоритм от автономных атак. Вот почему в HMAC и при втором хэшировании используется ключ аутентификации. Разработчики HMAC, безусловно, правы. Осуществлять автономные ата- ки намного легче, нежели оперативные. На наш взгляд, однако, это не оправ- дывает обеспечения различных уровней безопасности по отношению к авто- номным и оперативным атакам. Проблема состоит в том, что мы не хотим указывать некий фиксированный фактор затрат наподобие: “Каждый шаг оперативной атаки эквивалентен S шагам автономной атаки”. Мы не зна- ем, какое значение должно иметь S , особенно потому, что не представляем, как именно будет использоваться функция вычисления MAC. Таким образом, мы предпочитаем придерживаться общего 128-битового уровня безопасности. Только не воспринимайте это как критику разработчиков HMAC. Когда они 7.6. UMAC 125 разрабатывали свой алгоритм, большинство функций хэширования выдава- ли 128-битовые результаты. В то время автономная атака на основе коллизий требовала осуществить лишь 2 64 шагов — то, от чего определенно следовало защититься. Сейчас результаты функций хэширования имеют б´ольшие раз- меры, и подобные атаки для них несущественны. Так какой же из двух алгоритмов следует выбрать? Мы рекомендуем HMAC. Затрат на его реализацию требуется ненамного больше, чем на SHA d − 256( K k m ) , зато HMAC применяется уже довольно долго и удосто- ился более пристального внимания криптоаналитиков. Мы всегда пытаемся быть консервативными, а HMAC, безусловно, более консервативный выбор. 7.6 UMAC Семейство функций UMAC — хороший пример того, как использовать неопределенность в отношении K для получения функции вычисления MAC, намного более быстрой, чем функции хэширования 2 универсальной функции хэширования (universal hash function) . Это совсем не те функции хэширова- ния, о которых мы говорим в этой книге. Не путайте их. [8, 59]. Скорость работы алгоритма UMAC может на целый порядок превышать скорость ра- боты HMAC. Кроме того, для UMAC существуют доказательства его без- опасности. К сожалению, функции UMAC имеют несколько недостатков, которые не дают им право называться идеальными функциями вычисления MAC. 7.6.1 Размер значения Авторы алгоритма UMAC предлагают использовать 64-битовый резуль- тат, которого, на их взгляд, должно быть достаточно для большинства об- ластей применения. Это стандартная практика; и еще несколько лет назад мы бы порекомендовали то же самое. Причиной, по которой значение MAC может быть столь небольшим, состоит в том, что осуществить атаку путем полного перебора значений MAC в автономном режиме невозможно. Если злоумышленник попытается подобрать значение MAC, ему нужно вступить во взаимодействие с системой, чтобы проверить, правильно ли подобранное значение. Поскольку хорошая система не позволит злоумышленнику аутен- тифицировать так много сообщений, для обеспечения безопасности может хватить даже значения MAC небольшой длины. В последние годы, однако, мы изменили свою точку зрения и теперь счи- таем, что длины в 64 бит недостаточно. Безопасность MAC не должна зави- сеть от остальных частей системы. Как разработчики, мы не знаем, где будет 2 В документации UMAC слово “хэширование” применяется для определения |