LINUX.ORG.RU

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


0

0

Создаю файл, внутри него - шифрованная файловая система:

touch /file
shred -n1 -s500M /file
modprobe dm-crypt
modprobe aes
losetup /dev/loop0 /file
dd if=/dev/urandom of=/var/db/my.key bs=4096 - (генерация ключа)
cryptsetup -c aes -s 256 -d /var/db/my.key -y create mycrypt /dev/loop0
mkreiserfs /dev/mapper/mycrypt
mount /dev/mapper/mycrypt /home/user_vasya

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

Собственно сам вопрос:
1) Насколько вероятно расшифровать содержимое /var/db/file не имея файла /var/db/my.key (естественно имеется в виду что пытаться расшифровывать будут не школяры, а "соответсвующие органы")
2) Есть ли какие "подводные камни" в вышприведённом алгоритме (типа "необходимо до кучи шифровать своп" и т.д.)

anonymous

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

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

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

phoenix ★★★★
()

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

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

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

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

anonymous
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-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

marsijanin ★★
()

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

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

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

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

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

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

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

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

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

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

Так и сделано

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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