Imho. lidi nekradou notebook ani tak kvuli datum, jako notebooku samotnemu - takze zasifrovanou partionu proste preinstaluji svymi okynky... leda jim znemoznit to :)
to , ze mu to znemoznis ma prinos iba v tom, ze ho naseres, a ty budes mat lepsi pocit.ale ak ho iba zakryptujes (v tom zmysel vidim) bo fakt nechcem, aby si moje data pozeral niekto iny ako ja.je to ale samozrejme vec nazoru, a do znacnej miery tu hraje ulohu aj charakter majitela ;)
Moderni inteligentni notebooky, pokud jsou chraneny heslem v BIOSU, a kryptuji zavadeci sektor HDD je pro i zkuseneho lamera veliky problem obejit. Zrovna jsme tohle resili v praci. Byl tam notas od DELLu a ani zaboha jsme se do nej nedostali a to jsme ho i kompletne rozebrali (v nadeji ze najdeme nejaky tem jumprik), hledali jsme na netu ruzne navody a nic (byl to legalne zakoupeny notebook). Dale bych rad rekl, ze po navsteve kryptofestu a shlednuti prednasky od prednich ceskych kryptologu, na tema postrani kanaly jsem dospel k zaveru, ze temer az asi na jednu neexistuje nezlomitelna sifra. For je v tom, ze pokud USA pusti nejakou tu sifru za hranice, tak stoprocentne maji nejaky backdoor na jeji zlomeni a to plati urcite i o EU.
Dobrý článek. Ale nemám rád MD5, rozhodně bych se snažil použít SHA-1 (nebo delší) :-)).
Já osobně bych se u zašifrovaného disku bál ztráty dat (havárie toho USB s klíčem, havárie mozku s heslem). Chce to pořádně zálohovat (i ty klíče).
Když jsem se díval na to šílené patchování zdrojáků, tak jsem si vzpomněl, že na W2K s NTFS stačí zaškrtnout jedno políčko a daný adresář se šifruje. Cryptoroot bude asi bezpečnější, ale ne po každém jdou agenti NSA, že:-)
Pro hasovani hesel se v loop-AES pouziva SHA - _sila_ hasovaci funkce pak zavisi na zvolene sile sifry AES. Takze napriklad, pokud pouzijete AES256, tak se heslo bude hasovat SHA-512. Vice v pristim dile;-)
Tak to je potom škoda, že tam ta SHA-xx v tom assembleru není, ne? Ale ono to bude asi putna, nějaká velká data by přes ni téct neměla.
Take jsem koukal, jestli to neni nahodou nejaky preklep v manualu, ale zjevne neni.
Kryptovat NTFS je k smichu. Ale novy Longhorn, jak jsem zatim cetl by mel kryptovat i mys a datovy tok klavesnice, kvuly EM poly, ktere vyzaruji, ale stejne tomu neverim.
skusal autor pozriet aj DMCrypt? Pretoze Cryptoloop bude coskoro umriet (bohvie ci ho est 2.6.8 bude podporovat..)
inac pekny clanok, ja pouzivam BestCrypt, neni to sice gnu vec, ale ma to pekne featury (napr. ze bestcrypt kontainer ide namountovat aj pod windowsom, fake obsah kontajnera pre pripad nutnosti vyzradenia hesla atd)
co sa tyka straty dat pri chybe media (trebars badblock a podobne) tak u bestcryptu vypadne len poskodeny blok dat, nie cely kontajner
Pozriet jsem ho neskusal, ale vim o nem:-) Takze se rad neco dozvim - napr. jestli teda neni problem vytvorit cryptoroot pomoci DMCryptu s GPG klicem na tokenu?
BestCrypt jsem pouzival kdysi na Windowsech - ovsem nevim, jestli je to pouze shoda nazvu.
dm-crypt ma lepsi design nez Cryptoloop. Nicmene i tak by mel byt loopAES lepsi volbou, jelikoz je bezpecnejsi,tedy presneji v multikey modu:) dm-crypt trpi stejnymi problemy jako cryptoloop(tzn. jako IV pouziva cislo sektoru, je nachylna na watermark,etc.)
Jak budou pri navrhovanem postupu resena residualni data ve swapu? dd? :-)
Obvykle se to dela tak, ze se pri kazdem bootu konfiguruje swap s jednorazovym klicem (treba par bajtu z /dev/random), mkswap-ne a pripoji. Klic je pokazde jiny, ale to nevadi, protoze data ve swapu jsou platna jen v dobe behu systemu.
(samozrejme pokud neuvazujeme o sw-suspendu).
Drobna terminologicka poznamka:
> Prakticky známe dvě implementace cryptoloop, a to
> CryptoAPI a loop-AES.
Jedinym ukolem CryptoAPI je poskytovat zbytku kernelu pres standardni interface pristup k ruznym kryptografickym algoritmum. Takze CryptoAPI neimplementuje ani IPsec ani cryptoloop, ale jen poskytuje potrebne "zazemi".
Vyhodou tohoto pristupu je moznost pridat optimalizovanou (=rychlejsi) verzi nejakeho algoritmu a razem ji bude moci vyuzivat cely kernel. To se v posledni dobe stalo s aes-i586 (ma sice ponekud bourlivou historii, nicmene ve 2.6.8 snad v nejake podobe bude).
Dal bych si dovolil s autorem polemizovat ohledne volby loop-AES misto dm-crypt. Pomoci dm-crypt je mozne zasifrovat celou partition, cimz odpadne rezie spojena s umistenim filesystemu v loopback souboru na hostitelskem filesystemu. A krome toho je to standardni soucast 2.6 jader, takze neni potreba nic patchovat ;-)
Co se tyce CryptoAPI, tak mate pravdu. CryptoAPI vlastne zpristupnuje sifrovaci fce, ktere jiz v jadru jsou.
Co se tyce dm-crypt vs. loop-AES ... ja vybiral mezi CryptoAPI a loop-AES:-) Zkusim na to mrknout a mozna se to objevi v jednom z pristich clanku - jestli to ovsem nekdo neprozkouma za me;-)
Naprosty souhlas, neni potreba nic patchovat a staci defacto tri prikazy
pripojeni svazku (ci celho disku) pres kryptovany loop
vytvoreni filesystemu na danem loopu
pripojeni loopu :)
No de facto, timhle zpusobem se kernel taky nepatchuje.
To je sice pravda, ale je tu jistý problém v tom,
že onen jaderný modul 'loop.ko' se musí s každým novým kernelem kompilovat extra, a potažmo se tedy musí při upgradu kernelu pamatovat na rekompilaci loop-AES.
To nepovažuji za moc dobré.
Možná opravdu bude stát za to ještě vyzkoušet ten DM-crypt [s novějším jádrem]. :)
zadna rezie s umistenim loopback souboru na hostitelskem filesystemu se nekona, protoze losetup mohu pouzit i na blokove zarizeni.
Tož jsem takový zmatený. Asi tenhle dotaz bude Slackwaristům proti srsti, ale: Nebyl by nějaký klikací nástroj?
Díky, koffr
BURN!!!!
:) o zadnem klikacim nastroji nevim, max pod windows je ten klikaci bestcrypt
Mno jo, no. Tak to asi budu muset udělat podle tohoto návodu. Nic proti, ale přeci jen klikání je klikání :-/
a navyse: klik, klik (autoconfigure), klik, ... application error - we are loosing all data - OK? :) KLIK (turn off)
Když pojedeš podle návodu, nebo jiných článků
na webu tak budeš problematice rozumět určitě
víc, než když se proklikáš tunami tlačítek.
nj, ale ono to zas neni taky tak ruzovy - ja to z tohodle clanku taky moc nechapu (a to uz sem si neco zjistoval driv), pze je to navod... mozno misto toho zduvodnovat "proc" sifrovat (v uvodu clanku) mohl vyzvetlit jak to vlastne cely funguje (loop device, proc musi bejt podpora sifrovani primo v jadre atd) a pak by clovek jenom neopisoval pro nej nepochopitelny prikazy ...
-tohle neni mineno jako flamewar a je mi jasny, ze si kazdej muze patricny informace doplnit sam, jenom spis konstruktivni pripominka pro priste :)
jinak navod podrobnej a jestli funguje, tak no problem
Prijimam kritiku na svoji hlavu;-) Mozna to bude jasnejsi z pristiho dilu.
Robil som pokusy s cryptoloop a dm-crypto so sifrou AES na jadre 2.6. Pomocou dm-crypto mi citalo z disku asi 15MB/s a cryptoloop asi 10MB/s (Athlon XP2400+)& 1GB RAM, loop-AES som neskusal. Teraz mam komplet zakryptovany disk pomocou dm-crypto, teda / /home aj swap. Odkryptovana je len 20MB /boot kde je jadro a initrd. Na vykone to velmi nepoznat, iba pri kopirovani velkych suborov. Vacsinou to spomaluje pristupva doba disku. Robil niekto pokusy s vykonom loop-AES na podobnom stroji alebo to porovnaval s ostatnymi sposobmi?
No prave v pristim dile se dozvite, ze jsem zadne performance testy nedelal:-) Duvod je takovy, ze to nepotrebuji (rozdil oproti puvodnimu stavu bez sifrovaneho / jsem nezaznamenal) a ani nemam poradne s cim srovnavat. Palit pres to take nebudu, ale zrovna to by to melo urcite stihat fpoho.
no, linux je pomaly tak ako tak. asi si si uz zvykol ;-)
je to strasne zlozite, pochybujem ze ja, ako nelinuxak, by som to zvladol nastavit skor ako za mesiac
Zdravim, pise se tu o DMcryptu, LoopAESu a dalsich, ale je zde nekdo objektivne schopen doporucit nejrozumnejsi variantu sifrovani filesystemu? Kuprikladu kdyz mi nebude vadit zpomaleni cteni z disku, budu preferovat (relativni) "nezlomitelnost" sifry a budu preferovat sifrovaci system, ktery je pokud mozno co nejkompatibilnejsi s novymi Kernely (2.6.8 atd)? Diky za doporuceni predem.
ČLÁNKY DO MAILU