Dotaz: Ideální parametry pro LUKS

[Petr Fiedler]

Zdravím,
potřeboval bych poradit, jak co nejlépe zašifrovat oddíl s citlivými daty. Já to dělám takto:

# Zaplnění oddílu XY náhodnými daty
cryptsetup open --type plain --key-file /dev/random /dev/sdXY nejaky_nazev
dd bs=1M if=/dev/zero of=/dev/mapper/nejaky_nazev status=progress
cryptsetup close nejaky_nazev

# Likvidace LUKS hlavičky
dd if=/dev/urandom of=/dev/sdXY bs=1M count=10 status=progress

# Zašifrování oddílu XY
cryptsetup luksFormat --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random /dev/sdXY status=progress

# Passphrase bude složená z > 35 znaků - 0-9, a-z, A-Z a speciální znaky.

Použili byste jiné parametry? Třeba jinou šifru? Že by to bylo pomalejší nevadí. HDD připojím ~1 x za rok. Zkontroluji, případně doplním data a rok na něj zase nesáhnu, takže tu chvilku to vydržím. Hlavně, aby data byla opravdu dobře zabezpečená.

---

---

Odpovědi

[Peter Golis]

Skúsil by som si spustiť benchmark aby som vedel aké šifry a s akými veľkosťami kľúčov podporuje tebou používané distro aktuálnej verzie.

Vybral si si prúdovú šifru AES-XTS ktorá má u mňa dostatočnú rýchlosť keďže inštrukčná sada AES-NI (kryptoakcelerátor) je bežnou súčasťou CPU už dlhšiu dobu. Pre porovnanie (Algo aes-xts 512b):

CPU	Priepustnosť	Vek CPU	Poznámka
i5-2520M	1071 MiB/s	9 rokov	Nejaké procesy mi brali 20% zo 400% CPU
i3-10110U	1495.9 MiB/s	2 roky	Nič mi nebežalo, ale CPU prepnuté do úsporného režimu so zakázaným pretaktovaním.
i3-10110U	2438 MiB/s	2 roky	Nič mi nebežalo, CPU prepnuté do výkonného režimu s povoleným pretaktovaním.

Obávam sa že v prípade tebou vybratej prúdovej šifry nebude rýchlosť limitujúcim faktorom. Na tom prastarom kuse mi to zvládlo rýchlosť cca 1GB/s (8Gb/s). Ale ten benchmark ti prezradí či náhodou už nemáš novší kernel a cryptsetup ktoré by mohli zvládnuť dlhší kľúč.

[Petr Fiedler]

Já čerpal info z:
dm-crypt/Device encryption
When to use Argon2i vs Argon2d vs Argon2id?

takže toto je myslím plně ok:

cryptsetup --cipher aes-xts-plain64 --hash sha512 --key-size 512 --pbkdf argon2id --type luks2 --use-urandom --verify-passphrase luksFormat /dev/sdXY

Zdar Max

[Petr Fiedler]

Díky za odkaz.

Díky za příkaz. Proč --use-urandom ?

[Max]

Je to v tom odkazu:
Note that /dev/random blocking pool has been removed. Therefore, --use-random flag is now equivalent to --use-urandom

Zdar Max

[Andrej]

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ě.

[Petr Fiedler]

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.

To je dobré vědět.

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

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.

Snad to chápu správně. Myslím, že díky CPU instrukci AES NI se ten oddíl nezaplní nulami, ale náhodnými daty.

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ě.

Taky dobré vědět. Díky za informace.

[Andrej]

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

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.

Snad to chápu správně. Myslím, že díky CPU instrukci AES NI se ten oddíl nezaplní nulami, ale náhodnými daty.

Ne, to není správná interpretace skutečnosti.

Ta data nebudou náhodná. Z principu náhodná být nemohou, protože musí existovat způsob, jak z nich zpátky dešifrovat ty zapsané nuly.

Ovšemže, jedním z cílů kryptografie je, aby se šifrovaná data na první i druhý pohled co nejvíc podobala náhodným datům. Nicméně zašifrovat spoustu nul znamená, jak už jsem psal, zbytečně se vzdát jedné ze slupek zabezpečení: Kdyby implementace příslušné šifry náhodou měla nějakou zásadní slabinu, která by umožňovala zneužít znalost šifrovaných a odpovídajících nešifrovaných dat k (snazšímu) získání klíče, zbytečný zápis spousty nul by právě takovou slabinu přímo okatě vystavil.

Je zkrátka v určitém smyslu lepší (pokud nechceme doufat v ideálně-dokonalou implementaci každé šifry) „zašifrovat“ náhodná data z /dev/urandom než samé nuly z /dev/zero. A ještě lepší bude, zejména pak v případě SSD, nezapisovat tam zpočátku vůbec nic.

AES-NI nemají vůbec nic společného s tím, jaký bude výsledek šifrování nul. Šifrovací algoritmus je pořád stejný. Instrukce AES-NI umožňují výrazně (například deseti+násobně) zrychlit implementaci některých výpočtů typických pro šifrování. Nemají ale žádný vliv na to, jak přesně daná šifra funguje a jaký bude její výsledek. Kdyby totéž chroupal procesor bez AES-NI, výsledek by byl stejný, jen by to ukrutně dlouho trvalo.

[Peter Golis]

Myslel HW-RNG, ktorý zvykol byť pribalovaný aj k AES-NI. Ja so ho prvý krát videl v inštrukčnej sade VIA Padlock.

[Petr Fiedler]

Jinak ten benchmark jsem sem taky mohl dát. Takže tady je:

~$ cryptsetup benchmark 
# Testy jsou počítány jen z práce s pamětí (žádné I/O úložiště).
PBKDF2-sha1      3387967 iterací za sekundu pro 256bitový klíč
PBKDF2-sha256    5857966 iterací za sekundu pro 256bitový klíč
PBKDF2-sha512    2526689 iterací za sekundu pro 256bitový klíč
PBKDF2-ripemd160 1216445 iterací za sekundu pro 256bitový klíč
PBKDF2-whirlpool  918192 iterací za sekundu pro 256bitový klíč
argon2i      12 iterací, 1048576 paměti, 4 souběžných vláken (procesorů) pro 256bitový klíč (požadován čas 2000 ms)
argon2id     12 iterací, 1048576 paměti, 4 souběžných vláken (procesorů) pro 256bitový klíč (požadován čas 2000 ms)
#    Algoritmus |      Klíč |       Šifrování |     Dešifrování
        aes-cbc        128b      1563,4 MiB/s      6872,6 MiB/s
    serpent-cbc        128b       151,4 MiB/s      1078,9 MiB/s
    twofish-cbc        128b       298,8 MiB/s       551,6 MiB/s
        aes-cbc        256b      1172,2 MiB/s      5460,9 MiB/s
    serpent-cbc        256b       151,1 MiB/s      1073,4 MiB/s
    twofish-cbc        256b       296,1 MiB/s       548,0 MiB/s
        aes-xts        256b      5406,9 MiB/s      5406,1 MiB/s
    serpent-xts        256b       970,0 MiB/s       956,0 MiB/s
    twofish-xts        256b       512,9 MiB/s       523,7 MiB/s
        aes-xts        512b      4541,8 MiB/s      4494,1 MiB/s
    serpent-xts        512b       965,8 MiB/s       955,6 MiB/s
    twofish-xts        512b       509,7 MiB/s       523,2 MiB/s