Vlákno názorů k článku Jak vytvořit šifrovaný oddíl v Linuxu od marwis - Podstatně rychlejší alternativu k tomuto postupu může představovat...
-
marwis (neregistrovaný)Podstatně rychlejší alternativu k tomuto postupu může představovat vytvoření zašifrovaného oddílu pomocí dm-crypt/LUKS a jeho přepis zařízením /dev/zero (popřípadě užitím badblocks – viz výše). Nejsem kryptolog, abych byl schopen říci, nakolik je tato metoda horší než použití /dev/urandom, ale dle mého názoru by neměla být horší o moc.
Určite vhodnejšie je prepísať disk náhodnými dátami a to niekoľkonásobne. Ak je niekto paranoidný, prepíše 25 krát :). Jedná sa ale o ochranu dát, ktoré sa na oddieli nachádzajú pred zašifrovaním. V prípade, že nám o ochranu týchto dát nejde, možeme z podľadu bezpečnosti kľudne v rámci kontroly disku na chyby použiť /dev/zero. Či je to dostatočné aj pre sponenutú kontrolu chýb, neviem. -
anonymní/dev/zero je blby v tom, ze je pak videt, kde jsou sifrovany data a kde jeste data nejsou, z toho pak treba nekdo usoudi, kolik mate potencialne nelegalnich dat a mozna pak nebude muset desifrovat celej disk, ale jen jeho cast.
jinak kontrola chyb se dela pomoci 0xaa, 0x55, 0xff, 0x00 a nahodnyma cislama, nejlip samozrejme vsema moznostma :) -
fork (neregistrovaný)On nemal na mysli to ze sa pomocou /dev/zero prepise nezasifrovana particia ale ze si najprv vytvorime na tej particii sifrovany disk, ten sifrovany disk namapujeme napr. ako /dev/mapper/docasnydisk a zadame dd if=/dev/zero of=/dev/mapper/docasnydisk. Potom ten docasnydisk odpojime a znova si vytvorime sifrovany oddiel ako keby sme to robili prvykrat.
-
Pokud jste schopen pomocí urandom generovat pseudonáhodná čísla dostatečně rychle (desítky MB/s), pak používejte urandom (mimochodem, kde jste sehnal HW generátor náhodných čísel?). Sám si to můžete "nezávazně" vyzkoušet:
dd if=/dev/urandom of=/dev/null
Naopak, pokud vygenerujete z bídou 3-4MB/s jako já, pak se začnete poohlížet po alternativním řešení, abyste nemusel čekat dny na přípravu zašifrovaného oddílu.
vono stejne zasifrovany /dev/zero bude vytvaret nejakej slozitej ale predse jen periodickej vzorek, ne?
Tak za prvé, pokud si přečtete celou moji formulaci, pak dávám na výběr mezi /dev/zero (což je zrovna ta horší možnost) a programem badblocks (což osobně doporučuji), který generuje sice méně kvalitní pseudonáhodná data, ale generuje je velmi rychle, takže ve spojení s vhodnou šifrou a šifrovacím módem by měl být výstup náhodný dostatečně.
A za druhé, s použitím vhodného šifrovacího módu by vůbec nemělo vadit použití /dev/zero, výstup by měl být navzdory jeho použití taktéž dostatečně náhodný. Ale, jak už jsem uváděl, nejsem krytptolog, abych to dokázal odborně posoudit. Čili, badblocks+dm-crypt/LUKS je podle mého pro zaplnění oddílu náhodnými daty optimální řešení - je dostatečně rychlé a mělo by být i dostatečně "náhodné". Pro příklad v článku jsem právě proto zvolil tuto alternativu.
-
anonymníno HW generator mam u wifi karty Broadcom BCM4318, kdyz se pouzije b43 a rngd, ale rngd vlastne zasobuje /dev/random a ne /dev/urandom, kterej si z toho random vezme jen seed a pak uz se to jen pocita pseudonahodne
urandom mam taky jen 4MB/s, coz je asi limitovany CPU a random 0.3MB/s, coz je zase limitovany tim HW generatorem, bez toho generatoru se random plni jen z mysi a klavesnice a tak a tim padem dost casto ceka a zadny data neposila.
jinak si myslim, ze zasifrovany malo variabilni data (treba samy nuly) budou sice o trochu vice nahodny, ale ne o moc a to muze byt potencialni problem, proto taky v ssh je moznost komprese dat pred sifrovanim, cimz se snizi opakovani a zvysi se variabilita
na disk se zatim komprese pred sifrovanim nepouziva, ne? asi ta komprese je narocnejsi na CPU nez sifrovani
a ten napad naplnit disk sifrovanyma nahodnyma datama s jinym heslem, nez pak bude pouzito, je zajimavej, ale nevidim v tom moc zadnou vyhodu, to radeji pockam prez noc a naplnim to z urandom (160GB disk za 11 hodin zhruba)
jedine me napada naschval pouzit lehky heslo (myslim ve fazi mazani disku, potom samozrejme ne), lehkou sifru a naplnit disk nejakyma balastnima souborama, treba nejakyma videama, pak je mozny, ze se utocnikovi podari rozlousknout tu slabsi sifru a dostane se akorat k tomu balastu. ale asi taky zalezi, jak ten disk bude potom plnej uzitecnyma datama.... -
na disk se zatim komprese pred sifrovanim nepouziva, ne? asi ta komprese je narocnejsi na CPU nez sifrovani
Nepoužívá. Proto u diskového šifrování (a nejen tam, když už jsme u toho) hodně záleží na šifrovacím módu.
a ten napad naplnit disk sifrovanyma nahodnyma datama s jinym heslem, nez pak bude pouzito, je zajimavej, ale nevidim v tom moc zadnou vyhodu
"Jen" mnohonásobně vyšší rychlost oproti urandom. A podle mého názoru, výstup by měl být srovnatelně bezpečný s urandom.
