Надёжность шифрованной файловой системы

IMHO ключ, взятый из /dev/urandom, не является криптостойким. Заюзай для генерации ключа что-нибудь из openssl или gpg.

И еще, зачем генерить ключ размером 4K, если у AES длина ключа составляет 256 бит?

PS я не эксперт по безопасности/шифрованию

для шифрования лучше /dev/random использовать

>И еще, зачем генерить ключ размером 4K, если у AES длина ключа составляет 256 бит?

Но, вроде как использование 256 бит уже не является достаточно стойким. По крайней мере под офтопиком в PGPDisk используется 4 кб ключ + пароль.

Во первых, не /dev/urandom, а хотя бы, /dev/random;

во вторых, если хотите увеличить длину ключа, то это параметр -s к cryptsetup, а не bs к dd;

в третьих, не reiserfs, а ext3 с data=journal.

В четвёртых, почему и именно -c aes, когда и так достаточно других чиперов?

>Во первых, не /dev/urandom, а хотя бы, /dev/random;

Я использовал как раз и /dev/random (просто настраивал давно и эти примеры выковыривал из того, что на скорую руку нашёл в нете, именно поэтому идут некоторые несостыковки в именах файлов /file и /var/db/file)

>во вторых, если хотите увеличить длину ключа, то это параметр -s к cryptsetup, а не bs к dd;

-s не даёт поставить больше 256 потому и вопрос был.

>в третьих, не reiserfs, а ext3 с data=journal.

Файловая система не принципиальна, я использовал не рейзер, просто показал примерно. Суть вопроса в стойкости алгоритма, а не в надёжности fs

>В четвёртых, почему и именно -c aes, когда и так достаточно других чиперов?

Если подскажешь более стойкий ко взлому - буду очень признателен. Просто я делал по всяким хаутушкам, а атм глубоких разъяснений не даётся.

-s больше 256 подставит не даёт как раз из за -c aes, он больше
 и не умеет, вроде как.

Например:

name         : xts(aes)
driver       : xts(aes-i586)
module       : xts
priority     : 200
refcnt       : 4
type         : blkcipher
blocksize    : 16
min keysize  : 32
max keysize  : 64
ivsize       : 16


name         : lrw(aes)
driver       : lrw(aes-i586)
module       : lrw
priority     : 200
refcnt       : 2
type         : blkcipher
blocksize    : 16
min keysize  : 32
max keysize  : 48
ivsize       : 16

И сравните с:

name         : aes
driver       : aes-i586
module       : aes_i586
priority     : 200
refcnt       : 8
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

Т.е. 32*8=256. Смотрится всё это в /proc/crypto

Прохэшируйте случайные данные если хотите какой нибудь SHA-512 и выполните усечение до длинны ключа. Если там _действительно_ AES 256 - этого будет достаточно. Другой вопрос, не расшифруетесь ли вы сами органам? :)

Само собой, своп нужно шифровать, или не использовать; никаких хибернейтов ну и так далее. Мастер ключ надо хранить на отдельном носителе, желательно флеш-накопителе, который в случае чего - раздубасить молотком. Начальный файл лучше забить мусором из /dev/urandom. Вообще, конечно, надо использовать сертифицированные реализации, ибо что там по факту в aes.ko - надо внимательно смотреть: уточнить sbox'ы итд.

Рейндаль - 128, 192 и 256 бит. 256 битовый применим к использованию с информацией класса T.S. Этого как бы достотачно.

А 512 бит это какой класс? У мну таким ключом домашний раздел зашифрован.

AES достаточно криптостоек. Есть некоторые сомнительные места конечно, но в любом слечае - вокруг него много обсуждений и исследований. Без основательных причин лучше использовать его. Или наш ГОСТ. Но лучше AES :) Если очень хочется экзотики, можете использовать криптографические стандарты других стран: японскую камелию, или шакал. Они тоже могли бы стать AES :] Но к чему все эти игры?

А ГОСТ есть для блочных устройств и в ванильном ядре? По моему есть только патч к openssl.

512 у AES? Это очень интересно :] Такой длинны ключа _нет_ в стандарте. Может у вас какой нибудь блоуфиш?

Гм. В ванильном может и нет ) Тогда только AES.

xts, в качестве эксперимента.

Стойкость определяется в большей степени не длинной ключа. Хотя от нее тоже немало зависит. Впрочем, какая разница чем шифровать домашние разделы.

>Другой вопрос, не расшифруетесь ли вы сами органам? :)

Сервак настроен и сдан знакомой организации, т.е. если и будут кого дербанить, то их самих и их админа

>Мастер ключ надо хранить на отдельном носителе

Так и сделано

>Начальный файл лучше забить мусором из /dev/urandom

shred, кстати, аналогично работает

>Вообще, конечно, надо использовать сертифицированные реализации

Буду признателен, если "пнёте" в нужном направлении

>Стойкость определяется в большей степени не длинной ключа. Хотя от нее тоже немало зависит. Впрочем, какая разница чем шифровать домашние разделы.

В том-то всё и дело! Если б это был домашний раздел - я б вообще не парился.

>>Вообще, конечно, надо использовать сертифицированные реализации

> Буду признателен, если "пнёте" в нужном направлении

Из БСШ сертифицирован на территории пост-СССР только ГОСТ 28147. Думаю нагуглить конторы на территории вашей страны с такой малявкой можно.

С другой стороны, это как бы и не надо. Погуглите о подробностях реализации AES в ядре, если собираетесь использовать его. Интересуют сведения о тестах реализации в режиме совместимости. Вообще гарантии стоят денег. Если конторе это критично - необходимо найти товарищей, которые за вознаграждение решат поставленные задачи.

Да вроде как бы и AES 256 неплох, раз взят на вооружение правительством пендосии. Его плюс по сравнению с ГОСТ 28147-89, на мой взгляд, поддержка "из коробки".

>реализации в режиме совместимости

Совместимости чего с чем?

>>реализации в режиме совместимости

>Совместимости чего с чем?

Реализаций. Что если подать выход тестируемой реализации алгоритма на вход другой реализации дает корректный результат. И наоборот.

> Да вроде как бы и AES 256 неплох, раз взят на вооружение правительством пендосии. Его плюс по сравнению с ГОСТ 28147-89, на мой взгляд, поддержка "из коробки".

AES однозначно не плох. Вопрос может быть лишь в реализации.