Категории раздела |
|
Автомобильные гаджеты, ремонт...
[220]
|
Безопасность IT
[484]
|
Блоки питания, Power Banks, зарядки...
[490]
|
Видеорегистраторы
[220]
|
Гаджеты для спорта и здоровья...
[190]
|
Гаджеты, аксессуары...
[625]
|
Измерительная техника, инструменты
[449]
|
Накопители данных
[226]
|
Нетбуки, Ноутбуки, Ультрабуки
[680]
|
Мультиварки, блендеры и не только...
[158]
|
Планшеты
[758]
|
Радар-детекторы
[26]
|
Роботы-пылесосы
[37]
|
Своими руками
[357]
|
Сети, сетевые технологии, оборудование...
[269]
|
Смартфоны
[4966]
|
Фотокамеры, объективы, искусство фотографии..
[543]
|
Умный дом
[47]
|
Электронные книги
[96]
|
CB, LPD, PMR- связь...
[171]
|
DECT, IP-телефоны
[18]
|
Drones, boats, cars...
[108]
|
electric cars
[35]
|
GPS-навигаторы, трекеры...
[51]
|
Linux и не только
[4380]
|
mini computers и не только...
[409]
|
News IT, Это интересно, ликбез...
[1113]
|
Smart TV, UltraHD, приставки, проекторы...
[414]
|
Smart Watch
[263]
|
Sound: наушники, плееры, усилители...
[616]
|
Windows 10...
[298]
|
Windows 11
[28]
|
| |
|
|
| | |
| Главная » 2013 » Ноябрь » 12 » Сравнение производительности различных систем шифрования под linux
15:07 Сравнение производительности различных систем шифрования под linux |
Сравнение производительности различных систем шифрования под linux
В данной статье я попытаюсь сравнить производительность различных
систем шифрования под linux. В теории, конечно, известно, какая система
производительнее, и попытки посчитать производительность разных систем
были (например). Truecrypt
даже содержит встроенный бенчмарк (который показывает, однако,
производительность на RAM, его можно использовать разве что для оценки
скорости разных алгоритмов шифрования). Я же сделаю несколько другое —
измерю скорость файловой системы, зашифрованной разными средствами, в
процентном соотношении по сравнению с обычной нешифрованной файловой
системой.
Шифровать будем отдельный раздел на отдельном HDD, не содержащий
корневую файловую систему, алгоритмом, использующимся по-умолчанию в
каждом конкретном случае. Как обычный пользователь, я не разбираюсь в
нюансах стандартов шифрования (например, чем отличается хэширование
RIPEMD-160 от Whirpool, какой из этих режимов быстрее, какой
способствует более высокой защите), поэтому просто положимся на то, что
производители каждого программного продукта выбрали достаточно
криптостойкие параметры по-умолчанию. Может, это и не совсем корректно,
т. к. производительность различных алгоритмов шифрования неодинакова.
При желании, конечно можно сменить тип шифрования, но я не уверен, что
во всех тестируемых продуктах существует абсолютно идентичный набор
алгоритмов. Тестировать будем:
1) LUKS — нативная
система шифрования, в теории должна быть самой быстрой. Тома,
зашифрованные LUKS можно использовать в Windows через FreeOTFE.
2) Truecrypt — в
отличии от LUKS имеет, кроме консольного, и GUI-интерфейс, что делает
его на порядок удобнее в использовании. Мультиплатформенное ПО.
Обеспечение двух уровней правдоподобного отрицания наличия зашифрованных
данных, необходимого в случае вынужденного открытия пароля
пользователем. Тома Truecrypt не имеют заголовка, их нельзя отличить от
набора случайных данных. В теории медленнее, чем LUKS, т.к. использует FUSE.
3) eCryptfs —
система, по умолчанию предлагаемая пользователям Ubuntu для шифрования
домашних каталогов, поэтому и включена в данный тест. Работает поверх
уже существующей ФС. Шифрует каждый файл отдельно, поэтому всем видны
права, даты изменения, количество зашифрованных файлов; по-умолчанию
также видны имена файлов, хотя и существует опция для их шифрования.
Самое малофункциональное средство из представленных.
Итак, для тестов выделена отдельная машина довольно преклонного возраста
в следующей конфигурации: ЦП — Intel Celeron 2000Mhz, ОЗУ — 512 Mb DDR
PC2700, системный HDD — WD Caviar SE 5400 RPM 80Gb, тестовый HDD — WD
Caviar SE 7200 RPM 80Gb.
ОС — Ubuntu 12.04 LTS, версии всего ПО актуальные для репозиториев этой
ОС на момент написания статьи (Truecrypt 7.1a-linux-x86 не из
репозиториев).
Тестировать будем дефолтную для большинства дистрибутивов файловую
систему ext4. Для тестирования производительности будем использовать
утилиту iozone3 и написанный «на коленке» shell-скрипт для измерения процентной разницы в тестах.
Скрипт для подсчёта.
Особое внимание чистоте кода не уделялось, единственным критерием при
написании было наличие правильного результата.
Положимся на режим -a, в котором iozone должен произвести в
автоматическом режиме серию тестов, которые покрывают всевозможные
операции с файлами разных размеров и разной длиной записи (моя версия
произвела 1638 тестов).
В ходе эксперимента выяснилось, что одна серия тестов iozone может
отличаться от другой по производительности на 5%, поэтому я не буду
рассчитывать на результаты одного-единственного набора тестов и поступлю
таким образом: проведу набор тестов несколько раз и сгенерирую файл с
усредненными значениями по каждому из тестов (во всех расчётах данной
статьи под усредненными значениями понимается среднеарифметическое
значение). После этого я сравню усредненный файл, содержащий серию
тестов по незашифрованной файловой системе с аналогичным файлом,
содержащим серию тестов на зашифрованной ФС таким образом: каждый тест
первого файла будет сравнен с соответствующим тестом второго в
процентном соотношении, результаты сложим, а сумму разделим на
количество тестов, получив среднеарифметическое значение, на сколько
процентов первая группа тестов быстрее или медленнее второй.
Также, для простой оценки скорости, в дополнение к вышеописанным
вычислениям, проведем простенький тест — копирование средствами dd 500
мегабайт из urandom на зашифрованную ФС блоками, равными размеру
кластера ext4 по-умолчанию (4 килобайта). dd if=/dev/urandom of=testfile
bs=4k count=128000. Шифровать будет раздел целиком (за исключением
eCryptfs, которая этого делать не умеет). Я не буду приводить команды
для каждого конкретного случая, покажу только результаты.
Итак, приступим:
1) Система шифрования: нет
Количество проведенных серий тестов: 14
Средняя разница в производительности между одинаковыми сериями тестов: 1,3%
Результат dd: 524288000 bytes (524 MB) copied, 187.823 s, 2.8 MB/s
2) Система шифрования: LUKS. Используя ключи по-умолчанию, наш том будет зашифрован так:
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Количество проведенных серий тестов: 8
Средняя разница в производительности между одинаковыми сериями тестов: 1,4%
Результат dd: 524288000 bytes (524 MB) copied, 199.505 s, 2.6 MB/s
Падение производительности по сравнению с нешифрованной ФС: 7,9%
3) Система шифрования: Truecrypt. Применяя все параметры по-умолчанию,
том будет зашифрован AES с алгоритмом хеширования RIPEMD-160.
Количество проведенных серий тестов: 22
Средняя разница в производительности между одинаковыми сериями тестов: 3,2%
Результат dd: 524288000 bytes (524 MB) copied, 199.719 s, 2.6 MB/s
Падение производительности по сравнению с нешифрованной ФС: 7%
4) Система шифрования: eCryptfs
aes: blocksize = 16; keysize = 16
Количество проведенных серий тестов: 9
Средняя разница в производительности между одинаковыми сериями тестов: 0,9%
Результат dd: 524288000 bytes (524 MB) copied, 199.624 s, 2.6 MB/s
Падение производительности по сравнению с нешифрованной ФС: 49,5%
Итог: производительность eCryptfs по всевозможным файловым операциям
оставляет желать лучшего, хотя обычный тест dd с оптимальным размером
блока показывает скорость, аналогичную остальным системам шифрования.
Шифровать целиком ей домашнюю директорию я бы не стал. Удобно применять
лишь при шифровании отдельных поддиректорий. Ожидания меньшей
производительности Truecrypt из-за использования FUSE не оправдались, в
моём случае он оказался даже немного быстрее LUKS.
В дополнение, как бонус, приведу аналогичный тест dd для Truecrypt и
LUKS, но для file-hosted контейнера (все параметры шифрования
аналогичны).
1) LUKS
524288000 bytes (524 MB) copied, 207.07 s, 2.5 MB/s
2) Truecrypt
524288000 bytes (524 MB) copied, 205.046 s, 2.6 MB/s
Падение производительности можно объяснить тем, что появляются
дополнительные накладные расходы на чтение файла контейтера с уже
существующей файловой системы вместо прямого обращения к разделу.
http://habrahabr.ru/post/201694/
|
Категория: Linux и не только |
Просмотров: 639 |
Добавил: laptop
| Рейтинг: 0.0/0 |
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]
| |
| | |
|
Волк слабее льва и тигра, но в цирке волк не выступает!
Волк - единственный из зверей, который может пойти в бой на более сильного противника.
Если же он проиграл бой, то до последнего вздоха смотрит в глаза противника. После этого умирает...
Внимание! |
|
Администратор сайта laptop.ucoz.ru не несет ответственности за содержание рекламных объявлений. Все используемые на сайте зарегистрированные товарные знаки принадлежат своим законным владельцам! Используемая со сторонних источников информация публикуется с обязательными ссылками на эти источники.
| |
|
|