Comments 33
Если процессор поддерживает AES, а PHP — нет, то, как вы сказали, зачем платить больше? Уж лучше использовать внешний модуль, а не зацикливаться на переносимости для шаред-хостингов и пр…
Процессор то AES поддерживает, но как и любые специальные инструкции, нужно чтобы еще библиотеки эти инструкции поддерживали (сами по себе они работать не будут). Чесно говоря при беглом гуглении, не нашел инфы поддерживает ли mcrypt эти самые AES-NI иснтрукции. Может объявится обладатель сервера на Sandy Bridge и протестит.
Вот результат на php 5.3.8 и Intel E5620 (с поддержкой AES-NI), FreeBSD 8.2:
[twofish] => 0.1602
[blowfish-compat] => 0.2426
[blowfish] => 0.2558
[cast-128] => 0.2601
[cast-256] => 0.2618
[rijndael-256] => 0.3423
[rijndael-192] => 0.3444
[rijndael-128] => 0.3556
[serpent] => 0.3737
[xtea] => 0.4823
[gost] => 0.4824
[rc2] => 0.55
[loki97] => 0.5947
[des] => 0.7901
[saferplus] => 1.1972
[tripledes] => 1.4796
[twofish] => 0.1602
[blowfish-compat] => 0.2426
[blowfish] => 0.2558
[cast-128] => 0.2601
[cast-256] => 0.2618
[rijndael-256] => 0.3423
[rijndael-192] => 0.3444
[rijndael-128] => 0.3556
[serpent] => 0.3737
[xtea] => 0.4823
[gost] => 0.4824
[rc2] => 0.55
[loki97] => 0.5947
[des] => 0.7901
[saferplus] => 1.1972
[tripledes] => 1.4796
По скорости сразу видно, поддерживает или нет
media1.servethehome.com/wp-content/uploads/2011/03/Intel-Xeon-E3-1280-TrueCrypt.png
и это еще не предел, на некоторых процах соотношение разницы в 1.5-2 раза больше
media1.servethehome.com/wp-content/uploads/2011/03/Intel-Xeon-E3-1280-TrueCrypt.png
и это еще не предел, на некоторых процах соотношение разницы в 1.5-2 раза больше
Ну то TrueCrypt, который более того в 8 потоков работает. Как бы никто и не сомневается, что эти инструкции ускоряют работу (иначе в них бы смысла не было). А вот в том, что mcrypt оптимизирован под эти инструкции я сильно сомневаюсь, учитывая, что libmcrypt 2.5.8 зарелизен в феврале 2007 года, а инструкции AES-NI представлены в марте 2008.
На первом графике по оси y, наверно, не скорость всё-таки, а обратная величина (если я правильно понял что 100% — самый быстрый)?
Там на обоих графиках 100% это самый быстрый, а все остальные это отставание от него в процентах.
Соответственно по оси y всё же не скорость, а время выполнения цикла шифрования.
Отставание на 1100%? Это как? Вместо шифрации со скоростью 100кБ/сек происходит дешифрация со скоростью 1МБ/сек? :)
Не совсем понял причем тут дешифрация? Её я не тестировал. Возможно стоит дополнить (просто меня именно шифрование больше интересовало, так как значительно чаще делается бэкап, чем восстановление из него). В данном случае значит, что алгоритм Twofish почти в 11 раз быстрее шифрует данные, чем TripleDES.
при все уважении к проделанной раоте я думаю, чт у вас проблемы с результатами её отображения — дае на самом житеском уровне большее знвчкение скорости означает, чтоскрипт должен быть быстрее. А как любое значение скорости может быть на 1100 процентов ментше «оригинала» вообе не понять
~31kb данных под тест — это несерьезно. Не пароли же или сериализованную сессию шифровать.
Попробуйте на нескольких мегабайтах.
Попробуйте на нескольких мегабайтах.
Да, еще для сравнения можно взять результаты по openssl:
$ time openssl aes-128-ecb ./my-test-file
На серверах с FreeBSD openssl md5 на больших файлах (гигабайты), запущенный через банальный exec, работает в разы, если не порядки быстрее реализаций в самом php.
$ time openssl aes-128-ecb ./my-test-file
На серверах с FreeBSD openssl md5 на больших файлах (гигабайты), запущенный через банальный exec, работает в разы, если не порядки быстрее реализаций в самом php.
А в чем несерьезность, это блочные шифры, шифруют блоками по 128 бит. Да и я написал что скрипт немного упрощенный, далеко не у всех в конфиге выставлено 256 МБ для выполнения скриптами. Также я тестил на файлах по 700 МБайт, результаты аналогичные.
Время непосредственной работы алгоритма может быть сопоставима с оверхедом на вызов.
На большом объеме данных, это влияние нивелируется.
Если бы в скрипте сразу было Nмб — я бы ничего не сказал.
На большом объеме данных, это влияние нивелируется.
Если бы в скрипте сразу было Nмб — я бы ничего не сказал.
Я тестил набором данных 32 и 64 МБ, тупо файл загружался в память и потом вскармливался алгоритму. Также тестил шифрование при чтении небольшими файла частями около 60КБ, с большими строками уже сам PHP начинал тупить. Но поскольку результаты особо не отличались выложил упрощенную версию. Но в ней легко можно увеличить объем данных.
>> Во всех этих алгоритмах пока не найдены уязвимости.
Я с вами не согласен. Вот подтверждение того, что AES теоретически был взломан (повторяю, ТЕОРЕТИЧЕСКИ).
Я с вами не согласен. Вот подтверждение того, что AES теоретически был взломан (повторяю, ТЕОРЕТИЧЕСКИ).
Ну так теоретически. И это в том случае, если теоретик не допустил ошибку в своей теории. На практике если же Пентагон доверяет AES'у свои файлы, то думаю и свои бэкапы мы можем доверить. Тем более что, спокойно можно выбрать шифрование с ключом 256 бит, он всё равно быстрее, чем на 128 или 192.
Привожу цитату из статьи:
«We thank Joan Daemen and Vincent Rijmen for their helpful feedback.»
Это разработчики Rijndael, который был прототипом AES. Они прочитали и сказали, что атака действительно работает.
>>> Пентагон доверяет AES'у свои файлы, то думаю и свои бэкапы мы можем доверить.
Во всех документах пишется, что рекомендуется использовать, но это не говорит, что они это делают. Плюс есть ещё такое ведомство как NSA. Вот оно-то и даёт вердикт (я так думаю) о том можно ли его использовать или нет. И как не странно у них свои алгоритмы, отличные от общепринятых.
«We thank Joan Daemen and Vincent Rijmen for their helpful feedback.»
Это разработчики Rijndael, который был прототипом AES. Они прочитали и сказали, что атака действительно работает.
>>> Пентагон доверяет AES'у свои файлы, то думаю и свои бэкапы мы можем доверить.
Во всех документах пишется, что рекомендуется использовать, но это не говорит, что они это делают. Плюс есть ещё такое ведомство как NSA. Вот оно-то и даёт вердикт (я так думаю) о том можно ли его использовать или нет. И как не странно у них свои алгоритмы, отличные от общепринятых.
Ещё не согласен с другой составляющей названий графиков. Это не скорости (а как становится ясно всё же обратная величина) алгоритмов, а скорости (см. предыдущее замечанеи) просто шифрования. Покрайней мере это применимо к последнему графику.
Почти у всех шифров есть фаза предварительной обработки ключа (scheduling) — она исполняется один раз при установке (замене) ключа, а при шифровании каждого нового блока не производится. У некоторых шифров scheduling медленнее основного цикла в сотни раз.
Попробуйте сделать следующий разрез: шифрование 16 байт, 200.000 байт, 2.000.000 байт.
И картинки будут серьезно меняться.
Попробуйте сделать следующий разрез: шифрование 16 байт, 200.000 байт, 2.000.000 байт.
И картинки будут серьезно меняться.
$ openssl speed
При чём тут казалось бы PHP…
Ну как бы все тесты проводятся применительно к библиотеке mcrypt встроенной в PHP. Сами тестовые файлы на PHP. Так как в данном случае для меня лично важна была практическая скорость с которой сможет работать скрипт, а не теоретические рассуждения о скорости алгоритмов шифрования. Вполне возможно, что во всех других языках использующих mcrypt соотношения будут похожи, но без соответствующего тестирования я это утверждать не могу.
Ну при том что бенчмарк в TrueCrypt выдаёт другой результат где AES быстрее чем Twofish.
Sign up to leave a comment.
Тестирование скорости алгоритмов шифрования в PHP