Симметричное шифрование: вопросы производительности - PullRequest
2 голосов
/ 04 апреля 2010

Зависит ли производительность алгоритма симметричного шифрования от объема зашифрованных данных? Предположим, у меня есть около 1000 байтов, которые мне нужно быстро отправить по сети, лучше ли шифровать 50 байтов данных 20 раз или 1000 байтов одновременно? Который будет быстрее? Зависит ли это от используемого алгоритма? Если да, то какой алгоритм работы с наибольшей эффективностью и безопаснее всего для объемов данных до 512 байт?

Ответы [ 4 ]

5 голосов
/ 06 апреля 2010

Краткие ответы:

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

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

  • В случае сомнений используйте готовый протокол, такой как SSL / TLS . Если предоставляется выбор алгоритма шифрования в протоколе, используйте AES.

Теперь более длинные ответы:

Есть блочные шифры и потоковый шифр . Потоковый шифр начинается с фазы инициализации, на которой ключ вводится в систему (часто это называется «расписанием ключей»), а затем шифрует байты данных «на лету». При использовании потокового шифра зашифрованное сообщение имеет ту же длину, что и входное сообщение, а время шифрования пропорционально длине входного сообщения, за исключением вычислительной стоимости расписания ключей. Мы не говорим здесь большие цифры; время основного расписания меньше 1 мкс на не очень новом ПК. Тем не менее, для оптимальной производительности вы хотите составить расписание по расписанию один раз, а не 50.

Блочные шифры также имеют ключевое расписание. Когда расписание ключей выполнено, блочный шифр может шифровать блоки, то есть фрагменты данных фиксированной длины. Длина блока зависит от алгоритма, но обычно составляет 8 или 16 байтов. AES является блочным шифром. Чтобы зашифровать «сообщение» произвольной длины, блочный шифр должен быть вызван несколько раз, и это сложнее, чем кажется (есть много проблем безопасности). Часть, которая решает, как эти вызовы собираются вместе, называется режимом цепочки . Хорошо известный режим цепочки называется CBC. В зависимости от режима формирования цепочки может потребоваться дополнительный шаг, называемый padding , при котором к входному сообщению добавляется несколько дополнительных байтов, чтобы его длина стала совместимой с выбранной цепочкой. Заполнение должно быть таким, чтобы при дешифровании его можно было удалить однозначно. Общая схема заполнения называется "PKCS # 5".

Существует режим цепочки, называемый "CTR", который эффективно превращает блочный шифр в потоковый шифр. У него есть несколько хороших моментов; особенно, режим CTR не требует заполнения, и длина зашифрованного сообщения будет иметь ту же длину, что и входное сообщение. AES с CTR режимом хорош. Скорость шифрования составит около 100 МБ / с на обычном ПК (например, Intel Core2 с частотой 2,4 ГГц и одноядерным процессором).

Предупреждение: существуют проблемы с шифрованием нескольких сообщений с одним и тем же ключом. В режимах цепочки эти проблемы скрываются под именем «IV» (как «начальное значение»). В большинстве режимов цепочки IV является случайным значением того же размера блока шифра. IV не должен быть секретным (он часто передается вместе с зашифрованным сообщением, потому что дешифровщик должен также знать его), но он должен выбираться случайно и равномерно, и каждому сообщению требуется новый IV. Некоторые режимы цепочки (например, CTR) могут допускать неоднородный IV, но только для первого сообщения с данным ключом. С CBC даже первое сообщение нуждается в полностью случайном IV. Если этот абзац не имеет для вас полного смысла, тогда, , пожалуйста , не пытайтесь разработать протокол шифрования, он более сложный, чем вы себе представляете. Вместо этого используйте уже указанный протокол, такой как SSL (для туннеля шифрования) или CMS (для зашифрованных сообщений). Разработка таких протоколов была долгой и мучительной историей нападений и контрмер, с большим количеством зубов. Не воспроизводите эту историю ...

Предупреждение 2: если вы используете шифрование, то вы беспокоитесь о безопасности: могут быть недобросовестные объекты, склонные к атаке на вашу систему. В большинстве случаев простое шифрование не будет полностью их сдерживать; само по себе (при правильном применении) шифрование побеждает только пассивных атакующих , тех, кто наблюдает за переданными байтами, но не изменяет их. Обычный злоумышленник также активен , т. Е. Он удаляет некоторые байты данных, перемещает и дублирует другие или добавляет дополнительные байты своей собственной разработки. Чтобы победить активных злоумышленников, вам нужно не только шифрование, но и проверки целостности. И снова такие протоколы, как SSL и CMS, уже заботятся о деталях.

3 голосов
/ 04 апреля 2010

AES должен быть хорошим выбором.

Хорошая реализация AES (например, включенная в библиотеку openssl) требует около 10-20 циклов ЦП на байт для шифрования. Когда вы шифруете небольшие сообщения, вы также должны учитывать время для установки ключа. Например, типичная реализация DES требует нескольких тысяч циклов для настройки ключа. То есть вы могли бы на самом деле закончить шифрование небольшого сообщения с помощью AES, прежде чем даже начать шифрование с помощью других шифров.

Более новые процессоры (например, процессоры на базе Westmere) имеют набор команд, который поддерживает AES, позволяя шифровать со скоростью 1,5-4 цикла на байт. Это почти невозможно победить любым другим шифром.

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

1 голос
/ 04 апреля 2010

Симметричные алгоритмы шифрования обычно являются блочными шифрами. Для любого данного алгоритма размер блока является фиксированным. Затем вы выбираете из нескольких различных способов сделать последующие блоки зависимыми от более ранних блоков (то есть цепочку блоков шифра), чтобы создать потоковый шифр. Но потоковый шифр неизменно кэширует входящие данные и передает их блочному шифру в полных блоках.

Таким образом, выполняя 50 байтов 20 раз, все, что вы делаете, это стучите в логику кеша.

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

0 голосов
/ 04 апреля 2010

Очевидно, что производительность зависит от объема данных, поскольку каждая часть данных должна быть зашифрована. Вы получите намного лучшую информацию, выполнив тест в вашей конкретной среде (язык, платформа, реализация алгоритма шифрования), чем кто-либо здесь мог бы представить неожиданно: я не думаю, что установка займет больше получаса базовое измерение производительности.

Что касается безопасности, у вас должно быть все в порядке с Triple DES или AES .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...