A feladat: olyan kis "adatbázis" (inkább csak tárhely) készítése, amihez csak hozzáfűzni lehet adatokat (fájlokat), az azonosító (amivel később vissza lehet kérni az adatot) szekvenciálisan nő.
Az egy dolog, hogy a fájlokat (esetleg) titkosítom; de azt is meg kellene oldani, hogy (észrevétlenül) ne lehessen módosítani az adatbázisban (ami egy fájl).
Eddig elképzelés: minden adat hozzáfűzés után hozzáfűzök egy hash-t is,
a) a teljes előtte lévő állomány hash-et (gond: adatbázis megnyitásakor ezt elő kell tudni állítani (nem tudom, hogy mondjam meg a hash motornak, hogy éppen ebből az állapotból induljon) végig kell olvasnom a teljes állományt - ami több giga is lehet (elvileg)
b) a hasht mindig csak az előző hash-ből és az azóta írt adatokból képzem, így "láncot" kapok - kérdés, hogy ez elég védelem-e?
Másik kérdés: úgy tudom, a "salted" hash-nek van csak értelme (tehát vmi kulccsal inicializáljuk a hash engine-t minden hash-elés előtt) - de hol tároljam ezt a bizonyos "sót"? Mennyire érzékeny adat?
Kösz, GT
- 1265 megtekintés
Hozzászólások
Szerintem a b.) resznel emlitettek eleg vedelmet jelentenek, arra kell figyelni, hogy a hash valahogy "atfogja" az egesz file-t, es ne az legyen, hogy diszkret adat-hash blokkokat teszel a fileba, mert akkor a blokkokat lehet cserelgetni eszrevetlenul, ami kellemetlen lehet. Egy lehetseges megoldasa lehet a problemanak, hogy a hashelendo adatokhoz mindig hozzaveszed az elozo blokk hash-et (viszont igy nem tudod csak az utolso modositast ellenorizni, hanem ellenorzeskor mindig vegig kell menni az egesz file-on), vagy csinalsz a kulonbozo blokkokrol kulon hash-t, es a vegen ezeket osszefuzod, es az igy kapott sorozatrol csinalsz meg egy hash-t (ekkor pedig 2-szer kell hash-elni, es ha ala is akarod irni (nem art, lasd kesobb), 2-szer kell RSA/DSA/ilyesmi-t szamolni is, ami nem kimondottan gyors).
Fontos megjegyeznem (ha felreertettem valamit, akkor elnezest kerek), hogy a hash-eles maga nem ved semmi ellen, ha az adattal egyutt tarolod, azt meg digitalisan ala kell irni, managelni ugyesen a publikus/privat kulcsokat, stb.
Salt-elni itt nem erdemes, azt jelszavak tarolasanal szoktak hasznalni annak megnehezitesere, hogy a szotaron egyszer vegig menve az osszes user jelszavat egy menetben feltorjek (salt-elve kulon kell az osszes juzernel vegigprobalni). Egyebkent a salt nem szokott erzekeny adat lenni.
-
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni