Byla vydána nová verze 2025.4 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) zveřejnil Národní politiku koordinovaného zveřejňování zranitelností (pdf), jejímž cílem je nejen zvyšování bezpečnosti produktů informačních a komunikačních technologií (ICT), ale také ochrana objevitelů zranitelností před negativními právními dopady. Součástí je rovněž vytvoření „koordinátora pro účely CVD“, jímž je podle nového zákona o kybernetické … více »
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 25.12. Přehled novinek i s náhledy a videi v oficiálním oznámení.
Společnost System76 vydala Pop!_OS 24.04 LTS s desktopovým prostředím COSMIC. Videoukázky na YouTube.
Byla vydána verze 1.92.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Free Software Foundation zveřejnila ocenění Free Software Awards za rok 2024. Oceněni byli Andy Wingo, jeden ze správců GNU Guile, Alx Sa za příspěvky do Gimpu a Govdirectory jako společensky prospěšný projekt.
Bylo vydáno Eclipse IDE 2025-12 aneb Eclipse 4.38. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
U příležitosti oslav osmi let prací na debianím balíčku vyšlo GPXSee 15.6. Nová verze přináší především podporu pro geotagované MP4 soubory, včetně GoPro videí. Kdo nechce čekat, až nová verze dorazí do jeho distribuce, nalezne zdrojové kódy na GitHubu.
Monado, tj. multiplatformní open source implementace standardu OpenXR specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro virtuální realitu (VR) a rozšířenou realitu (AR), bylo vydáno ve verzi 25.1.0. Přehled novinek v poznámkách k vydání.
Byla vydána listopadová aktualizace aneb nová verze 1.107 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.107 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
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
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
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
Jinak ten benchmark jsem sem taky mohl dát. Takže tady je:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
~$ 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:
