[gl-como] Hash e falsificazioni

Pirla the.pirla@flashnet.it
Ven 4 Mar 2005 16:21:34 CET


In realtà non è proprio così.

L'hash (per esempio md5) viene usato per avere una certa sicurezza che
il file sia effettivamente quello che si pensa sia.

Però l'hash effettua una modifica del contenuto del file per determinare
un valore molto più piccolo del file stesso, in modo da poterlo
trasferire con poca spesa e poter verificare la corrispondenza.
Per esempio rsync usa questo metodo per trasferire i soli blocchi
modificati di un file molto grande e poi verificare che il file
ricostruito sulla destinazione sia lo stesso di quello originale.

Questo meccanismo in se non da nessuna sicurezza perché chiunque con
dolo potrebbe corrompere il dato.

La caratteristica più importante dell'hash e che non ci siano
collisioni... il che non vuol dire che due file diversi non possono
avere hash uguale, ma che tutti gli hash siano uniformemente distribuiti
(ovvero non ci siano hash con probabilità maggiore di verificarsi o con
probabilità minore che sarebbe ancora peggio).

Faccio un esempio chiarificatore:
Supponiamo di avere una funzione che soddisfa il criterio sopra esposto
e che genera un hash da 16 bit (per fare numeri piccoli.. il concetto
vale lo stesso anche per numeri grandi).
Con 16 bit io posso generare 65536 valori diversi che rappresentano i
miei hash.

Supponiamo di riuscire a generare (non è difficile) 65536 file da 16 bit
e che tutti i file siano diversi.

Se la funzione è fatta bene io devo riuscire ad ottenere per tutti i
file hash diversi.

Supponiamo ora di creare 131072 file diversi da 17 bit e di calcolare
per tutti i file l'hash.

Se ancora una volta la funzione è fatta bene io ho 65536 hash diversi e
quindi tutti i miei file a 2 a 2 avranno hash uguale.
Ecco quindi che in questo modo riesco a generare un file che ha un hash
uguale ad un altro file.

Allora qual'è il vantaggio di usare gli hash?
Dal punto di vista statistico ed escludendo il dolo, ho una buona
probabilità che modificando di poco il file originale l'hash cambi
(questa è una prerogativa delle funzioni di hash).
In poche parole se cambio un solo bit o due bit devo avere poche
probabilità di avere una collisione.
Anche questo prevede l'uso della statistica... per file molto grandi
questo non è vero.

Inoltre io posso applicare allo stesso file più funzioni di hash ed
ottenere risultati diversi.
Anche quì statisticamente troverò che ho poche probabilità che due file
diversi possano avere hash uguali pur usando funzioni diverse.


Il ven, 2005-02-25 alle 16:57, Matteo Cavalleri ha scritto:
> luca marletta wrote:
> 
> >Alle 03:31 del 25 Feb 2005, Pietro Bertera ha scritto:
> >  
> >
> >>Il giorno ven, 25-02-2005 alle 15:19 +0000, luca marletta ha scritto:
> >>Hash e cifratura (con chiave) sono due cose diverse, il primo è
> >>una trasformazione matematica pardendo dal plaintext per la
> >>seconda occorre anche una (o 2) chiave(i). Quindi non esiste
> >>nessuna chiave per gli hash.
> >>    
> >>
> >
> >Si hai ragione, ho sbagliato ad usare il termine chiave, intendevo
> >la "chiave di lettura" perchè, probabilmente sbaglio ma ho sempre
> >pensato che anche nel caso degli hash se ricostruisci, a tentativo
> >la trasformazione nè hai la chiave, stesso procedimento che devi
> >fare per decriptare una cifratura. O no??!! :-))
> >
> >  
> >
> no, nel senso che non puoi ricostruire. (sarebbe troppo bello, avremmo 
> inventato un compressore fantastico!)
> l'hash funziona così
> 
> dati   ---algoritmo-di-hash-->   risultato
> 
> l'algoritmo è perfettamente ripetible, per cui un persona che vuole 
> verificare per es. l'integrità dei dati
> può applicare di nuovo l'algoritmo e verificare che il risultato sia lo 
> stesso. L'algoritmo non è reversibile
> cioè non si può dal risultato risalire al file. (magari!) Non c'è 
> nessuna chiave. Il risultato è un numero di bit fisso
> e di solito modesto (per es. 1024).  Per esempio l'hash serve a tripwire 
> a verificare che nessuno abbia
> toccato qualche file del tuo firewall (ammesso che tu ti stia salvando 
> da qualche altra parte il db degli hash;-)
> 
> Una piccola variante, sono gli algoritmi "salted" ovvero "con sale". si 
> aggiunge il sale quando
> si vuole fare in modo che il risultato dipenda anche dal sale..
> 
> dati   ---\
>               algoritmo-di-hash-->   risultato
> sale  ----/
> 
> ma il funzionamento monodirezionale dell'algoritmo rimane lo stesso.
> 
> (spero che il "disegno" a caratteri non si rovini...)
> 
> ______________________________________________________________________
-- 
Ciao
	Pirla

Per rispondere in E-mail the (punto) pirla (chiocciola) flashnet.it
*** un bacio ai pupi ***

---> Linux user since yesterday <---




Maggiori informazioni sulla lista gl-como