LINUX.ORG.RU

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


0

0

Какой шифр лучше подходит для шифрования диска?
AFAIK, шифры делятся по:
1] длине ключа - лучше 256 бит
2] длине блока - на что это влияет?
3] производительности - у меня четвертый пень, HT, 32bit, если это влияет
4] количеству слабых ключей - ключи как-то проверяются при создании?

Судя по этому:
http://www.pgpru.com/biblioteka/statji/sravniteljnyjjobzoralgoritmovpgp
стоит выбирать между AES, CAST,Twofish и Blowfish.
Что из них и какой версии стоит выбрать в данном случае?


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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()

Здесь я тестировал 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

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous

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

dd if=/dev/zero of=/dev/mapper/random_sdb bs=1M
жесткий диск забивался случайными данными на скорости 50MB/s при полной загрузке процессора. Явно дело не в /dev/zero и не в скорости жесткого диска (~100MB/s).

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, но где посмотреть то что выбранно на самом деле я не нашел.

alex4
() автор топика
Ответ на: комментарий от alex4

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

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

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

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous
dd if=/dev/urandom of=/dev/sd?

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

alex4
() автор топика
Ответ на: комментарий от annoynimous

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

alex4
() автор топика
Ответ на: комментарий от alex4

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

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

iZEN ★★★★★
()
Ответ на: комментарий от alex4

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

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

annoynimous ★★★★★
()
Ответ на: комментарий от iZEN

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

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

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

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous

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

alex4
() автор топика
Ответ на: комментарий от annoynimous

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

alex4
() автор топика
Ответ на: комментарий от alex4

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

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

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

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous

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

alex4
() автор топика
Ответ на: комментарий от alex4

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

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

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous

я идиот. зачем-то отключил в ядре 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
теперь гораздо лучше, хотя все равно не 100MB/s

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.