ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverAjánlott böngésző Linux Weekly NewsFreeBSD Project NewsOpenBSD Journal |
Adattitkosítási funkcióval bővül a ZFSA 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.
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzésekHUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekLegfrissebb HUP dokumentumokSzavazásMit tudsz a B-tree struktúráról? Részletekbe menően ismerem a felépítését, funkcióját, határait és felhasználását. 10% Kevésbé ismerem, mint az első pontban, de hozzá tudok szólni a témához. 18% Használom, de nem ismerem minden részletét. 4% Hallottam már róla, minimális mértékben ismerem. 27% Egyáltalán nem ismerem. 34% Csak az eredmény érdekel. 8% Összes szavazat: 556
Új felhasználók
InformációKövess minket!Partnerünk |
geli mellett ez nem annyira hianyzik.
+1
--
1 leszel vagy 0 élő vagy hulla!
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ű. xkcda titkosítás és a feloldása miatt sokkal többet teker a cpu, ez tény, tehát szerintem az akksi üzemidejét jócskán befolyásolhatja.
egyébként meg ott van a plusz titkosító réteg is, amely magába a modulba ágyazva biztos hatékonyabb lehet (gondolom).
Szerintem mindennapi használtban mindenképp észrevehető a különbség. Kivétel ha kis I/O terheléssel használod persze...
Újabb procikkal lehet, hogy transzparensebb élmény:
http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-aes-instructions-set/
Ez sok tenyezotol fugg(mit, mivel es hogyan), de altalanossagban elmondhato, hogy sokkal.
ü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ű. xkcdAz újabb Intel procikban már van az AES gyorsításához szükséges utasításkészlet.
És ezeket a Linux vajh képes kezelni?
Én is abban bíztam egyébként, hogy van valami hardwired megoldás, amivel gyorsan és kis fogyasztással lehet titkosítani, de a fenti megszólalások némiképp kételyekkel töltenek el.
merevlemez hardveres titkosítása? nekem a notim gyári hdd-je támogatja pl. vagy venni is tudsz akár ha nagyon fontos.
A kérdés már csak az, hogy megbízol-e benne, hogy valóban titkosítja az adatokat és olyan eljárással, amelyik nem visszafejthető... :)
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... :)
Jah,
arch/x86/crypto/aesni-intel_*alatt van a hozzá szükséges kód.Ü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ű. xkcdFreeBSD fejlesztői ágban ott van már a
sys/crypto/aesni/alatt a kód, de nem tudom hogy a merge megtörtént-e a -stable-be.A paper alapján azért a T3-asban lévő kicsit többet tud, meg lehet, hogy gyorsabb is...
suckIT szopás minden nap! Solaris: a legeslegfaszább OS
félig off: egy titkosított partíció mennyi plusz terhelést jelent?
Hát, ez attól is függ, hogy milyen CPU-d van... :)
Pl. ezzel:
http://blogs.sun.com/BestPerf/entry/20100920_sparc_t3_pk11rsaperf
nem hiszem, hogy észrevehető. :P
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.
Elég stabil már a zfs ahhoz hogy ezzel is ráérnek foglalkozni?
… vagy lehet párhuzamosan csinálni, és benne voltak a tervekben. Ha ilyenkor el lehet kezdeni, miért ne…?
int getRandomNumber() { // ←ez itt már az aláírásom return 4;//szabályos kockadobással választva. } //garantáltan véletlenszerű. xkcdEz is egy elfogadható álláspont, csak én arra gondoltam hogy ha az alap nem stabil akkor egy továbbfejlesztése - nagy valószínűséggel - újabb hibákkal terheli és ezzel megnehezíti a javításokat.