Вопросы по шифрованию разделов

Везде делаю LUKS(LVM(разделы)) или просто LUKS(раздел) прямо поверх винта, без MBR. Загружаюсь с флэшки.

На SSD есть тонкость с discard/trim: будет видно, какие участки не используются файловой системой.

Везде делаю LUKS(LVM(разделы)) или просто LUKS(раздел) прямо поверх винта, без MBR. Загружаюсь с флэшки.

И как скорость, норм?

На SSD есть тонкость с discard/trim: будет видно, какие участки не используются файловой системой.

Да пофиг, не критично думаю. Всё равно лучше так, чем в открытом виде хранить.

update: нда, не обрадовал меня этот пункт: https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS#Discard.2FTRIM_suppor...

В общем, в отношении SSD я уже определился, это однозначно будет LUKS.

Вот только не знаю как лучше шифровать:

1) весь раздел целиком (кроме /boot), или создать lvm в котором выбрать шифрование сугубо /home? Как считаете? Или по скорости я почти ничего не потеряю в первом случае?

2) какой выбрать шифр и какой длины ключ?

openssl benchmark и выбирай самый быстрый. Если ЦП поддерживает аппаратное шифрование AES, то лучше AES.

К сожалению мой i3-2350M не поддерживает AES :(

Вот результат openssl benchmark: http://pastebin.kde.org/pbsm7jiye

Что лучше из перечисленного?

Поясню, мне важна в первую очередь скорость. Не думаю что мои разделы будет кто-то специально ломать. Это скорее на случай, если я ноут потеряю, или у меня его угонят.

шифрование разделов в твоём случае не нужно.

Почему? А что тогда?

Да пофиг, не критично думаю. Всё равно лучше так, чем в открытом виде хранить.

почему не хочешь зашифровать только файлы бекапа, а всё хранить в памяти? Я так и делаю. Получилось быстро и надёжно. ИМХО ещё и безопасно.

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

сугубо /home? Как считаете? Или по скорости я почти ничего не потеряю в первом случае?

ну ты в любом случае потеряешь. Чудес не бывает.

почему не хочешь зашифровать только файлы бекапа, а всё хранить в памяти? Я так и делаю. Получилось быстро и надёжно. ИМХО ещё и безопасно.

Да мне в принципе достаточно шифровать только хомяк, где пароли от контактика хрянятся (это я образно). Хранить в памяти? Многовато получится. У меня всего 6 гигов ОЗУ, которые «чуть более чем полностью» забиты под виртуальные машины. А хомяке много всякого хлама лежит. Хотя можно только dotfiles в память кидать, конечно. Но тогда и синкать их придётся переодически и + загружаться долго будет (хотя если с ssd, то пофиг). Покажи как у тебя сделано, если не в лом.

Вот результат openssl benchmark: http://pastebin.kde.org/pbsm7jiye

Что лучше из перечисленного?

прости, но ты идиот. Ну очевидно же, что чем больше, тем лучше! Враги на планетарном квантовом компьютере не 5 лет будут считать, а 15! А может не 5 сек, а 15 сек. А может 15 миллиардов лет, а не 5. Ну всяко очевидно, что md2 считается быстрее sha512. И очевидно, что последнюю ЛУЧШЕ юзать.

Я про скорость + более-менее относительно качество.

При чем здесь openssl benchmark, если ты шифруешь люксом? cryptsetup benchmark тогда уж.

Да мне в принципе достаточно шифровать только хомяк, где пароли от контактика хрянятся (это я образно).

ну дык мне тоже. Я тоже образно.

Хранить в памяти? Многовато получится.

дык вынеси куда-нить папку «порно» и папку «всякое говно, которое я скачал из интернетов».

У меня всего 6 гигов ОЗУ

у меня 1.

которые «чуть более чем полностью» забиты под виртуальные машины.

тогда — страдай. А чё ты хотел: стоя, в гамаке, в противогазе? Да ещё что-бы СПИДОм не заразится и бесплатно? Лучше подрочи, это ты сейчас можешь сделать.

А хомяке много всякого хлама лежит. Хотя можно только dotfiles в память кидать, конечно. Но тогда и синкать их придётся переодически и + загружаться долго будет. Покажи как у тебя сделано, если не в лом.

синкать не нужно. Нужно хомяк в память сувать. А всякое большое говно распихивать по каталогам, каталоги на диск, а на хомяк — симлинки.

У меня так и сделано.

А ты можешь свои виртуалки зарядить на криптованные разделы. Тут яхз...

Я про скорость + более-менее относительно качество.

не. Ты точно идиот: чем медленнее криптофункция, тем она лучше. Вся криптография именно на этом и держится — тебе просто ресурсов не хватит проверить ВСЕ пароли. Если ты криптоаналитик, и если твой враг грамотно зашифровал свой файл, т.е. так, что тебе вправду ВСЕ пароли проверять надо.

Ессно, intel опустила в унылое говно AES256, ибо теперь любой му*ак подберёт Over9000 паролей за секунду, просто купив говноинтел за $100. Или ты думаешь, что ты один такой Д`Артаньян, который про AES в курсе, а все остальные лохи?

Ну тогда — страдай.

При чем здесь openssl benchmark, если ты шифруешь люксом?

там другие алгоритмы и/или другая реализация этих алгоритмов?

Ёпт, точно. Это мне подсказали неправильно. Я по правде говоря тоже думал, что luks юзает openssl.

Тут выбор не столь велик:

% sudo cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       312076 iterations per second
PBKDF2-sha256     174762 iterations per second
PBKDF2-sha512     117028 iterations per second
PBKDF2-ripemd160  255003 iterations per second
PBKDF2-whirlpool  142469 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   124,5 MiB/s   151,7 MiB/s
 serpent-cbc   128b    50,3 MiB/s   197,2 MiB/s
 twofish-cbc   128b   114,9 MiB/s   225,2 MiB/s
     aes-cbc   256b    95,2 MiB/s   108,1 MiB/s
 serpent-cbc   256b    50,1 MiB/s   196,2 MiB/s
 twofish-cbc   256b   114,5 MiB/s   219,6 MiB/s
     aes-xts   256b   158,2 MiB/s   155,6 MiB/s
 serpent-xts   256b   201,0 MiB/s   201,6 MiB/s
 twofish-xts   256b   230,0 MiB/s   232,0 MiB/s
     aes-xts   512b   108,6 MiB/s   107,8 MiB/s
 serpent-xts   512b   223,8 MiB/s   212,4 MiB/s
 twofish-xts   512b   230,0 MiB/s   232,0 MiB/s

не. Ты точно идиот: чем медленнее криптофункция, тем она лучше.

Да что у тебя заело «идиот», да «идиот»?

Я не спец в криптографии, но смею предположить, что «тормознутость» определённого алгоритма шифрование не есть его «надёжность». Вспомни md5.

Можно еще подключать алгоритмы через modprobe.

modprobe camellia
cryptsetup benchmark -c camellia-xts-plain64

У меня serpent-xts всех уделывает, как ни странно.

Ты точно идиот: чем медленнее криптофункция, тем она лучше.

А пацаны на конкурсе AES не знали, и выбрали самый быстрый алгоритм rijndael.

Для «специалистов»: когда пользователь вводит пароль, он гоняется через хеш-функцию одну секунду (время конфигурабельно), результат используется в качестве ключа. То есть сложность перебора зависит только от производительности машины злоумышленника, а не от скорости работы хеш-функции и тем более алгоритма шифрования (который даже выполнятся при переборе не будет, т.к. хеш ключа уже хранится в заголовке Luks).

luks(dm_crypt)
            \---lvm2
                   \---ext4-root
                   \---swap

Для внешних винтов думаю стоит юзать encfs с blowfish

У меня он гораздо медленней чем aes (без aes-ni, мой проц не имеет этих инструкций) Сразу выкинь однораундовый aes-ni. twofish несколько современней aes, но медленней, serpent, емнип, ещё надёжней и ещё медленней.

какой выбрать шифр и какой длины ключ?

aes-cbc-essiv, ключ 256бит, хэш sha256, вполне достаточно. Тут вроде забыли упомянуть, что xts использует половину ключа, in fact --cipher «aes-xts-essiv:sha256» --key-size=256 будет использовать 128байт.

Всегда указываю на количество итераций хэша --iter-time=25000.

cryptsetup --verbose --cipher "aes-cbc-essiv:sha256" --key-size=256 --hash=sha256 --iter-time=25000 --verify-passphrase luksFormat /dev/чототам

После создания и luksFormat, найти uuid

dd if=/dev/random of=/secpath/key bs=512 count=1
cryptsetup luksOpen /dev/disk/by-uuid/UUID my_cryptodisk
cryptsetup luksAddKey /dev/disk/by-uuid/UUID /secpath/key
cryptsetup luksClose my_cryptodisk

cryptsetup luksOpen /dev/disk/by-uuid/UUID --key-file /secpath/key my_cryptodisk

Спасибо огромное за развёрнутый ответ!

1. а что у тебя за проц, кстати?

2. бут ведь вне lvm?

Да, я уже передумал использовать encfs на винте для бекапов. Лучше создам там lvm с бекапом и зашифрую его (фильмы, музло в незашифрованную область), а ключ в /home положу, чтобы каждый раз не вводить пароль (вводить пароль буду только при монтировании /home).

aes-cbc-essiv, ключ 256бит, хэш sha256, вполне достаточно.

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

Вот результат openssl benchmark: http://pastebin.kde.org/pbsm7jiye

Что-то я затупил :) не та команда, с телефона просто писал, не проверил. Надо было cryptsetup benchmark. У меня serpent как ни странно дает лучшую производительность.

UPD: Опоздал я с комментом.

а что у тебя за проц, кстати?

Не скажу, параноикноут, intel серии Penryn, ~2ghz.

бут ведь вне lvm?

Если не особо вникая в детали:

sda1+sdb1>raid1>ext4>boot
sda3+sdb3>raid1>luks>lvm>swap
                        >ext4>root

raid1>aes-cbc-essiv_256>lvm>ext4   47-51mb/s
raid0>ext4                         96-99mb/s
raid0>aes-cbc-essiv_128>ext4       79-87mb/s
raid0>aes-cbc-essiv_256>ext4       62-68mb/s
raid0>des-cbc-plain64>ext4         35-36mb/s
raid0>aes-cbc-plain128>ext4        83-84mb/s
# zfs checksum=off atime=off
raid0>aes-cbc-essiv_128>zfs        64-68mb/s

Скорость ещё зависит не только текущей загрузки проца, но и как ни странно от винта, т.е. иногда шифрование упирается в винт, иногда в проц.

Лучше создам там lvm с бекапом и зашифрую его

Ну имеет смысл перемещать сразу rootfs и swap на криптодиск>lvm. Всякую медиа можно и не шифровать.

Ага, но всё равно спасибо, я например только благодаря твоей ошибки наткнулся на 'openssl speed', ранее не обращал внимание :)

Я не спец в криптографии, но смею предположить, что «тормознутость» определённого алгоритма шифрование не есть его «надёжность».

нет конечно. Всегда можно пойти иным путём.

Вспомни md5.

не забываю. Её пока никто не сломал. А ты, сможешь?

А пацаны на конкурсе AES не знали, и выбрали самый быстрый алгоритм rijndael.

и что?

Для «специалистов»: когда пользователь вводит пароль, он гоняется через хеш-функцию одну секунду (время конфигурабельно), результат используется в качестве ключа. То есть сложность перебора зависит только от производительности машины злоумышленника

ты сказал ерунду. Предположим, что у меня i80486, ты хочешь сказать, что расшифруешь мой файл, который я 5 секунд шифровал? Попробовать слабо?

Благодарю за цифры. Сейчас тоже эксперименты сделаю на своей машинке.

Скорость ещё зависит не только текущей загрузки проца, но и как ни странно от винта, т.е. иногда шифрование упирается в винт, иногда в проц.

В этом плане мне бояться нечего (кроме снижения криптостойкости за счёт trim) - у меня ssd.

Ну имеет смысл перемещать сразу rootfs и swap на криптодиск>lvm. Всякую медиа можно и не шифровать.

Да и рут в принципе чего шифровать? Что там есть ценного кроме /etc/shadow? Но если есть подозрение что кто-то сможет поиметь доступ к компу в твоё отсутствие и подменить бинарники с бекдором - то есть смысл и его шифровать, конечно. Но не думаю что в моём случае)

Swap у меня файлом на root для суспенда, который опять не работает, поэтому не использую.

Пока что остановился на идее сделать следующее:

ssd>sda1>boot (не шифруем)
ssd>sda2>lvm>root (не шифруем)
ssd>sda2>lvm>home (шифруем, храним исключительно dotfiles с настройками, паролями программ и с ключиком для расшифровки бэкапов на винте)
ssd>sda2>lvm>data (сюда я складываю всё то же что лежало у меня в хомяке вроде музыки, фильмов, етц и монтирую отдельным mountpoint в /home/user/data, например)
hdd>sdb1>lvm>data (не шифруем)
hdd>sdb1>lvm>backup (шифруем, монтируем ключом, который лежит в /home)

Как считаешь, норм?

ты хочешь сказать, что расшифруешь мой файл

Не угадал.

который я 5 секунд шифровал

Опять мимо. 5 секунд шифруется не файл, а генерируется ключ.

В этом плане мне бояться нечего (кроме снижения криптостойкости за счёт trim) - у меня ssd.

В SSD я не спец, там вроде надо указывать
cryptsetup luksOpen --allow-discards /dev/sdX my_crypt

--allow-discards
              Allow  using of discards (TRIM) requests for device.  This option is only relevant for
              create, luksOpen or loopaesOpen.

              WARNING: Assess the specific security risks carefully  before  enabling  this  option.
              For  example,  allowing discards on encrypted devices may lead to the leak of informa-
              tion about the ciphertext device (filesystem type, used space etc.)  if the  discarded
              blocks can be located easily on the device later.

              Kernel  version  3.1  or  more  recent  is required.  For older versions is the option
              ignored.

Нечто близкое по теме.

Ещё, так как некоторые SSD контроллеры показывают высокую скорость, за счёт сжатия данных, при использовании крипто может просесть скорость, так как это чистая энтропия. Тут пусть меня поправят SSD-гуру.

Да и рут в принципе чего шифровать? Что там есть ценного кроме /etc/shadow?

Всё! Всё ценное. Хомяк ассоциирую исключительно с набором конфигов от текущего окружения.

Но не думаю что в моём случае)

Шнайер всегда говорил, что надо взвесить угрозы и действовать соответственно. Можно и не перебарщивать.

Как считаешь, норм?

ssd>sda2>lvm
hdd>sdb1>lvm

Во-первых, это должны быть два разных pv. Во-вторых, вид lvm-volume>luks как-то режет глаз :)

Вобщем да, хотя смотря для/от чего.
Если нет проблем с ресурсами проца, то почему бы не запилить весь rootfs-lvm, а потом, если вдруг что-то упрётся в скорость переместить его на нешифрованный раздел, хотя сам не сталкивался с чем либо подобным.

Остаётся только вероятность потерять данные при повреждении диска или сектора с мастер-ключём, от второго cryptsetup luksHeaderBackup --header-backup-file /safeplace/sdX3.header /dev/sdX3, а от первого я перелез на mdadm.

Вот как-то так.

--iter-time=25000 это я там загнул, значит, что хэшить будет 25сек, и примерно столько же будет уходить времени на открытие контейнера, это на одном и том же проце, 7-10 секунд вполне достаточно.

вообще, попробуй забэкапь корень, перенеси на luks да погоняй пару дней, всякие aptitude, firefox, прочее что в повседневной работе, не пойдёт откатишь.

Всё! Всё ценное.

Так а что ценного в бинарных файлах ОС, которые можно скачать с сайта? :) Разве что логи в /var (хотя они у меня всё равно в ОЗУ), ну и вариант с возможной подменой бинарников.

Ещё, так как некоторые SSD контроллеры показывают высокую скорость, за счёт сжатия данных, при использовании крипто может просесть скорость, так как это чистая энтропия. Тут пусть меня поправят SSD-гуру.

Блин, фигово если так

Во-первых, это должны быть два разных pv. Во-вторых, вид lvm-volume>luks как-то режет глаз :)

Ага, это опечатка у меня) А почему глаз режет-то?) Какая разница, раздел отдельный криптовать, или логическую область? (я не умничаю, а серьёзно спрашиваю)

Если нет проблем с ресурсами проца, то почему бы не запилить весь rootfs-lvm, а потом, если вдруг что-то упрётся в скорость переместить его на нешифрованный раздел, хотя сам не сталкивался с чем либо подобным.

По такой схеме у меня аккумы будут за час сдыхать, что тоже не очень хорошо :)

Вобщем да, хотя смотря для/от чего.

Во-во, просто у меня в хомяке пароли всякие, куки браузера, на конфиги пофиг, они даже на гитхабе в открытом доступе есть) А вот сопрут ноут - будет очень неприятно, если чем нибудь завладеют из этого.

Остаётся только вероятность потерять данные при повреждении диска или сектора с мастер-ключём,

Так я думал использовать две авторизации - по ключу и по паролю. Пропадёт ключ на шифрованном разделе - введу пароль, а ключ тупо чтоб пароли по сто раз не вводить. Разве так нельзя?

cbc

xts

Зачем, если есть ctr?

Так я думал использовать две авторизации - по ключу и по паролю. Пропадёт ключ на шифрованном разделе - введу пароль, а ключ тупо чтоб пароли по сто раз не вводить. Разве так нельзя?

Можно, я про мастер-ключ говорил, паролем/ключом ты расшифровываешь мастер-ключ, которым производится уже непосредственно блочное шифрование.

Если повредить произвольные блоки на диске - не страшно, только они не будут читаться, а если повредить мастер-ключ, то уже ничего не будет ни читаться, ни писаться :)

просто у меня в хомяке пароли всякие, куки браузера, на конфиги пофиг

Да, у меня всякие /var/www, /var/lib/mysql, /etc/openvpn/keys, /croots, /kvm, и тьма-тьмущая софта, файлов и конфигов настроена и распихана не помню уже где, мне что, теперь список составить, что, где и в какой мере может быть уязвимо в случае потери? :)

По такой схеме у меня аккумы будут за час сдыхать

cpufreq-set -r -g powersave

И терпи!

А почему глаз режет-то?) Какая разница, раздел отдельный криптовать, или логическую область?

Обосновать не могу, но в практике не встречал. Разве что один пароль от всего, чего захочешь, rootfs/swap/... нарезкай сколько надо, всё под одним паролем, всё шифровано.

Хотя оказывается, некоторые делают LVM over LUKS over LVM, что у них там выходит страшно предположить.

Блин, фигово если так

Это по памяти, скастуй шарящих по ssd и спроси.

Пацаны у нас тут самый главный криптоаналитик нарисовался с окладом как у всего лор отделения.

Например, если используется команда locate, то она умеет создавать базу где-то в /var; возможны и другие утечки какой-то секретной информации в /var, так что я бы просто зашифровал весь диск не заморачиваюясь.

Зачем, если есть ctr?

ECB should not be used if encrypting more than one block of data with the same key.

CBC, OFB and CFB are similar, however OFB/CFB is better because you only need encryption and not decryption, which can save code space.

CTR is used if you want good parallelization (ie. speed), instead of CBC/OFB/CFB.

XTS mode is the most common if you are encoding a random accessible data (like a hard disk or RAM).

OCB is by far the best mode, as it allows encryption and authentication in a single pass. However there are patents on it in USA.

...

CTR is amenable to parallelization because you can split the message into chunks, each chunk having a range of counter values associated with it, and encrypt (or decrypt) each chunk independently.

Анонимус, что ты делаешь, ахахаха, прекрати.

Ушел прогнать тестов.

Отпишись потом, плз.

Ааа, блин, реально. В общем подниму сначала на винте, посмотрю как проц жрётся, а потом в случае чего весь рут с хомкой закриптую.

Можно, я про мастер-ключ говорил, паролем/ключом ты расшифровываешь мастер-ключ, которым производится уже непосредственно блочное шифрование.

Ага, понял! Рисковано конечно, но что поделаешь :)

Да, у меня всякие /var/www, /var/lib/mysql, /etc/openvpn/keys, /croots, /kvm, и тьма-тьмущая софта, файлов и конфигов настроена и распихана не помню уже где, мне что, теперь список составить, что, где и в какой мере может быть уязвимо в случае потери? :)

В общем ты меня почти убедил. Тещу на винте и если всё ок - ставлю на рут.

Обосновать не могу, но в практике не встречал. Разве что один пароль от всего, чего захочешь, rootfs/swap/... нарезкай сколько надо, всё под одним паролем, всё шифровано.

Это ты ведь про случай когда LVM ВНУТРИ Luks, правильно?

Хотя оказывается, некоторые делают LVM over LUKS over LVM, что у них там выходит страшно предположить.

оО то есть одновременно? Но зачем?

Это по памяти, скастуй шарящих по ssd и спроси.

Ай, я по ссд столько спецов развелось и все разное говорят, что я уже мало кому верю. Лучше просто не запариваться :)

sync;sync ; dd if=/dev/zero of=/mnt/rw bs=1M count=512 conv=fdatasync ; sync
sync;sync ; dd if=/dev/zero of=/mnt/rw bs=1M count=4096 conv=fdatasync ; sync

raid0
/dev/md2 512k chunks
                                 mb/s
                        ext4     100;    106;    102;   105
aes-cbc-essiv 128       ext4     87,5;   77,5;   76;    89
aes-cbc-essiv 256       ext4     77,8;   78,9;   70;    75
aes-xts-essiv 256 (128) ext4     99;     85,1;   90;    95
aes-xts-essiv 512 (256) ext4     72,5;   76,3;   81,3   79,3
aes-ctr-essiv 128       ext4     88,7;   96;     97     87,3
aes-ctr-essiv 256       ext4     70,6;   81;     81,7;  83,2
aes-cbc-plain 128       ext4     80;     79,5;   92,8;  72,1
aes-xts-plain 256 (128) ext4     96;     101;    88;    98
aes-ctr-plain 128       ext4     88,4    90;     95;    95

Вобщем ничего нового, всё что проще aes-cbc-essiv-256 или начинает по скорости упираться в рейд, или плавает в зависимости от циклов работы/охлаждения процесора, хотя и долгие тесты на count=4096 выдавали в целом то же.
Дальше стало скучно.

Рисковано конечно

Бэкапь хэдэры. Прячь бэкапы.

Тещу на винте и если всё ок - ставлю на рут.

При переносе рабочей системы на lusk+lvm советую запастись парой ядер, чтоб не для всех (и тем более для одного единственного ядра) обновлять inird, а то если допустишь ошибки - получишь незагружаемую систему.

Что вдвойне уныло если ноут, надо откручивать, вытаскивать, ставить запасной винт с рабочей системой (он ведь есть?) чтоб зачрутиться, починить и обновить initramfs.

Это ты ведь про случай когда LVM ВНУТРИ Luks, правильно?

Да, делаешь luks, открываешь, дальше pvcreate /dev/mapper/crypt_disk и поверх этого pv нарезаешь swap, rootfs, home, и прочее.

оО то есть одновременно?

Ну там вроде это разные pv.

Но зачем?

Во имя санты видимо.

Тоесть самое менее ресурсоёмкое aes-xts-essiv, или даже aes-xts-plain?

Поясни плз что значит бекапить хидеры. Можно пример какой нибудь, или пруф?

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

А по скорости ж по идее пофиг lvm в luks, или luks в lvm?

кто-то сможет поиметь доступ к компу в твоё отсутствие и подменить бинарники с бекдором - то есть смысл и его шифровать

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

Опять мимо. 5 секунд шифруется не файл, а генерируется ключ.

ясно. Ликбез, не благодари.

Ещё, так как некоторые SSD контроллеры показывают высокую скорость, за счёт сжатия данных, при использовании крипто может просесть скорость, так как это чистая энтропия.

тут не в сжатие дело. Обычная ФС может изменить только то, что изменилось. А криптоФС вынужденна менять ВСЁ. Потому о всяких снапшотах и т.п. можно забыть. Ext4 обычно вообще не хранит блок, в котором одни нули, потому файлы часто занимают намного меньше места, чем их размер. Но в криптоФС это невозможно.

Так я думал использовать две авторизации - по ключу и по паролю. Пропадёт ключ на шифрованном разделе - введу пароль, а ключ тупо чтоб пароли по сто раз не вводить. Разве так нельзя?

нет. Ибо враг «тупо не введёт пароль». Откуда система узнает, что её не скомуниздили только-что?