SHA256 szöveg állományokra

Security-all

A kérdésem kicsit programozási témájú.

Kapunk naponta 50-100 PDF fájlt és ebből szövegállományokat generálok. Ezeket az állományokat eddig tároltam egy könyvtárban, de most nézem, hogy 20 ezer fájl egy kicsit sok. Ezért arra gondoltam, hogy a fájlokat SHA256SUM segítségével azonosítom és ezt az azonosítót tárolom egy SQLite adatbázisban. Mivel a txt állományok tartalma nem fontos, ezért a tárolásuk sem létfontosságú, a lényeg, ha ugyanolyan PDF-et küldenek ami már volt akkor azt ki tudjam szűrni.

Ez jó megoldás lehet vagy teljesen tévúton járok?

  • 6951 megtekintés

( cherockee v | 2016. 10. 07., p – 13:36 )

Egy kérdés: miért küldhetnek ugyan olyan pdf-et, mint amilyent már kapott a program? (csak próbálom a problémát visszafelé kibontani, valamilyen pdf-to-txt szolgáltatás része?)

Egyébként szerintem jó megoldás.

( mrceeka v | 2016. 10. 07., p – 13:38 )

töröltem, write only voltam.

Üdv,
Marci

A nyers szövegrész a lényeges, mert van hogy bitre azonos a belső, mert a PDF-hez csaptak még egy grafikát is ami nekünk a feldolgozás szempontjából irreleváns. Tehát csak a szövegre kell koncentrálom (csavar, hogy az első 4 sor kivételével, de ez mellékes).

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

( Szenti v | 2016. 10. 07., p – 13:41 )

Tárolhatnád a fájlokat könyvtárakban, például hónapok, vagy napok szerinti aggregációban.

2016-09
2016-10

vagy

2016-09-30
2016-10-10

( mrceeka v | 2016. 10. 07., p – 13:45 )

Vita esetén nem kell tudjátok felmutatni a megkapott .PDF-et, hogy lám, jól dolgoztátok fel a megbízást belőle?
Nincs olyan külső/belső szabályozás vagy törvény, mely értelmében ezeket meg kell őrizni?

Üdv,
Marci

A PDF-eket megőrzöm, csak egy előfeldolgozást kell csinálnom. Ezért konvertálom ugye szövegbe és ebből kinyert infók alapján szétrakom a PDF-et a megfelelő helyre a megfelelő névvel. És még egy mentés van beérkezéskor közvetlenül napi könyvtárba (20161017, stb.). Annyi a kérdés, hogy az SHA256 van annyira megbízható, hogy ez alapján azt mondhassam, hogy igen ilyen még nem volt és letárolom, vagy már volt és akkor nincs dolgom vele.

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Elvileg igen, nagyon-nagyon-...-nagyon kicsit az ütközés esélye... ha biztosra akarsz menni, hogy ütközéskor is helyesen dolgott, csinálhatod azt, hogy valahova ledobálod a text fájlokat (akár óránként külön mappába, mindegy), és symlinkeket csinálsz rájuk a hash nevével, opcionális könyvtárakba dobálva (hash[0:1]/hash[2:3]/hash[4:5]/hash), így az első három szinten lesz 256 (x[0:1] az x string 0. és 1. karaktere, feltételezem a hash-t a 16-os számrendszerbeli megfelelőjével tárolod) mappád egy-egy könyvtárban és szépen szétterítetted őket. Aztán egy PDF beérkezésekor átküldöd a pdf2text-en, kiszámolod a hash-ét, megnézed, hogy létezik-e a megfelelő hash. Ha létezik, összehasonlítod a két fájlt, ha egyezik, a PDF kuka. Ha nem egyezik, találtál egy collissiont, a PDF nem kuka, feldolgozod. Ha nem létezett, létrehozod a symlinket, és küldöd tovább a PDF-et feldolgozásra.

Szerk.: hogy mennyire nagyon-nagyon-nagyon kicsi... igazából simán mondanám, hogy ne foglalkozz vele, de ennél a nagyságrendnél (100/nap) bőven ráérsz összenézni a fájlokat, és akkor garantáltan helyes leszel.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( Crayon | 2016. 10. 07., p – 15:16 )

Nagyjából 2^128 darab (link) fájlból lesz 2 amikre azonos lesz a SHA-256.
Ha még ez ellen is védekezni akarsz, SzBlacky megoldása itt feljebb erre is megoldást nyújt.

Én egyszer régen találtam 2 különböző file-t, aminek ugyanaz volt az md5 hash-e. Szerintem ez ilyen once in a lifetime, és az md5 fele at sha256-nak, szóval kicsi az esély.
Azért én inkább 2 hash-t is csinálnék, ha 2 különböző hash esetén sincs egyezés akkor gyakorlatilag kizárható a false match.

Igaz, azonban +1 szuro a file meret, hogy azonos hash-t keresni eleg az azonos meretuek kozott, ami sokat gyorsithat akar, ha eleg sok az adat.

Masik, hogy nem voltam egyertelmu fentebb:

Sha2-512-t javaslok, nem Sha3-512-t.
Sha3 meg ujabb, es hardveresen gyorsabban hasznalhato/torheto, mint szoftveresen, AES-hez hasonlo, AES tervezoi csinaltak. Bar itt nem fontos a biztonsag, csak az utkozes... :)

Sakk-matt,
KaTT :)

Perl scriptből fogom a checksum generálást végrehajtani a Digest::SHA segítségével. Tehát amit ezt tud, azt én is tudom :-) Lehet akár 4096 is. A keresés meg kurva gyors egy SQLite adatbázisban akár 20 ezer tétel között is. A lényeg, hogy ne legyen ütközés. Egyébként havi kb 500 évi 6000 tételről van szó. A 20 ezer már az eddig összegyűlt tételek az évek során. Év végén nyugodtan takaríthatok is.

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

termeszetesen eleg a sha256 sum, en egy 128bites uuidre is nyugodtan rabiznek barmit, akkor erre miert nem?

Mert ~három sornyi plusz kódról beszélünk (hívsz egy cmp-t, nézed, hogy 0-e az exit code-ja), amivel egy >0 (még ha tényleg retek kicsi is) levihetünk ==0-ra... (az egyszer megírt unit testen kívül meg a soha le nem futó kód enni nem kér)

Egyébként meg folyamatosan feltételezzük, hogy csak véletlen egyezés van, és azért már volt nem egyszer példa arra, hogy azzal a felkiáltással, hogy hány csillió nagyságrenddel nagyobb a függvény állapottere, rendben leszünk (MD4 -< MD5 -< SHA1 -< SHA2)... aztán pár éven belül jött az, hogy ja, most már egy komolyabban ellenérdekelt fél már simán tud ütköző hash-t generálni...
A random UUID és a hash között a különbség az, hogy utóbbit egy másik fél is tudja módosítani, egy jó véletlenszám-forrással készült UUID-et nem.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"A random UUID és a hash között a különbség az, hogy utóbbit egy másik fél is tudja módosítani, egy jó véletlenszám-forrással készült UUID-et nem."

Csakhogy itt a másik fél arról sem tud, hogy készül SHA256 és ha tudná se érdekelné, nem érdeke ütközést létrehozó preparált megbízást készíteni.
Ha meg véletlenül ütközés történne, akkor azt ki kéne vizsgálni, ugyanúgy, mintha az ütközés azonos megbízás kétszeri beküldéséből fakadna.
Aztán lehetne belőle egy jó kis HUP blogposzt, mi meg példálózhatnánk a lottóötössel.

Szóval, nem értem, miért megy a pörgés ezen.

Üdv,
Marci

"en meg egyszer talaltam egy 100ft-ost. ennek ugyanannyi koze van a sha256-hoz, mint a te md5-utkozesednek, erted?"

Értem, persze, de...
Nyilván van valamilyen elhanyagolhatóan kicsi esélye az ütközésnek bármilyen hash esetén, sha256 és md5 esetén is, noha az utóbbinál nagyságrendekkel nagyobb, de még így is bolhafingnyi.
Egy másik ellenőrzést (még egy hash, file méret, whatever) mellé tenni szinte semmibe se kerül, kell még egy field az adatbázisban, és kb. 3-5 plusz kódsor. Megér-e ennyit az, hogy további nagyságrendeket csökkents a false match előfordulási esélyén? Szerintem igen.

Célszerűbb lenne valamilyen statisztikai megoldás, mely észreveszi a minimális eltérést és mondjuk jelezne egy beállítható küszöb érték felett.

A hash lehetne elő - elő szűrő, hogy eldobja a totál egyezőt ha sok van ilyen és így csökkentse a későbbi erőforrás igényesebb statisztikait.

Deduplikálásra nem használnék hasht, mert nem fogja észrevenni, ha két dokumentum pl. csak egy szóközben tér el.

A fuzzy hashek működhetnek rá (ahogy a pl. DCC is hasheli a leveleket, pont, hogy az apró különbségek eltűnjenek).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( Jason v | 2016. 10. 08., szo – 07:21 )

Ugyanolyan pdf-et küldenek, vagy pontosan ugyanazt?

Ha pont ugyanazt, akkor eleg a file-t checksumozni :)

Ha ugyanolyat, akkor mi garantalja, hogy a text resze pontosan ugyanaz lesz?

Ugyanolyan, de nem pontosan ugyanazt. Az első 4 sor mindig változik annak függvényében, hogy ki és mikor küldi. Ezek egy partner által generált PDF-ek. Nincs ráhatásom, nem is kell, mert az első 4 sort lecsapva ugyanaz lesz, ha ugyanazt küldik el többször is.

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!