Adattitkosítási funkcióval bővül a ZFS

Fájlrendszer, NAS, storage

A hírek szerint hét évvel azután, hogy fejlesztők elkezdtek dolgozni a ZFS-en, a fájlrendszer végül adattitkosítást lehetővé tevő funkciókkal egészül(het) ki. A crypto funkció valószínűleg fellelhető lesz már a Solaris Express következő kiadásában. További részletek itt és itt.

( c4nn1b4l | 2010. 10. 06., sze – 11:26 )

geli mellett ez nem annyira hianyzik.

( numen v | 2010. 10. 06., sze – 12:14 )

félig off: egy titkosított partíció mennyi plusz terhelést jelent?
van valakinek tapasztalata, hogy egy efféle technológia használata esetén mennyivel lassul a gép, illetve mennyivel rövidül laptop esetében az akkuidő? 

int getRandomNumber() { // ←ez itt már az aláírásom
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

ühhüm, köszi, ez szomorkás ☺
Alapvetően az érdekelt volna, hogy létezik-e olyan titkosítás, ami viszonylag kis overheaddel biztosít elfogadható biztonságot (leszámítva, hogy a terhelés csökkenésével egyszerűsíti a brute force-t…). Elfogadhatónak tartok mondjuk egy 20%-os csökkenést CPU és I/O sebességben, valamint akkuidő-csökkenésben, de úgy tűnik, hogy erre a transzparens rot128-on kívül nincs túl sok lehetőség ☺

int getRandomNumber() { // ←ez itt már az aláírásom
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

megint előjön a kérdés, hogy ki ellenében akarunk titkosítani. én csak lopás ellen, az állam felé nincsenek titkaim ;)

persze a hardveres megoldásnál nincsenek szoftver frissítések sem. ha +/- viszonylatban nézem a hdd teljes szoftveres titkosítását, akkor a terhelés miatt negatív számomra, meg ugye használat alatt folyamatosan nyitva van. ezért én pl. csak 1 db encfs mappát és 1 db gpg fájlt használok, melyek csak alkalmanként kerülnek feloldásra. nekem ennyi elég lopás ellen.

megint előjön a kérdés, hogy ki ellenében akarunk titkosítani. én csak lopás ellen

Ez esetben nem feltétlenül van szükséged titkosításra se, lehet hogy elég egy ATA Security Mode által nyújtott jelszavas védelem is.

az állam felé nincsenek titkaim ;)

Bátor kijelentés... :)

Ühhüm, és gondolom ha titkosítást végző libet használok, akkor jó eséllyel használom ezen funkciókat – magyarul a szálban említett eredmények valószínűleg ezen funkciók használata mellett készültek.
Zrubi emlegette, hogy nem túl észrevehető az overhead, c4nn1b4l linkje nem sok jót ígér viszont – FreeBSD esetében is használják ezeket? Sejtem, hogy rtfs jelllegű kérdés, de hátha valaki már readelte a source-ot ☺ 

int getRandomNumber() { // ←ez itt már az aláírásom
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

A cikkben említett megoldással ugyan nincs, de Linux +dm-crypt +sw raid +ext3 felállással van. Ez a megoldás a céges laptopjainkon alapvető követelmény, de még 'házilagos' storage megoldásnál is használtuk. Nagyobb, folyamatos írási műveleteknél észrevehető, ám szvsz teljesen elfogadható teljesítményt nyújt mint desktopon, mint pedig storage-ként.

( 4fonya | 2010. 10. 09., szo – 11:24 )

Elég stabil már a zfs ahhoz hogy ezzel is ráérnek foglalkozni?