В чем разница производительности симметричного шифрования от pki? - PullRequest
12 голосов
/ 23 сентября 2008

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

Мне кажется, я знаю, что PKI намного медленнее и сложнее, чем симметричное шифрование, но я не могу найти цифры, подтверждающие мои чувства.

Ответы [ 6 ]

26 голосов
/ 23 сентября 2008

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

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

23 голосов
/ 24 сентября 2008

На Macbook с OS X 10.5.5 и стандартной сборкой OpenSSL "openssl speed" тактирует AES-128-CBC со скоростью 46 000 1024 битных блоков в секунду. Та же самая коробка синхронизирует 1024-битный RSA со скоростью 169 подписей в секунду. AES-128-CBC - это алгоритм блочного шифрования «учебник», а RSA 1024 - алгоритм открытого ключа «учебник». Это яблоки с апельсинами, но ответ таков: RSA намного, намного медленнее .

Однако не следует использовать шифрование с открытым ключом. Вот реальные причины:

  1. Криптооперации с открытым ключом не предназначены для шифрования необработанных данных . Такие алгоритмы, как Диффи-Хеллман и RSA, были разработаны как способ обмена ключами для блочных криптоалгоритмов. Так, например, вы должны использовать безопасный генератор случайных чисел для генерации 128-битного случайного ключа для AES и шифровать эти 16 байтов с помощью RSA.

  2. Алгоритмы, такие как RSA, намного менее "удобны для пользователя", чем AES . При случайном ключе блок открытого текста, который вы передаете AES, будет случайным образом отдан любому, у кого нет ключа. Это на самом деле не так с RSA, который - в большей степени, чем AES - просто математическое уравнение. Таким образом, помимо правильного хранения ключей и управления ими, вы должны быть предельно осторожны при форматировании блоков открытого текста RSA, иначе вы столкнетесь с уязвимостями.

  3. Открытый ключ не работает без инфраструктуры управления ключами . Если у вас нет схемы проверки открытых ключей, злоумышленники могут заменить свои собственные пары ключей настоящими для запуска атак «человек посередине». Вот почему SSL заставляет вас проходить через множество сертификатов. Блочные криптоалгоритмы, такие как AES do , тоже страдают от этой проблемы, но без PKI AES не менее безопасен, чем RSA.

  4. Крипто-операции с открытым ключом подвержены большему количеству уязвимостей реализации, чем AES . Например, обе стороны транзакции RSA должны согласовать параметры , которые являются числами, поданными в уравнение RSA. Есть злые значения, которые злоумышленники могут заменить, чтобы отключить шифрование. То же самое относится и к Диффи-Хеллману, и даже к Эллиптической кривой. Другим примером является уязвимость RSA Signature Forgery, возникшая 2 года назад в нескольких реализациях SSL высокого класса.

  5. Использование открытого ключа является доказательством того, что вы делаете что-то «необычное» . Необычное - это именно то, что вы никогда не хотите использовать в криптографии; Помимо алгоритмов, крипто designs проверяются и проверяются годами, прежде чем они считаются безопасными.

Для наших клиентов, которые хотят использовать криптографию в своих приложениях, мы даем две рекомендации:

  • Для «данных в покое» используйте PGP . В самом деле! PGP был избит более десяти лет назад и считается безопасным от глупых ошибок в реализации. Существуют открытые и коммерческие варианты.

  • Для «данных в полете» используйте TLS / SSL . Ни один протокол безопасности в мире не может быть лучше понят и протестирован, чем протокол TLS; финансовые учреждения повсеместно принимают это как безопасный способ переместить самые важные данные.

Вот достойная статья [matasano.com] я и Нейт Лоусон, профессиональный криптограф, написали несколько лет назад. Он охватывает эти моменты более подробно.

7 голосов
/ 23 сентября 2008

Используйте команду OpenSSL speed для сравнения алгоритмов и убедитесь сами.

[dave@hal9000 ~]$ openssl speed aes-128-cbc
Doing aes-128 cbc for 3s on 16 size blocks: 26126940 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 7160075 aes-128 cbc's in 3.00s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc     139343.68k   152748.27k   155215.70k   155745.61k   157196.29k


[dave@hal9000 ~]$ openssl speed rsa2048
Doing 2048 bit private rsa's for 10s: 9267 2048 bit private RSA's in 9.99s
Doing 2048 bit public rsa's for 10s: 299665 2048 bit public RSA's in 9.99s
...
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.001078s 0.000033s    927.6  29996.5
4 голосов
/ 23 сентября 2008

Практические системы шифрования на основе PKI используют асимметричное шифрование для шифрования симметричного ключа, а затем симметричное шифрование с этим ключом для шифрования данных (сказав, что кто-то укажет контрпример).

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

В прошлый раз, когда я проверял это, проверял цепочку из 3 или около того сертификатов X.509 [править, чтобы добавить: и данные, которые они подписывали] занимал долю секунды на ARM, работающем на частоте 100 МГц или около того (усредненное по много повторений, очевидно). Я не могу вспомнить, как маленький - ничтожно мал, но намного меньше секунды.

Извините, я не могу вспомнить точные детали, но вкратце это так, если только вы не находитесь в очень ограниченной системе или не используете много шифрования (например, если вы хотите принимать как можно больше соединений SSL в секунду), Одобренные NIST методы асимметричного шифрования быстрые.

2 голосов
/ 23 сентября 2008

Видимо, это в 1000 раз хуже. (http://windowsitpro.com/article/articleid/93787/symmetric-vs-asymmetric-ciphers.html). Но если вы действительно не работаете с большим количеством данных, это не имеет значения. Что вы можете сделать, это использовать асимметричное шифрование для обмена симметричным ключом шифрования.

0 голосов
/ 23 сентября 2008

Возможно, вы сможете добавить некоторые подробности о вашем проекте, чтобы получить более качественные ответы. Что вы пытаетесь обезопасить? От кого? Если бы вы могли объяснить требования вашей безопасности, вы получите гораздо лучший ответ. Производительность мало что значит, если механизм шифрования не защищает то, о чем вы думаете.

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

Спасибо.

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