Практический выбор алгоритма шифрования

именно на разделе, как раз был пустой, просто указав в скрипте BLOCKDEV=/dev/sda4 .
Так как все таки правильно провести эксперимент ?

Подозреваю, что гиг на запись вполне себе способен кэшироваться при современных размерах памяти.

Там в скрипте сделан сброс кэша. Единственное, было бы правильно sleep небольшой после этого поставить, операция-то вроде несинхронная.

Вообще, соотношение скоростей чтения/записи от теста к тесту гуляет довольно сильно, а после сброса кэша можно увидеть повышенный iowait. Неужто проклятый 12309? По хорошему надо поприбивать все сколько-нибудь активно читающие/пишущие процессы на время теста.

sentaus

было бы правильно sleep небольшой после этого поставить

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

соотношение скоростей чтения/записи от теста к тесту гуляет довольно сильно

У меня от теста к тесту плавала только скорость записи, чтение шло почти стабильно.

надо поприбивать все сколько-нибудь активно читающие/пишущие процессы на время теста

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

1)Добавьте sleep 5 после строчки "echo 3 >/proc/sys/vm/drop_caches":
echo 3 >/proc/sys/vm/drop_caches sleep 5

2) Отключите swap совсем
swapoff -a

3) иксы для теста тоже лучше бы потушить, хоть и xfce не страдает прожорливостью

sentaus
выполнил все три пункта, вот результаты:
1-го прогона
Options Write Read -c aes-cbc-essiv:sha256 -s 128 77.11 57.37 -c aes-cbc-essiv:sha256 -s 192 78.71 52.89 -c aes-cbc-essiv:sha256 -s 256 81.99 53.08 -c twofish-cbc-essiv:sha256 -s 256 79.38 65.14 -c blowfish-cbc-essiv:sha256 -s 256 78.35 78.47
3-го прогона
Options Write Read -c aes-cbc-essiv:sha256 -s 128 78.83 57.76 -c aes-cbc-essiv:sha256 -s 192 74.42 53.53 -c aes-cbc-essiv:sha256 -s 256 77.63 53.33 -c twofish-cbc-essiv:sha256 -s 256 74.04 64.73 -c blowfish-cbc-essiv:sha256 -s 256 79.63 87.60

еще могу признаться что при установке для пробы зашифровал корневой раздел в блоуфиш, просто экспериментировал, но это другой раздел – sda5. Также имеются временные фс (я их не делал):
tmpfs 566M 688K 566M 1% /run tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 1,2G 8,0K 1,2G 1% /tmp tmpfs 1,2G 0 1,2G 0% /run/shm
Какие есть еще предложения ?

Немного поиграл со скриптом на тему размера записываемого файла на диск, по умолчанию 1Гб, ставил 2,4 и 8 Гб — результаты теже, затем поменял размер блока был 1Мб, ставил 512Кб и 256Кб — картина таже, без изменений, blowfish рвет всех как тузик грелку. Что скажите ?
Какие есть недостатки у блоуфиш? длины ключа 256 хватит или надо больше ? (кстати пробовал задать в параметрах теста 448, скорость так и не просела ..)

Сам по себе этой стойкий шифр. Но по размеру блока он относится к 64-битным шифрам, что нехорошо при шифровании разделов большого размера.
Кое-что упоминалось здесь, и здесь вторая часть ответа в коментарии.

Наконец, новые, улучшенные режимы XTS-PLAIN и XTS-BENBI гарантированно правильно работают только с AES. С другими шифрами они работать тоже будут, но нет никакой гарантии, что когда-нибудь после обновления вы сможете расшифровать данные на новой системе или что их реализация проверялась с другими шифрами (будет выдано сообщение, что тестовый вектор для такого сочетания шифра и режима неизвестен). Поэтому, в принципе XTS-PLAIN и XTS-BENBI использовать не рекомендуется пока они не устоялись (из них XTS-PLAIN уже устарел) или только для временных данных (шифрованный своп). CBC-ESSIV будет работать со всеми шифрами и это устоявшийся режим, его уязвимости некритичны.

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

Мда, тогда из них остается туфиш.
Ну неужели нет чего нибудь по быстрее (и совместимого с luks)?

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

На Intel Core i5 660 скорость шифрования данных для AES составляет 3261 Мб/с против 283 Мб/с у TrueCrypt. Вероятно, столь большая разница при использовании AES достигается за счет использования инструкций AES-NI. Для сравнения — разница при использовании алгоритмов Twofish и Serpent не столь значительна ☭

Вот оно.