TrueCrypt и разделы/алгоритмы

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

У меня есть новый диск на 400 гигов. Хочу чоздать на нем пару разделов пол линукс ( всего на 20 гигов), пару под винды (тоже около 20-30 гигов). Все остальное использовать как зашифрованные диски/файлы.
Информация логически разделена (для примера как видео, музыка, базы данных, порно :)))

1) Теряется ли ВСЯ информация, если произойдет сбой на диске и появится бэд-блок? Или просто какие-то части зашифрованного раздела будут недоступны?

2) остальные350 гигов лучше
а) сделать одним логическим разделом и зашифровать его как раздел
б) сделать одним логическим разделом и создать на нем один зашифрованный контейнер
в) сделать одним логическим разделом и создать на нем несколько зашифрованный контейнеров
г) сделать несколько логических разделом и зашифровать их как раздел
д) сделать несколько логических разделом и создать на них по зашифрованному контейнеру

3) Какой алгоритм предпологает хорошую стойкость наряду с отличной скоростью (для первичного и скрытого контейнеров), а какой наивысшую стойкость (для редко используемых важных данных)?

TC я тестировал на скорость, примерно вышло по разным тестам, что Blowfish, Twofish и AES имеют наивысшие скорости. Далее идут Serpent и CACT5, за ними с огромным отрывом другие.
Насколько надежны быстрые алгоритмы?

4) На что влияет Buffer size?

5) Какой хэш-алгоритм лучше выбрать?
Whirlpool
SHA-1
RIPEMD-160

Спасибо!

Комментарии

—	SATtva (28/09/2006 18:56) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

1. Сектора шифруются независимо, так что повреждение информации будет также локализовано размерами сектора.

2. Я бы предпочёл вариант "г".

3. Все предложенные алгоритмы равно пригодны по стойкости для любых задач. Но, например, CAST, 3DES и Blowfish оперируют на 64 блоках, а потому их небезопасно использовать на 2-гигабайтовых и более крупных файлах (контейнерах, аналогично). Соответственно, Вам они не подойдут. Я бы на Вашем месте выбрал скоростной Twofish, а для сверхценных данных — один из каскадных шифров (такой, где используется одновременно несколько алгоритмов, к примеру, Serpent-Twofish-AES): их преимущество в том, что даже если когда-нибудь будет взломан один из алгоритмов, данные всё равно будут в безопасности.

4. Не понимаю, о чём Вы. Может быть, cluster size? Если так, то это размера кластера файловой системы криптоконтейнера. Чем он больше, тем быстрее будет доступ к контейнеру, но и тем быстрее будет расходоваться свободное место, особенно при большом числе мелких файлов. Но не все ФС могут работать с произвольным размером кластера, лучше оставить режим по умолчанию.

5. Для выработки ключей из паролей подойдёт любой алгоритм. Вся нынешняя ситуация с SHA-1 относится к цифровым подписям, но не к подобным приложениям. Я бы, пожалуй, выбрал Whirlpool, хотя он и медленнее.

—	*Гость* (29/09/2006 12:39) <#>

Спасибо за ответы!
1. Да, я проверил, изменение одного байта в контейнере меняет только 17 байт в оригинале (AES)
2. а почему?
3. прогуглил инет на эту тему, остановился на AES и Twofish, и конечно их связке
4. Имеется ввиду опция в TC в окошке тестирования скорости алгоритмов

—	*Гость* (29/09/2006 18:24) <#>

Сам нашел :)

Вопрос: Какой тип раздела TrueCrypt лучше: файл-контейнер или накопитель/устройство?
Ответ: Вы можете работать с файлом-контейнером, как и с любым обычным файлом: копировать, перемещать и т.д. (это также означает, что контейнер может быть поврежден или удален столь же просто, как и обычный файл). Накопители/устройства могут быть лучше в плане производительности. Учтите, что чтение/запись в файле-контейнере становятся значительно медленнее, если контейнер (сам его файл, а не внутренняя файловая система) сильно фрагментирован. То же самое касается подключения скрытого раздела в файле-контейнере. Причина этого в том, что хидер скрытого раздела расположен в конце внешнего раздела-носителя, и когда контейнер фрагментирован, поиск его окончания занимает большее время. Для решения этой проблемы дефрагментируйте контейнер (файловую систему, где хранится контейнер, предварительно его отключив).

—	*Гость* (12/10/2006 00:43) <#>

"Но, например, CAST, 3DES и Blowfish оперируют на 64 блоках, а потому их небезопасно использовать на 2-гигабайтовых и более крупных файлах (контейнерах, аналогично)"
А можно поподробнее об этом, я ничего про это не слышал...

—	SATtva (12/10/2006 13:21) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

В моём ответе была опечатка, должно было быть так: "Но, например, CAST, 3DES и Blowfish оперируют на 64-битовых блоках..."

Суть в том, что при шифровании крупных файлов алгоритмом с малым блоком ряд блоков может быть зашифрован в идентичный шифртекст, что даст оппоненту материал для криптоанализа. С учётом парадокса дней рождений, такие коллизии могут проявляться уже после первого гигабайта данных, поэтому TrueCrypt предупреждает о рисках использования подобных шифров на контейнерах, крупнее 1Гб.

—	*Гость* (21/10/2006 13:23) <#>

А как насчет безопастности 128-битной версии Blowfish? В PGPfone вроде используется, но при этом вроде же Шнайер и компани пытались сделать 128-битную версию, и неудачно.

—	SATtva (21/10/2006 18:33) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Blowfish оперирует с 64-битовыми блоками. Проблема относится к любым 64-битовым шифрам. Это статистическая проблема, а не архитектуры алгоритмов.

—	unknown (23/10/2006 08:52) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Существует экспериментальное расширение для 128-блоковой версии Blowfish (Kaweichel):

http://eprint.iacr.org/2005/144
http://eprint.iacr.org/2005/432

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

Ваша оценка документа [показать результаты]