Portál AbcLinuxu, 30. dubna 2024 01:59
27.12.2021 03:13
Petr Fiedler | skóre: 35
| blog: Poradna
| Brno
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á.
Řešení dotazu:
| 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. |
27.12.2021 12:54
Max | skóre: 72
| blog: Max_Devaine
cryptsetup --cipher aes-xts-plain64 --hash sha512 --key-size 512 --pbkdf argon2id --type luks2 --use-urandom --verify-passphrase luksFormat /dev/sdXYZdar Max
27.12.2021 19:42
Petr Fiedler | skóre: 35
| blog: Poradna
| Brno
Díky za odkaz.
Díky za příkaz. Proč --use-urandom ?
28.12.2021 00:57
Max | skóre: 72
| blog: Max_Devaine
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ě.
27.12.2021 19:54
Petr Fiedler | skóre: 35
| blog: Poradna
| Brno
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/urandommí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.
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/urandommí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.
27.12.2021 20:08
Petr Fiedler | skóre: 35
| blog: Poradna
| Brno
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
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.