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

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

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

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

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

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

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

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

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

Другие проблемы архитектуры

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

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

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

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

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

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

Изменение скорости выполнения в зависимости от длины ключа

Программное выполнение MARS, RC6 и Serpent не очень сильно изменяется в зависимости от длины ключа. Однако для Rijndael и Twofish установление ключа или шифрование/дешифрование заметно медленнее для 192-битных ключей, чем для 128-битных ключей и еще медленнее для 256-битных ключей.

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

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

Краткий вывод о скорости выполнения на основных программных платформах

Огромное количество информации собрано относительно скорости финалистов на различных программных платформах. Эти платформы включают 32-битные процессоры (реализации на С и Java), 64-битные процессоров (С и ассемблер), 8-битные процессоры (С и ассемблер), 32-битные смарт-карты (ARM) и цифровые сигнальные процессоры. В таблицах описано сравнение выполнения финалистов на различных платформах при использовании 128-битных ключей. Скорости финалистов сгруппированы следующим образом. Первая группа (I) обладает самой высокой скоростью выполнения, далее следуют вторая (II) и третья (III) группы.

В следующих оценках "низкое", "среднее" и "высокое" являются терминами, используемыми только в контексте этих пяти финалистов.

MARS обеспечивает среднее выполнение для шифрования, дешифрования и установления ключа.

RC6 обеспечивает от среднего до высокого выполнение для шифрования и дешифрования и среднее выполнение для установления ключа.

Rijndael обеспечивает последовательно высокое выполнение для шифрования, дешифрования и установления ключа, хотя выполнение и понижается для 192- и 256-битных ключей.

Serpent обеспечивает последовательно низкое выполнение для шифрования и дешифрования и платформно-зависимое выполнение для установления ключа.

Twofish обеспечивает платформно-зависимое выполнение для шифрования и дешифрования и последовательно низкое выполнение для установления ключа. В реализациях используется опция "Full Keying". Данная опция обеспечивает максимально быстрое шифрование с помощью выполнения большинства вычислений при установлении ключа. Выполнение шифрования/дешифрования или установления ключа понижается при увеличении размера ключа в зависимости от используемой опции ключа.

Изменение скорости в зависимости от режима

Другим фактором, который может влиять на выполнение алгоритма, является используемый режим операции. Алгоритм, выполняемый в режиме non-feedback (например, ЕСВ), может быть реализован для независимой и, следовательно, одновременной, обработки блоков данных. Результаты одновременного выполнения затем собираются для создания потока информации, который должен быть идентичен потоку, создаваемому при последовательной обработке. Считается, что реализации, использующие данный подход, применяют "interleaved режим". Это противоречит режимам с обратной связью (например, Cipher Feedback, Cipher Block Chaining и т.д.), которые должны обрабатывать блоки данных последовательно. Режимы interleaved имеют преимущества на процессорах с возможностью параллельного выполнения.

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

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

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

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

Замечания по финалистам

MARS имеет определенные сложности в силу гетерогенной структуры раунда (четыре различных типа раунда). Для S-boxes необходимо 2 Kbytes ROM, что не является проблемой, т.к. всегда доступен достаточный объем ROM.

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

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

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

RC6: шифрование в RC6 хорошо подходит для использования в смарт-картах. Как и в случае MARS переменные ротации могут эмулироваться умножениями по модулю.

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

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

Serpent: возможны два различных режима реализации Serpent: обычный и bit-sliced. Рассмотрим только обычную реализацию. Для таблиц требуется 2 Kbytes ROM, что не является проблемой.

Можно реализовать Serpent, используя 80 байт RAM и вычисляя подключи на лету.

Twofish: существует несколько возможных режимов реализации Twofish ; все они соответствуют окружениям с ограниченной памятью.