Алгоритмы симметричного шифрования. Часть 3. Разработка Advanced Encryption Standard (AES)

Методология и результаты выбора

Принципы выбора алгоритма

Команда NIST до выбора алгоритма должна была принять несколько фундаментальных решений:

• Принять количественный или качественный критерий при выборе алгоритма.
• Выбрать один или несколько алгоритмов в качестве AES.
• Выбрать запасной алгоритм(ы).
• Рассмотреть предложения по модификации алгоритмов.

Кратко рассмотрим полученные результаты.

Качественный или количественный критерий

На одной из первых встреч по планированию второго этапа обсуждений была рассмотрена возможность количественного подхода, используя который каждый алгоритм или комбинация алгоритмов будет получать определенное количество очков, основываясь на критерии оценки. Как при осуществлении такого подхода определить конкретные значения и обеспечить сравнение алгоритмов? Количественный подход также обеспечивает явные веса для каждого выбранного фактора AES. Тем не менее, было достигнуто соглашение, что степень субъективности в критерии приведет к большому количеству дискуссий. Было также высказано предположение, что определение количественной системы счетчиков невозможно без широкого обсуждения того, что такая система является объективной. Поэтому был сделан вывод, что количественный подход неприменим, и было решено рассмотреть его после первого этапа обсуждений. То есть было решено рассмотреть безопасность алгоритма, выполнение, реализацию и остальные характеристики и принять решение, основываясь на качественной оценке каждого алгоритма - помня, что обсуждение безопасности является самым главным.

Количество алгоритмов AES

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

Некоторые аргументы, выдвинутые в защиту нескольких алгоритмов (против единственного алгоритма), включают:

• В интересах безопасности; на случай, если один алгоритм AES будет взломан, в продуктах должно быть реализовано более одного AES-алгоритма. Некоторые считают, что широкое применение единственного алгоритма является рискованным, если данный алгоритм проявит себя как небезопасный.
• Понятия интеллектуальной собственности могут быть рассмотрены позднее в вопросе отсутствия лицензионных ограничений для конкретного алгоритма. Альтернативный алгоритм может предоставлять промежуточный вариант, который не влияет на рассмотренное понятие интеллектуальной собственности.
• Множество алгоритмов AES может охватывать более широкий диапазон характеристик, чем единственный алгоритм. В частности, можно будет предложить как большую степень безопасности, так и большую степень эффективности, что не всегда возможно при использовании единственного алгоритма.

Были также высказаны мнения в пользу единственного алгоритма (и/или против нескольких алгоритмов). Некоторые из этих аргументов таковы:

• Использование нескольких AES-алгоритмов уменьшает интероперабельность и увеличивает стоимость продукта.
• Несколько алгоритмов могут представлять собой определенное число "атак на интеллектуальную собственность", направленных против реализаций.
• Описание нескольких алгоритмов может вызвать обсуждение вопросов безопасности любого из алгоритмов.
• Аппаратные реализации могут лучше использовать доступные ресурсы, оптимизируя выполнение единственного алгоритма, а не нескольких алгоритмов.

Во время второго этапа обсуждались эти и другие проблемы, касающиеся единственного или нескольких алгоритмов AES. Как выяснилось, существует вероятность, доказываемая коммерческими продуктами сегодня, что скоро продукты будут реализовывать несколько алгоритмов, которые определяются нуждами потребителей, требованиями интероперабельности с наследуемыми или собственными системами и так далее. Тройной DES, который NIST предлагает сделать в обозримом будущем соответствующим FIPS-алгоритмом, доступен во многих коммерческих продуктах, как и другие FIPS и не-FIPS алгоритмы. Следовательно, считается, что наличие этих нескольких алгоритмов в конкретном продукте обеспечивает большую степень надежности, как и наличие нескольких длин ключей в AES. В случае атаки на выбранный алгоритм NIST предлагает задействовать соответствующие исследованные опции, которые включают использование других финалистов AES, у которых отсутствуют подобные атаки, либо в случае необходимости определить полностью новые подходы.

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

На конференции AES3 состоялась дискуссия по поводу количества алгоритмов, которые должны быть включены в AES. Большинство присутствующих выразили поддержку выбора единственного алгоритма. Некоторые поддержали и выбор запасного алгоритма, но не было согласовано, как это должно быть выполнено. Указанное выше мнение было отражено в письменных комментариях, представленных в NIST многими из присутствующих на конференции.

Перед тем как принять решение в пользу единственного алгоритма AES, были рассмотрены все комментарии и аргументы. Остальные соответствующие FIPS алгоритмы будут обеспечивать определенную степень надежности, единственный же AES-алгоритм обеспечивает интероперабельность, способствует решению проблем интеллектуальной собственности.

Запасной алгоритм

Как уже отмечалось, существует взаимосвязь между обсуждениями проблемы нескольких алгоритмов AES и выбором запасного алгоритма, особенно в случае единственного алгоритма AES. Backup может иметь несколько форм, от алгоритма, который требуется реализовывать в продуктах AES ("cold backup"), до определяемого в AES запасного алгоритма ("hot backup"). Было доказано, что запасной алгоритм во многом эквивалентен второму AES-алгоритму, так как многие пользователи пожелают, чтобы даже "cold backup" был реализован в продуктах.

Итак, имея

• представления о том, что запасной алгоритм должен de facto требоваться в продуктах;
• сомнения относительно потенциальной применимости в связи с возможными достижениями криптоанализа;
• заинтересованность NIST в обеспечении интероперабельности;
• доступность в коммерческих продуктах других алгоритмов (как FIPS, так и не-FIPS);

было принято решение не выбирать запасной алгоритм.

Как и в случае с другими стандартами на криптографические алгоритмы, NIST продолжит исследования в области криптоанализа AES-алгоритма, и стандарт будет пересматриваться каждые пять лет. Если полученные результаты потребуют более быстрой реакции, NIST будет действовать соответствующим образом и рассмотрит все возможные альтернативы.

Модификация алгоритмов

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

При обсуждении были отмечены следующие результаты и введены понятия:

• Для некоторых алгоритмов неясно, каково полное определение алгоритма (например, управление ключом) при различном количестве раундов и как такое изменение влияет на анализ безопасности.
• Изменение количества раундов влияет на анализ выполнения. Все полученные данные для модифицированного алгоритма необходимо либо оценить, либо получить заново. В некоторых случаях, особенно при аппаратной реализации и в окружениях с ограниченной памятью, оценка алгоритма с новым количеством раундов должна производиться особенно тщательно.
• Должно быть достаточное количество аргументов для добавления числа раундов и соответствующего изменения алгоритма.

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