kdyz uz jsme u te bezpecnosti, tak proc radeji nepouziovat skutecne bezpecnou, troufam si rici platformu, Trustix, OpenBSD je mozna relativne dost bezpecne jako OS, ale nektere tradicne derave sluzby na nem...
Zajimalo by mne, jak subjektivne vnimate zpomaleni disku. Ten muj na notebooku ma 4500 otacek, takze bych nerad se zvysenim bezpecnosti ztratil nervy. A co zatez CPU? Precijen, kdyz se funguje z baterii, je to dulezite. Ale jinak - at zije paranoia :-))
Zpomaleni nevnimam prakticky vubec. Pri _bezne_ praci to nepoznate. Co se tyce CPU, tak asi nejake zatizeni navic urcite bude, ale zase to bude minimalni - kdyz tak koukam na gkrellm a top:-)
a jestli nevite jak NEOMEZIT delku hesla na uz
nainstalovanem systemu (Suse 9.1)?
Uz nejakou dobu po tom patram protoze na nove
nainstalovanem linuxu nemuzu kvuli "nedostatecne"
delce hesla cist moje data z jineho, starsiho
linuxu (RedHat 7.3).
Zminku o tom naleznete trebas v http://linuxfromscratch.org/~devine/erfs-howto.html v sekci "Installing util-linux-2.12a". Takze vas problem mozna vyresi preinstalovani util-linux s patricnym flagem.
Pouzivam cryptoloop s aes (kernelovske, nikoliv loop-aes) - a system o "vykonu" 790 bogomips je schopen
+- dekcryptovat (cist xor zapisovat) 3MB/sec dat
Bez cryptoloopu jsem byl schopen cist xor zapisovat asi 15MB/sec ...
Dobre je mit hodne ramky... to si to linux, pokud nestiha cryptovat pri zapisu, hezky kesuje :) a pak to dopise :)
Jak si uvedl,
tak kryptovani/dekryptovani jede 3MB/s. Vykon dnesnich disku je vetsi jak 15MB/s pri cteni/zapisu (to jsi taky uvedl), z cehoz jasne vyplyva, ze nenastane situace, ze by disk nestihal zapisovat, a tim padem by se data nehromadili v cachi. Hlavnim problemem je rychlost procesoru, ktery nestiha (de)sifrovat data rychlosti vetsi nez 3MB/s.
Reseni jsou tedy dve:
1) velka ramka (tve reseni)
2) nebo aspon 4x rychlejsi procak
(3MB/s x 4 = 12MB/s coz je vetsi nez teor. rychlost prenosu po LAN)
peace...
ted jeste vyzkouset jestli se zvysujicim vykonem procesoru primo umerne roste rychlost (de)sifrovani...
128 mi pro "rychly zapis" prijde malo.. Ja jsem ramku dimenzoval tak abych mohl uploudnout cele cedecke "plnou rychlosti" ethernetnu ... tedy mam tam 1GB ram.. To uz se da pak neco nahrat na server. Problem je se ctenim.. to se sice kesuje take.. ale jen po te co to bylo jednou precteno.. takze takovy efekt to neni, jako s tim zapisem
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.
Mno, je rozdil mezi implementaci samotneho sifrovaneho filesystemu a samotnou sifrou. Co se tyce sifry, tak by na tom papirove i prakticky mela byt nejlepe AES (Rijndael). Co se tyce softu, kterym budeme realizovat sifrovani filesystemu, zrejme cryptoloop pomalu umre a nahradi ho _modernejsi_ dm-crypt. Ale pokud se bavime o jadrech <=2.6, tak dobre vyuzijeme loop-AES ci CryptoAPI.
