Anche se NON lo è, quando verifichi manualmente gli hash con gli occhi (e il cervello), sembra un'ottima ottimizzazione. Dopotutto anche piccole modifiche nel contenuto dovrebbero causare un hash completamente diverso, giusto?
Sfortunatamente, questo fa diverse ipotesi che potrebbero essere la tua rovina. A causa di questi presupposti, la sicurezza ridotta non è una funzione del numero ridotto di bit che stai controllando. Ma qualcos'altro, non è facile da calcolare. Ma non è probabilmente un piccolo impatto.
Ad esempio:
- Se si assume che l'avversario stia apportando piccole modifiche. Molto probabilmente falso, a meno che tu non stia guardando un documento di prestito che è solo un hash (non firmato digitalmente), dove semplicemente aggiungere pochi zeri all'importo del prestito è un impatto abbastanza buono.
- Se si presuppone che l'avversario non tenterà collisioni hash, di nuovo è probabilmente falso - perché il tipo di persone che manomettono i documenti di solito hanno puntate alte e di solito vale la pena tentare. Riducendo i bit della metà, è probabile ridurre lo sforzo di generare collisioni hash da "100s of years" a "pochi minuti / ore" (ovvero, probabilità da ~ 0 a ~ 1) - non esattamente una riduzione del 50% in sicurezza. In questo modo sono state raggiunte le prime collisioni SHA1, tra l'altro: riducendo lo sforzo necessario (questo l'articolo di arstechnica parla di identici attacchi di prefisso - in termini di laici - significa che se si conosce una buona parte del documento in questione, lo sforzo si riduce in modo significativo ).
Ci sono anche altri problemi, ma credo che questo sia un motivo sufficiente per non seguire questa strada.
Quindi uso sempre gli strumenti per fare il controllo per me. ad esempio, Linux sha1sum e sha256sum non generano solo gli hash (per verificare manualmente) ma, dato il 2 ° input, possono verificare e dirti se tutto va bene.
