I checksum nei formati di file sono obsoleti?

L'altra cosa che non hai considerato è che i file in genere non esistono solo sul disco:

• Sono copiati su reti in vari modi e in varie circostanze.
• Sono copiati da un supporto di memorizzazione a un altro o persino all'interno di un supporto.

Ogni volta che un file viene copiato, i bit potrebbero essere corrotti ...

Ora alcune di queste rappresentazioni o schemi di spostamento dei dati hanno (o possono avere) meccanismi per rilevare la corruzione. Ma questo non si applica a tutti e qualcuno che riceve un file non può sapere se i precedenti schemi di archiviazione / movimento che hanno toccato il file eseguono il rilevamento degli errori.

Pertanto, se il contenuto del file garantisce il rilevamento degli errori, incluso il rilevamento degli errori come parte del formato del file, è una cosa ragionevole da fare. (In effetti, se non lo fai, dovresti usare una sorta di meccanismo di checksum esterno , indipendente dal rilevamento degli errori del file system, eccetera.)

(Poi c'è il problema che si potrebbe desiderare / bisogno di rilevare manipolazioni intenzionali di file. Per questo è necessario qualcosa di più dei semplici checksum. Hai bisogno di qualcosa come le firme digitali.)

TL; DR - i checksum nei formati di file non sono ridondanti.

I checksum migliorano la qualità dei dati su base statistica. Quindi dipende dal fattore di sicurezza di cui hai bisogno per i tuoi dati. Non puoi mai raggiungere il 100% dal momento che ogni somma di controllo può alterare (anche se molto improbabile) in un modo con i dati che sarà sicuro. C'è solo una regola che più i tuoi dati devono essere protetti, più devi aggiungere un overhead algoritmico. È una funzione sigmoide dove a destra si aumenta lo sforzo algoritmico, ma non si raggiunge mai la sicurezza al 100%.

(N.B Non so mai quando è la sicurezza o la sicurezza, ma probabilmente indovina cosa intendo.)

Risposta rielaborata dopo la discussione nei commenti

Checksum nei formati di file

Il checksum in un formato file ha uno scopo diverso rispetto ai checksum nel file system. Mira a verificare l'integrità dei dati a livello di applicazione . Può rilevare:

• corruzione accidentale del contenuto (ad es. capovolgimenti accidentali di bit nelle operazioni di I / O su file, sul dispositivo di archiviazione o durante il trasferimento di rete quando il file è stato trasferito)
• potenziali incongruenze (ad esempio il file è stato modificato manualmente o modificato senza una sufficiente conoscenza della sua struttura)
• corruzione intenzionale e frode (ad esempio, i formati bancari prevedono checksum più complessi, rendono più difficile l'hacking fraudolento nelle modifiche manuali).

I checksum non garantiscono l'autenticità dei dati (per questo ci sono le firme digitali), ma riducono il rischio di alterare i dati delle applicazioni.

Checksum nei file system

In una scala molto ampia (ad es. datacenter), la corruzione accidentale non è una domanda se succede, ma quando succede:

• Nel 2013 il disco rigido aveva una frequenza di errore di 1 bit ogni 10 ^ 16 bit letti / scritti. Allo stesso modo, la RAM ha un errore non corretto ogni 10 ^ 14 bit.
• Il danneggiamento dei dati silenziosi può anche verificarsi a causa di radiazioni cosmiche che colpiscono i chip, onde elettromagnetiche che interferiscono con la trasmissione del segnale e altri fenomeni fisici esterni.

Questo spiega la logica per i checksum nei filesystem:

• proteggere i dati a livello di archiviazione dalla corruzione accidentale, indipendentemente dal formato del contenuto:

  As an example, ZFS creator Jeff Bonwick stated that the fast database at Greenplum, which is a database software company specializing in large-scale data warehousing and analytics, faces silent corruption every 15 minutes
  Wikipedia article (link above)

• proteggere i metadati del file system dalla corruzione accidentale (o tentativi di manomissione), perché la perdita di informazioni critiche, come i riferimenti a i-nodes o altri, potrebbe avere un effetto ancora più drammatico sui dati in singoli file (ad esempio perdita istantanea di migliaia di file)

  Some file systems, such as Btrfs, HAMMER, ReFS, and ZFS, use internal data and metadata checksumming to detect silent data corruption. In addition, if a corruption is detected and the file system uses integrated RAID mechanisms that provide data redundancy, such file systems can also reconstruct corrupted data in a transparent way.
  Wikipedia article (link above)

Protezione multistrato

La protezione fisica nel livello hardware (ECC, CRC, RAID ...), il checksum del filesystem o del protocollo di rete nei livelli di sistema e il checksum del contenuto incorporato nel livello dell'applicazione si completano a vicenda e ciascuno protegge da diversi fenomeni (ad esempio un checksum del filesystem non protegge da una scrittura intenzionale).