Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Společnost Kaspersky vydala svůj bezplatný Virus Removal Tool (KVRT) také pro Linux.
Grafický editor dokumentů LyX, založený na TeXu, byl vydán ve verzi 2.4.0 shrnující změny za šest let vývoje. Novinky zahrnují podporu Unicode jako výchozí, export do ePub či DocBook 5 a velké množství vylepšení uživatelského rozhraní a prvků editoru samotného (např. rovnic, tabulek, citací).
Byla vydána (𝕏) nová verze 7.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
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. |
cryptsetup --cipher aes-xts-plain64 --hash sha512 --key-size 512 --pbkdf argon2id --type luks2 --use-urandom --verify-passphrase luksFormat /dev/sdXYZdar Max
Díky za odkaz.
Díky za příkaz. Proč --use-urandom
?
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 discard
u, 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ě.
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.
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.
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: