Administrace komentářů

Důležitý parametr je --pbkdf argon2id. Jinak (pokud se to poslední dobou nezměnilo) se použije (i pro dnes už implicitní LUKS2) stará PBKDF z LUKS1, což je trochu škoda.

Jinak to „plnění nulami“ je poměrně sporný nápad.

Vstup má v sobě jakési náhodnosti velmi málo, diplomaticky řečeno, což znamená, že se pak uživatel spoléhá jenom a pouze na odolnost příslušné šifry vůči protivníkovi, který téměř přesně ví, co bylo zapsáno do většiny šifrovaných bloků. Ovšemže, šifra (jako algoritmus, matematická abstrakce) bude proti takovým scénářům odolná a pevně opřená o matematické důkazy. Platí však totéž pro tuhle konkrétní implementaci příslušné šifry, od hardwaru až po software? Možná jo, doufejme, ale bezpečnost je jako cibule: pokud nemusím odloupnout slupku, nechám slupku být.

Jo, kdybych cítil potřebu tam za každou cenu něco zapsat (což fakt není potřeba), zapsal bych tam asi /dev/urandom místo /dev/zero.

Dotaz sice zmiňuje HDD (tedy rotující disk, předpokládám), nicméně i přesto bych dodal, že například na SSD, zejména pokud chce uživatel mít funkční discard skrz všechny vrstvy (filesystém, LUKS atd.) [jo, chce], je takové plnění daty dvojnásob sporné. Všeho všudy se tím vyplýtvá jeden zápis na SSD, které obvykle vydrží za svou životnost jenom cca 1000 zápisů. Po prvním discardu, který většinou nastane automaticky rovnou při vytváření filesystému, vezme celý plán s rádoby-náhodností za své.

Závěrem bych ještě upozornil na off-topic zajímavost: Pokud chce člověk --hash sha512 místo implicitního --hash sha256 u všech key slotů [jo, proč by nechtěl], musí volbu --hash sha512 zopakovat navíc i u následného / následných luksAddKey. Jinak totiž bude mít nově přidaný key slot pouze implicitní sha256. Manuálová stránka tohle bohužel nepopisuje dostatečně přesně.