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

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

unknown
AES, его хорошо пиарят и впаривают во все что только можно ...
Моя паранойя в него не верит, есть в штатах такое понятие как ограничение технологий на экспорт, часто то одно, то другое не дают вывозить или юзать, а тут целый алгоритм идеального шифрования на раздаче всем подряд :)
Хочется чего то другого

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

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

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

которое давно благополучно умерло в отношении почти всех криптотехнологий, по крайней мере не только самого AES, но и других блочных шифров. Можете выбрать исконно американские Blowfish/Twofish или условно английско-датско-израильский Serpent. Если быстродействие решает, то за вычетом AES выбор Twofish вполне адекватен.

Я не хочу ни кого обидеть, но хочется видеть конкретику. все говорят абстрактно: этот быстрее, а тот медленнее, но никто не говорит в цифрах.

Это очень давно было.


Это от незнания матчасти. Это ж результат открытого конкурса НИСТ. Вам не нравится Rijndael (AES)? Предложите свой шифр, который будет лучше. Обсуждалось много раз, в т.ч. в /comment3301 и /comment32619.


Не говорите ему, что Keccak — очень вероятный следующий финалист, тоже разработан в Бельгии.


Тоже много раз обсуждалось, + нагуглить более, чем реально. Общие идеи можно уловить с /comment39601, /comment17615 и отсюда.

На форуме был результат бенчмарков в картинках, но найти его будет затруднительно. А может и самой картинки уже нет в том посте. Есть тулзы (название не помню), которые делают такой бенчмарк под Linux — можно всегда всё проверить самому и на конкретном железе.

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

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

unknown
Большое спасибо, это и искал. Теперь осталась только непонятка с архитектурой -стоит ли переходить на х64 или нет ?
Читал как то одну интересную статейку (ссылку сейчас не найду, да и всех подробностей ее не помню) на тему сравнения винды хр, висты и семеры в х86 и х64 редакциях на ноуте, на тему кто больше протянет на батарее. так в х86 жилось по дольше на хр до 30мин, на висте разница меньше, а семера шла почти вровень. Интересно как с этим дело в линуксе.

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

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

У AES конечно есть небольшая особенность: скорость расшифрования меньше скорости зашифрования (проявляется естественно не во всех режимах шифрования). Но это не должно проявляться столь значительно и для фишей такого быть не должно. Подозреваю, что гиг на запись вполне себе способен кэшироваться при современных размерах памяти.
проверялось именно на разделе или записывалось в файл поверх файловой системы на разделе?