1, 3, 4 - всё оставить по умолчанию, если luks2. Если luks1, то сначала обновить.

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

С удовольствем подпишусь и послушаю конкретные народные советы

как быть?

Использовать дефолт.

Настройки по умолчанию там задавали не дураки, без веских причин их лучше не трогать.

Не дураки. Но им стоит считаться с взглядами, например, СМИ. А в этом случае, 20-секундная генерация ключа может повредить репутации, что приводит к выбору оптимума между скоростью и безопасностью.

Вот, наглядная разница функций: https://pastebin.com/R0AHk2ba

Насколько мне известно, argon еще медленнее.

Вот, полный список: https://pastebin.com/06FEKMGB

256-битного ключа достаточно

Насколько я знаю, Grub2 пока что не поддерживает LUKS2, если есть желание /boot тоже держать зашифрованным. Но, думаю, TC не ставил такую цель.

Нет, boot меня не интересует. Но, можно сделать так:

/dev/sda1 — раздел для образов .efi, не зашифрован, FAT32; /dev/sda2 — раздел /boot, зашифрован, LUKS1; /dev/sda3 — /, зашифрован, LUKS2.

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

Но брутить ведь сложнее будет?

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

кстати, в cryptsetup (и по дефолту тоже) задаётся именно время генерации ключа, как следствие, если инициализировать luks на медленной машине, то итераций будет меньше, и на более мощной время будет монтирования (ну и брутфорса) меньше.

Спасибо

1)PBKDF2 Whirlpool/Или Sha512; или, лучше, вообще, использовать argon?

Вроде как argon лучший, там даже что-то такое придумывали, чтобы подсчет тяжело распараллеливать было. Зато PBKDF2/Sha512 лучше обкатаны.

2)Хеш-функции же влияют только на скорость размонтирования, так ли?

Монтирования, хотел сказать? Ну да, на скорость собственно работы не влияет.

3)Ключ тут делится на 2, выбирать 256(128) или 512(256) для aes?

На два делится он только для xts-режима.

4)aes-xts или aes-cbc?

aes-xts

Очень познавательно, благодарю!

Для aes-xts ключ делай в два раза длиннее чем для aes-cbc чтобы безопасность была таже. Для aes-xts ключ ставь 512.

Время итерации надо увеличивать если проц слабый, открыватся диск при этом будет значительно медленнее.

sha512 & whirlpool вполне хороши.

О рандоме еще ничего тебе не сказали, принудительно используй /dev/random по умолчанию там /dev/urandom

Для aes-xts ключ ставь 512.

Это сто лет как умолчание, не надо ничего ставить.

256-битного ключа достаточно

поддерживаю, сам aes такой, что 512 не сильно прибыльный.

/dev/sda1 — раздел для образов .efi, не зашифрован, FAT32; /dev/sda2 — раздел /boot, зашифрован, LUKS1; /dev/sda3 — /, зашифрован, LUKS2.

А зачем это делать? Если у кого-то есть рут на твоей тачке, он получит все ключи через dmsetup table --showkeys. А вариант незаметного физического доступа стремится к нулю: просто запароль биос и отключи загрузку с юсб.

А вариант незаметного физического доступа стремится к нулю: просто запароль биос и отключи загрузку с юсб.

True way - контролировать efi файл через UEFI. В UEFI хранится хеш efi файла, и если кто-то его изменить - PC не загрузится.

Незаметный физический доступ не стремится к нулю. Представь ситуацию: стоит у тебя сервер в ДЦ, ты все зашифровал кроме раздела с efi файлом. Сотрудник ДЦ выключает твой сервер (типа сбой), подменяет тебе efi файл, это efi пропатчен на сохранение ключей которым у тебя /boot зашифрован или сразу после расшифровки /boot тебе ядро патченное туда закинут… И всё, привет паролям.

True way - контролировать efi файл через UEFI. В UEFI хранится хеш efi файла, и если кто-то его изменить - PC не загрузится.

Это от юз кейса зависит, на домашнем ноуте - вообще пофиг. И вообще, ты описал способ, а можно реальный гайд?

Поддержку luks2 в grub уже считай завезли. Код написан, осталось дело за малым.

Спасибо, не знал. Буду наблюдать за рассылкой и репозиторием.

Спрошу здесь

Дефолтный алгоритм шифрования не подходит, так как процессор старенький и скорость падает при его использовании, serpent и twofish примерно одинаковы по скорости, что получше будет использовать или может пожертвовать скоростью?

почитай сообщения в этой теме

Не берусь утверждать, но сюда скину: https://hashtelegraph.com/algoritm-serpent-priznan-nebezopasnym/

https://ru.wikipedia.org/wiki/Twofish

Наверное, twofish будет более предпочтителен.