La risposta dipende dal modello di sicurezza.
Classicamente, una funzione di hash crittografica ha tre proprietà:
- Resiste a preimmagini : dato y , è impossibile trovare x tale che h ( x ) = y .
- Resiste a second preimages : dato x , è impossibile trovare x ' tale che x ≠ x ' e h ( x ) = h ( x' ).
- Resiste a collisioni : non è possibile trovare x e x ' tale che x ≠ x ' e h ( x ) = h ( x' ).
Per una funzione di hash "perfetta" con un output di n bit, la resistenza è allo sforzo, rispettivamente, 2 n , 2 n e 2 n / 2 (indipendentemente da quanto sia strong la funzione, "fortuna" funziona ancora con una piccola probabilità, e questo fornisce questi costi medi per trovare una pre-immagine, una seconda pre-immagine o una collisione).
Quando si tronca l'output di una funzione di hash esistente, si sta infatti definendo una nuova funzione di hash e poiché la funzione di hash ha un output più piccolo, la sua resistenza è corrispondentemente più piccola.
La buona domanda è quindi: su quali di queste proprietà stai facendo affidamento? Questo dipende molto dal contesto.
Ad esempio, supponiamo che l'obiettivo dell'attaccante sia di modificare un dato esistente, senza essere rilevato attraverso una mancata corrispondenza della funzione hash. Questa è una seconda situazione di preimage: l'attaccante vede un messaggio m e prova a trovare un messaggio modificato m ' che ha lo stesso valore. In questo caso, troncare a 10 byte significa che hai ancora la resistenza 2 80 , un numero enorme che scoraggerà tutti tranne gli aggressori più determinati o irrazionali. Si noti, tuttavia, che un utente malintenzionato può avere una scelta di bersagli: se l'utente malintenzionato vede 100 messaggi e desidera modificarne uno (senza preferenze su cui può essere modificato), quindi "fortuna" funziona 100 volte meglio. Pertanto potresti volere un margine di sicurezza extra e mantenere, diciamo, 12 o 13 byte di output.
Ora se l'autore dell'attacco può iniettare il suo proprio messaggio m dall'aspetto innocente, convalidare e cancellare e in seguito sostituirlo con un messaggio distinto m con lo stesso valore di hash, allora questa è una questione di collisioni, quindi funziona con la resistenza 2 n / 2 per un output n -bit . In tal caso, troncare l'output della funzione hash è una pessima idea.
Il corso sicuro non deve troncare nulla. Dopotutto, mentre scrivo sopra, il troncamento dell'output equivale a progettare la propria funzione di hash e, in generale, è molto difficile farlo correttamente. SHA-1 ha un output a 160 bit preciso in modo da ottenere "almeno 2 80 sicurezza" in tutti i casi. Determinare se le collisioni si applicano alla tua situazione o no può essere difficile.
Inoltre , ricorda che un valore hash non crea integrità; si concentra solo il problema. Quando si hash una parte di dati, si ottiene un valore di hash e tale valore di hash garantirà che i dati originali sono invariati solo nella misura in cui si può essere certi, con altri mezzi , che il valore hash stesso non è stato alterato. Se si memorizza il valore hash insieme ai dati hash (il proprio "input") e si presume che l'autore dell'attacco sia in grado di modificare i dati memorizzati, cosa esattamente gli impedirebbe di modificare anche il valore hash? Ogni volta che vuole mettere m ' invece di m in alcune celle del database, può anche mettere SHA-1 ( m' ) nel vicino cella, sovrascrivendo SHA-1 ( m ) che era lì, e non ne sarai più saggio.
Se si desidera utilizzare valori hash per proteggere l'integrità dei dati, è necessario garantire l'integrità dei valori hash stessi in qualche altro modo. Funzioni hash riducono il problema: invece di proteggere un file da 1 gigabyte, devi "solo" proteggere un valore hash da 20 byte. Ma devi ancora fare qualcosa.
La crittografia può aiutarti a concentrare ulteriormente le cose utilizzando un MAC invece di una funzione di hash. Con un MAC, hai una chiave segreta e puoi usare la chiave one per milioni di MAC calcolati su milioni di "input". Anche in questo caso, devi ancora fare qualcosa, ma quel qualcosa è: mantenere la riservatezza di una singola chiave (di, ad esempio, 128 bit) per l'intero server.