выбор блочного шифра

AES и не мучайтесь,

собственно AES это конкурс, на него были поданы заявки, среди них фавориты RIJNDAEL, MARS, SERPENT, лучший из них (угадайте какой?) стал называться AES

Blowfish достаточно быстрый алгоритм, но уступает AES, по сути когда (3)DES cтал сдавать позиции прочности, его стали заменять на blowfish, потом появился AES

сами ж дали такую хорошую ссылку, неужели непонятно ?) для диска - AES , у него отношение прочности и скорости оптимально

Здесь я тестировал 128-битный вариант. 256-битное шифрование жрет уж больно много ресурсов, для моих целей хватает 128-битного.

Вот дамп

]# cryptsetup luksDump /dev/VolGroup00/home
LUKS header information for /dev/VolGroup00/home

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	1032
MK bits:       	128
MK digest:     	13 13 14 ... 
MK salt:       	92 03 6a ...
               	1a 08 bd ...
MK iterations: 	10
UUID:          	99764ba8-7f3a-4788-ba40-a76fdae4eb53

Key Slot 0: ENABLED
	Iterations:         	154978
	Salt:               	58 63 46 ...
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

У меня сильные сомнения вызывает то, что по команде

dd if=/dev/zero of=/dev/mapper/random_sdb bs=1M

hdparm -tT /dev/mapper/random_sdb 

/dev/mapper/random_sdb:
 Timing cached reads:   1018 MB in  2.00 seconds = 508.75 MB/sec
 Timing buffered disk reads:  152 MB in  3.03 seconds =  50.14 MB/sec
halflife:/home/fazenen# hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   970 MB in  2.00 seconds = 484.82 MB/sec
 Timing buffered disk reads:  290 MB in  3.01 seconds =  96.34 MB/sec

Может быть у меня выбирается неправильный режим шифрования по умолчанию? В документации написано, что выбирается aes с режимом cbc-plain, но где посмотреть то что выбранно на самом деле я не нашел.

да, ключ там по умолчанию 256 бит.

Во-первых, /dev/zero генерирует поток нулей. Во-вторых, забить случайными данными раздел нужно ДО шифрования, например такой командой

dd if=/dev/urandom of=/dev/sda2 (или что там у Вас)

ну и в третьих, команда на прочтение заголовка luks-раздела приведена в моем предыдущем посте.

dd if=/dev/urandom of=/dev/sd?

- это слишком медленно (у меня ~3MB/s). Гораздо быстрее забить раздел зашифрованным рандомным ключем потоком нулей.

у всех так

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

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

>Гораздо быстрее забить раздел зашифрованным рандомным ключем потоком нулей.

Так на диск в этом случае будет записан сам ключ шифрования. :)))

> Забивать кусками фильмов нельзя, поскольку там есть некий формат и вообще это изображение, которое априори несет некую информацию.

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

Так на диск в этом случае будет записан сам ключ шифрования. :)))

Это не xor, не мути воду.

Да, и я забыл тебе выдать приглашение в Биореактор L.O.R., не забудь им воспользоваться.

man cryptsetup:

--cipher, -c set cipher specification string. For plain dm-crypt mappings, the default is «aes-cbc-plain», for LUKS mappings it’s «aes-cbc-essiv:sha256». For pre-2.6.10 kernels, use «aes-plain» as they don’t understand the new cipher spec strings. To use ESSIV, use «aes-cbc-essiv:sha256».

For plain dm-crypt mappings, the default is «aes-cbc-plain»

cbc

Вопрос-то в чем? (этот man я знаю достаточно хорошо)

Ок. При шифровании диска используются режимы шифрования. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation Благодаря этому одинаковые блоки данных выглядят по разному после шифрования. Там на картинке хорошо показанно.

Ну ок, хочешь по-своему, делай по-своему. В любом случае речь идет о псевдослучайных последовательностях.

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

> кстати зашифрованные данные тоже не случайная последовательность

даже если все твои файлы взяты из /dev/random? :-)

Для стороннего атакующего они как раз случайны, если он не имеет представления, откуда они взяты :-) Ну, за исключением служебных структур ФС.

различий в скорости по отношению к 128 битному и 256 битному ключу практически нет. все шифры работают примерно с одинаковой скоростью (~50MB/s), за исключением cast6 (~30MB/s) и serpent (~20MB/s)

> различий в скорости по отношению к 128 битному и 256 битному ключу практически нет

Возможно, 256-битный шифр я тестил довольно давно уже, у меня осталось ощущение, что кушал он пропускную способность прилично... Впрочем, может я и ошибаюсь, сейчас уже не на чем тестить, да и лень :-)

я идиот. зачем-то отключил в ядре smp.

# hdparm -t /dev/mapper/crypted_main_drive 

/dev/mapper/crypted_main_drive:
 Timing buffered disk reads:  206 MB in  3.02 seconds =  68.22 MB/sec