Viene chiesto uno scenario in cui un utente malintenzionato è in grado di creare una collisione hash con un file arbitrario che l'utente malintenzionato non controlla (in questo caso, il download valido). Questo è chiamato un attacco Preimage , ed è generalmente più difficile di un semplice attacco di collisione, ma il tuo scenario prevede un attacco pre-attacco piuttosto che una semplice collisione. In tale scenario, la seguente affermazione non tieni premuto:
It would be extremely improbable for an attacker to be able to generate a collision that would be a runnable program, and could somehow infect your system.
Supponendo che tu abbia determinato come produrre qualsiasi file Y che ha una collisione hash con il file X valido, è probabile che altrettanto facile produca invece una Z funzionante Z con lo stesso valore di hash. I binari hanno enormi gradi di libertà: è possibile modificare le risorse incorporate (tabelle e icone delle stringhe e così via), i metadati (nome del programma, autore, data di compilazione, ecc.) E ovviamente basta attaccare la "spazzatura" usata per produrre l'hash collisione alla fine del file, dopo il vero programma (dannoso).
Quando le persone producono una collisione di hash, non stanno lavorando da uno stato pristine in cui non c'è hash, con cura elaborando dati che a poco a poco producono l'hash desiderato (almeno, non se ne usano anche solo vagamente -algoritmo hash moderno). Tutti i possibili input, inclusa la stringa vuota , hanno un hash digest valido. L'obiettivo del cercatore di collisione è trovare un input che produca l'output desiderato, ma non c'è motivo per cui l'input non possa essere parzialmente un blob di dati fissi (come un programma malware). Sì, quel blob avrà il proprio valore di hash iniziale (digest) ... ma lo stesso vale per la stringa vuota!
Quindi sì, se il blob arbitrario A produce di per sé la collisione desiderata, blob A da solo (come un file) è estremamente improbabile che sia un programma significativo, molto meno dannoso. Tuttavia, la quantità di lavoro necessaria per trovare BLOB A è la stessa quantità necessaria per trovare BLOB B che, una volta concatenato alla fine del programma dannoso fisso M, il digest di M + B produce la collisione.
Ora, con quello detto, le collisioni trovate finora su SHA1 non sono pre-immagini. Cioè, i ricercatori della sicurezza hanno trovato due blob arbitrari A e B che hanno lo stesso digest SHA1, ma hanno non dimostrato la capacità di, per un file specificato X (o specificato Digest D, dove presumibilmente D = SHA1 (X) per alcuni X), produce un file Y che ha lo stesso digest di SHA1 D di X. Hanno prodotto una collisione, ma non un attacco di pre-immagine.
La resistenza di collisione è una caratteristica di una funzione di hash sicura, quindi trovare qualsiasi collisione ha messo in dubbio la sicurezza generale di SHA1. Tuttavia, siamo ancora in alcuni modi dall'essere in grado di produrre attacchi preimage (contro digest arbitrari o file arbitrari) contro SHA1.