Алгоритм AES. Режимы выполнения алгоритмов симметричного шифрования. Создание случайных чисел

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

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

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

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

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

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

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

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

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

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

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

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

В результате было решено выбрать единственный алгоритм.

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

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

Итак, имея

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

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

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

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

Было принято решение не изменять количество раундов AES-алгоритма. Причины этого в следующем:

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

Безопасность AES

Безопасность является самым важным фактором при оценке алгоритмов. В отношении ни одного из алгоритмов никаких атак не выявлено.

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

Трудно оценить важность атак на варианты с уменьшенным числом раундов. С одной стороны, варианты с уменьшенным числом раундов на самом деле являются другими алгоритмами, и таким образом атаки на них никак не характеризуют безопасность исходных алгоритмов. Алгоритм может быть безопасен при n раундах, даже если он уязвим при n-1 раунде. С другой стороны, обычной практикой в современном криптоанализе являются попытки сконструировать атаки на варианты с уменьшенным числом раундов. С этой точки зрения вполне понятны попытки оценить "резерв безопасности" рассматриваемых алгоритмов, основываясь на атаках на варианты с уменьшенным числом раундов.

Одним из возможных критериев резерва безопасности является число, на которое полное число раундов алгоритма превышает наибольшее число раундов, при котором возможна атака. Существует ряд причин, объясняющих, почему не следует полагаться исключительно на подобную метрику для определения силы алгоритма; тем не менее, данная метрика резерва безопасности может быть полезна.

Программные реализации

Программные реализации алгоритмов могут быть выполнены в широ-ком диапазоне языков программирования и аппаратных архитектур. В не-которых случаях память никак не ограничена; в других случаях RAM и/или ROM могут быть существенно ограничены. Иногда большое количество данных шифруется и расшифровываются единственным ключом. В остальных случаях ключ изменяется часто, возможно, для каждого блока данных.

Скорость шифрования и/или расшифрования часто является противо-положностью безопасности. Это означает, что число раундов, указанное для алгоритма, является фактором безопасности; скорость шифрования или расшифрования приблизительно пропорциональна числу раундов. Таким образом, скорость не может исследоваться независимо от безопас-ности.

Существует много других аспектов программных реализаций. Некото-рые из них будут перечислены ниже, включая скорость и стоимость.

Размер машинного слова

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

Считается, что в ближайшие годы 8-битные, 32-битные и 64-битные архитектуры будут играть важнейшую роль (в какой-то момент будут добавлены 128-битные архитектуры). Хотя 8-битные архитектуры используются приложениями, которые имеют и 32-битные версии, 8-битные архитектуры не исчезнут окончательно. Между тем некоторые 32-битные архитектуры будут вытеснены 64-битными версиями, но 32-битные архитектуры будут использоваться приложениями с более низкими требованиями, т.е. важность 32-битных архитектур также останется высокой. Важность 64-битных архитектур будет возрастать. Таким образом, AES должен хорошо выполняться на различных архитектурах.

Следует заметить, что выполнение не может оцениваться только на ос-нове длины слова. Должны учитываться также дополнительные факторы, предоставляемые ПО, которые обсуждаются далее.

Языки реализации

Выполнение также зависит от использования конкретного языка (например, ассемблер, компилируемый или интерпретируемый язык высокого уровня). В некоторых случаях играет роль конкретное ПО. Существует целый спектр возможностей. Как одна из крайностей, вручную созданный ассемблерный код обеспечивает выполнение лучшее, чем даже оптимизирующий компилятор. Другая крайность - это интерпретируемые языки, которые в общем случае плохо решают задачи оптимизации. Оптимизация, выполняемая компиляторами, находится где-то посередине. Также следует заметить, что некоторые компиляторы работают лучше других, обеспечивая поддержку предоставляемых архитектурой операций, например, 32-битную ротацию. Это увеличивает трудность оценки выполнения на различных платформах.

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

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

Оптимизация имеет широкий диапазон решений. Иногда ее можно осуществить без особых усилий. Более того, некоторые оптимизации могут быть портированы на другие платформы. В качестве противоположного примера можно сказать, что ряд оптимизаций требует больших усилий и/или ограничений для конкретных платформ.

Окружения с ограничениями пространства

В некоторых окружениях, обладающих небольшими объемами RAM и/или ROM для таких целей, как хранение кода (обычно в ROM), представление объектов данных, таких как S-box (которые могут храниться в RAM или ROM в зависимости от того, известны ли они заранее или нет) и хранение подключей (в RAM), существуют значительные ограничения. Теоретически могут использоваться промежуточные формы хранения, например, EEPROM, для таких значений как подключи. Тем не менее, можно предполагать, что подключи также хранятся в RAM.

Кроме того, следует учесть, что доступная RAM должна использоваться для различных целей, таких как хранение промежуточных переменных при выполнении программы. Таким образом, не следует предполагать, что большие порции данного пространства доступны для хранения подключей.

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