Potresti essere interessato a leggere ssdeep , un "hash a tratti attivato dal contesto" (CTPH) usato come indipendente dal contenuto forma di hashing sfocato. Ssdeep costruisce gli hash di parti di un file in modo che sia possibile determinare la similarità; diciamo che un personaggio cambia tra due file altrimenti identici. Il checksum delle parti di file modificate sarà diverso, ma i checksum di tutte le altre parti non lo saranno, quindi i file saranno considerati molto simili.
In pratica stai provando a farlo, ma senza l'intenzione di usarlo per misurare la somiglianza dei file.
Ho l'impressione che fino a quando mantieni interi hash (non li tronchi) e i segmenti che hai cancellato sono abbastanza grandi da rendere le collisioni rare (forse 512 byte?), allora avrai un livello sufficiente di integrità dei dati . È teoricamente possibile che tu abbia più integrità poiché hai una lunghezza hash più lunga, ma ci sono così tante aree su cui devi fare particolare attenzione nella tua implementazione che non vorrei assolutamente raccomandare questo.
Detto questo, hai specificato tre hash sha256, incluso uno per l'intero file. Fintanto che stai abbinandoli tutti e tre, questo dovrebbe essere, al suo punto più debole, buono quanto lo sha256 da solo. Probabilmente è ancora più strong, ma tu sarai (probabilmente) più vulnerabile di un singolo sha256 quando si tratterà di vulnerabilità teoriche dello SHA-2, quindi potresti anche fare un altro algoritmo come SHA-3 o anche (dato che hai ancora il file intero sha256) qualcosa più veloce come MD5. Puoi anche considerare di memorizzare la dimensione del byte.
SHA-2 a 256 bit dovrebbe essere sufficiente per qualsiasi cosa, a meno che tu non sia preoccupato per il lontano futuro. Se questo è il caso, non puoi dare nulla per scontato, ma andrei con SHA2-512 e SHA3-512 e la dimensione esatta del file.
Se vuoi solo aumentare la velocità e non preoccuparti di essere attaccato (cioè sei solo preoccupato dell'integrità dei dati da hardware difettoso e / o reti crappy), puoi iniziare con la dimensione del file, quindi calcolare MD5 e SHA1 contemporaneamente (due processi separati, uno letto del file). Non mi verrebbe ancora in mente di tagliare un file a meno che tu non voglia usare ssdeep (che sembra usare MD5 per i suoi pezzi di default).
Forse un interessante equilibrio tra velocità e integrità potrebbe essere quello di controllare la dimensione del file, quindi l'MD5 del primo 5 MB (o l'intero file se inferiore a 5 MB), quindi il vero controllo di integrità, ad es. sha256 o sha3-512. Dovrebbe * essere più difficile creare una collisione e più veloce per rilevare i guasti (fermarsi al primo errore) mentre è solo leggermente più lento dell'ultimo controllo (mi ci sono voluti 0.003 per calcolare l'hash MD5 di un file di test casuale da 5 MB). (* Non sono esperto né nella cryptoanalysis né nei checksum crittografici: non è autorevole.)
Sono tentato di dire che se non si sospetta un attacco, staresti bene con entrambe le dimensioni del file e MD5 (probabilmente starai bene solo con MD5, anche se le dimensioni del file ti permetterebbero di fallire più velocemente < em> e forniscono un'integrità dei dati leggermente migliore).