Come spostare/salvare i vostri dati con la certezza di non perdere nemmeno un bit (1 di 2)

La cosa che più preoccupa quando si tratta di muovere di frequente grandi quantità di dati da una partizione all'altra è che il sisetema operativo o il filesystem sbaglino a copiare un bit da qualche parte, eventualità nemmeno troppo remota considerando che un singolo file può essere composto da miliardi di bit!



NOTA:Questo è il primo di due articoli sull'argomento; qui cerco di dare una spiegazione più dettagliata, per quelle che sono le mie capacità, di cosa stiamo facendo, mentre nel secondo passerò alla parte pratica. La lettura di questa prima parte, sebbene caldamente consigliata, non è necessaria alla comprensione del secondo articolo.

Se i dati sono particolarmente importanti una (anzi parecchie) copie di backup sono un obbligo!
Questa soluzione, però, non è sempre sufficiente e ve lo dimostro subito con un esempio pratico:

abbiamo un archivio fotografico digitale con migliaia di scatti di cui facciamo periodicamente il backup su un sistema dotato di raid mirror (più una copia su disco esterno, perchè la sfiga ci vede benissimo!). Succede però che lo spazio per le copie di backup finisca, la soluzione più ovvia (che non sia semplicemente comperare hard disk aggiuntivi) è quindi cancellare i backup più vecchi per far posto ai nuovi, giusto? NI e vi spiego perchè: mentre in altri ambiti i file sono usati con cadenza giornaliera e servono per un intervallo limitato di tempo, quando si archiviano fotografie (ma potrebbero essere anche altri tipi di documenti particolari) non volete avere una data di scadenza, ma non potete nemmeno pensare di ricontrollare uno ad uno tutti i vostri scatti passati prima di cancellare i backup più datati.

Come la manna dal cielo, arriva in nostro aiuto uno dei tool a mio avviso più utili di tutto il panorama informatico: gli algoritmi di hash

COSA SONO?

Gli algoritmi di hash sono delle particolari funzioni che prendono in input una stringa di lunghezza arbitraria (come ad esempio un file) e ne restituiscono una di lunghezza fissa detta digest.
Hanno inoltre due particolarità: (1)deve essere difficile, partendo dal digest ottenere la stringa di partenza (peculiarità utile in crittografia che a noi interessa solo marginalmente) e (2)il digest deve essere, per quanto possibile, univoco per uno e un solo input in modo da rappresentarne una sorta di impronta digitale digitale (la ripetizione non è un refuso :D ). Vedremo come questa seconda proprietà è quella che ci interessa maggiormente.

SONO SICURI?

Esiste una enorme quantità di algoritmi di hash, dai più semplici come il crc32 ai più sicuri come il sha512, tutti con le loro peculiarità. Più si sale con la sicurezza e più potenza e tempo di calcolo sono richiesti per computare i digest. Chiavi troppo semplici si traducono in crittografia in sistemi deboli, nel nostro caso in una elevata probabilità di incappare in una collisione.

COLLISIONE, MA SE NON HO NEMMENO L'AUTO...

Per chiarire le idee su questo punto occorre capire un po' come funzionano questi algoritmi; immaginiamo che il nostro algoritmo sia estremamente semplice e che agisca sui familiari numeri in base 10 (il concetto, per input diversi, non cambia).
Sceglieremo in particolare quella funzione che genera un digest di due cifre che sono proprio le ultime due cifre di un numero di lunghezza arbitraria.
Immaginiamo ora di processare una lista di numeri con il nostro algoritmo, ad esempio: 2, 15, 37, 147, 415, 12698, 3137.
I digest saranno quindi: 02, 15, 37, 47, 15, 98, 37

Avete notato il problema? Proprio così, a input diversi corrisponde lo stesso digest e quindi non possiamo affermare che, per quei numeri, il nostro algoritmo generi "impronte digitali" soddisfacenti. Ci troviamo di fronte a delle collisioni ovvero varie stringhe con il medesimo digest.

E A NOI, CHE CE FREGA?

L'idea è che se io genero il digest di un file, poi questo file si corrompe e genero nuovamente il digest, i due digest saranno diversi e quindi sarò in grado di isolare i file rovinati e ripristinarli tempestivamente con le copie i backup! Noi non ci preoccupiamo quindi che due file possano produrre il medesimo digest (improbabile, ma non impossibile) quello che ci interessa è che la probabilità che un file si corrompa e che gli errori siano tanti e tali da generare un nuovo file con il medesimo digest sia praticamente nulla. E con praticamente nulla intendo dell'ordine di 1/2^512 per gli algoritmi più sicuri e dell'ordine di 1/2^63 per l'algoritmo che useremo noi, probabilità paragonabile con quella che avete lanciando una pallina su un muro di ritrovarvi la pallina dall'altra parte del muro per effetto tunnel, non male vero?!

OK, MA PERCHE' NON USIAMO L'ALGORITMO PIU' SICURO?

Purtroppo questi algoritmi sono letteralmente affamati in termini di potenza di calcolo, sono quindi ottimi se dobbiamo verificare una sola stringa come una password, ma non sono assolutamente raccomandabili per processare decine di migliaia di file. Noi useremo l'algoritmo SHA1 che è un buon compromesso avendo una discreta velocità e un ottimo grado di sicurezza!
Tra l'altro questo algoritmo è anche il primo di quelli per cui un attacco intenzionale a un nostro file, con il tentativo di corromperlo sostituendolo con uno in collisione, richiederebbe un tempo macchina spaventoso rendendo questa strada non percorribile! Se tutto questo non dovesse convincervi, sappiate che è anche l'algoritmo di hash utilizzato dai mantainer del kernel Linux (è utilizzato infatti nel software GIT, programma con cui il codice viene manutenuto)

Finita la parte teorica, vi do appuntamento al secondo articolo per quanto concerne l'utilizzo reale di tutti i giorni.
---
M