Core i3 неподдерживает инструкции AES-NI (который в стабильном Debian, впрочем, временно выкинули), так что почти без разницы. Если всё-таки выжимать максимум по скорости, лучше всё-равно выбрать AES, Twofish будет сравним. X-64 должно быть лучше, но не сказать насколько. Blowfish — это 64-битный шифр по размеру блока, его использование для шифрования современных больших дисков и с современными режимами дискового шифрования нежелательно (некритично конечно, но устарелое решение).

есть в штатах такое понятие как ограничение технологий на экспорт,

А тот факт, что сей алгоритм разработан в Бельгии, шаблон не сильно рвёт? :)

http://blog.wpkg.org/2009/04/2.....k-for-dm-crypt-luks/^[link7]
+все комменты к тому блогпосту гляньте.

The benchmarks were made with dd (bs=64k, 3 GB read), repeated several times; caches were dropped before each test.

unknown
решил все таки проверить сам, использовал скрипт Heikki Salokanto из блогпоста что ты дал. Debian testing x64, ядро 3.2. Вот что получилось:
1. На RAM диске:
Options Write Read -c aes-xts-plain -s 256 199.22 121.47 -c aes-cbc-essiv:sha256 -s 128 160.00 123.37 -c aes-xts-plain -s 384 167.59 107.23 -c aes-cbc-essiv:sha256 -s 192 139.32 105.79 -c aes-xts-plain -s 512 134.03 92.92 -c aes-cbc-essiv:sha256 -s 256 134.56 92.92 Options Write Read -c aes-cbc-essiv:sha256 -s 128 138.38 123.23 -c aes-cbc-essiv:sha256 -s 192 138.38 105.68 -c aes-cbc-essiv:sha256 -s 256 127.36 93.26 -c twofish-cbc-essiv:sha256 -s 256 203.58 142.42 -c blowfish-cbc-essiv:sha256 -s 256 149.27 186.52
2. На реальном разделе hdd:
Options Write Read -c aes-xts-plain -s 256 78.89 57.72 -c aes-cbc-essiv:sha256 -s 128 80.25 57.27 -c aes-xts-plain -s 384 77.40 55.65 -c aes-cbc-essiv:sha256 -s 192 80.06 53.81 -c aes-xts-plain -s 512 80.13 53.31 -c aes-cbc-essiv:sha256 -s 256 74.10 53.06 Options Write Read -c aes-cbc-essiv:sha256 -s 128 75.07 56.20 -c aes-cbc-essiv:sha256 -s 192 79.56 54.07 -c aes-cbc-essiv:sha256 -s 256 80.69 53.58 -c twofish-cbc-essiv:sha256 -s 256 80.13 65.02 -c blowfish-cbc-essiv:sha256 -s 256 80.00 88.81
делал по 3 прохода, цифры записи немного различались, чтение почти стабильно. Как интерпретировать полученные результаты ?
Почему скорость записи намного больше скорости чтения ?
Почему на hdd все так сильно просело и старый добрый blowfish всех порвал? Может скрипт работает криво или я что делал не так ?

Почему скорость записи намного больше скорости чтения ?

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

Почему на hdd все так сильно просело

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

#!/bin/bash ## This script benchmarks write and read performance of given block ciphers. ## Edit the list of 'cryptsetup' options at the end of this file. ## ## Results are written in MiB/s (2^20 bytes per second) in a CSV file and stdout. ## ## You must have a writable block device of at least 1.05 GiB of size. ## WARNING: The contents of the block device will be overwritten. ## ## You can create a temporary loopback device on a ram-disk as follows: ## mkdir /mnt/ramdisk ## mount -t tmpfs none /mnt/ramdisk -o size=1200m ## dd if=/dev/zero of=bigsecret bs=1048576 count=1024 ## losetup /dev/loop0 bigsecret ## ## A key must be put in $KEYFILE. It can be anything. ## ## Author: Heikki Salokanto <heikki.salokanto@gmail.com> OUT=/tmp/results.csv KEYFILE=/tmp/keyfile BLOCKDEV=/dev/loop0 if [ $UID != 0 ]; then echo "Must be root"; exit 1; fi printf "%-35s%9s%9s\n" "Options" "Write" "Read" | tee $OUT cd /mnt [ -d cr ] || mkdir cr while read opts; do printf "%-35s" "$opts" | tee -a $OUT cryptsetup -q $opts luksFormat $BLOCKDEV $KEYFILE cryptsetup --key-file $KEYFILE luksOpen $BLOCKDEV crypt mkfs.ext4 -m 0 -q /dev/mapper/crypt mount /dev/mapper/crypt cr ( time -p { dd if=/dev/zero of=cr/file bs=1048576 count=1024; sync; } ) 2>&1 \ | perl -ne 'printf "%9.2f", 1024/$1 if /real (.+)$/' | tee -a $OUT echo 3 >/proc/sys/vm/drop_caches ( time -p dd if=cr/file of=/dev/null bs=1048576 ) 2>&1 \ | perl -ne 'printf "%9.2f\n", 1024/$1 if /real (.+)$/' | tee -a $OUT umount cr cryptsetup luksClose crypt done <<EOF -c aes-xts-plain -s 256 -c aes-cbc-essiv:sha256 -s 128 -c aes-xts-plain -s 384 -c aes-cbc-essiv:sha256 -s 192 -c aes-xts-plain -s 512 -c aes-cbc-essiv:sha256 -s 256 EOF

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

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

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

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

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

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

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

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

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

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

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