Protezione di un checksum

Due domande, davvero.

1. No. Non mai. Cattiva idea. Male male male male male Non dare per scontato che concatenare più cose insicure ti fa essere sicuro perché, sai, probabilmente dovrebbe essere più sicuro. Potresti guadagnare un po 'di sicurezza attraverso l'oscurità, ma ricorda che gli hash sono rotti . Si riscontrano fallimenti fondamentali nel modello matematico che fornisce garanzie di sicurezza. Non è immediatamente chiaro se due algoritmi spezzati possono essere facilmente rotti insieme a meno che non si abbia lo sfondo matematico necessario per rompere la crittografia in primo luogo. Non farlo mai in questo modo.

   • Come esempio banale, si consideri la seguente serie di checksum: MD-5, CRC8-AUTOSAR e CRC-32. Utilizzando 3 checksum dovrei sicuramente essere più sicuro, giusto? No. Scoprirai che i due CRC aggiungono uno 0% di sicurezza in più rispetto a MD-5 e MD-5 è rotto, quindi quei tre checksum non faranno nulla per te.

2. Sì, è possibile utilizzare HMAC per fornire codici di autenticazione dei messaggi basati su hash e quindi rimuovere il bit di autenticazione pubblicando la chiave. Se rimuovi le parole che non si applicano, ti rimane il "codice hash". Sì, se si hash qualcosa con un algoritmo di hashing sicuro, il risultato sarà sicuro. Certo, potresti risparmiare un sacco di tempo semplicemente usando l'hash.

3. L'opzione migliore è quella che non hai menzionato: scopri quali algoritmi di hash sono sicuri e usane uno.

Infine, concentrati sulle parti deboli del tuo sistema. Descrivi un caso in cui i dati possono essere attaccati, ma nessuno attaccherà il checksum. Questa è una situazione piuttosto strana. L'unico caso che conosco dove si verifica è dove si scarica un file da una posizione non sicura e quindi si scarica la firma da una posizione attendibile per ridurre al minimo la larghezza di banda richiesta per la parte della posizione attendibile. Assicurati che il resto del tuo sistema sia sicuro. Come sottolinea Bruce Schneier, molto raramente la cripto è in realtà la parte debole del link!

Non appena usi la frase "condividi il segreto insieme all'hash generato", sei su un terreno instabile. Gli hash sono pubblici, chiunque può generarli e chiunque può controllarli. i "segreti" sono segreti. Hai bisogno di un canale sicuro per comunicarli o non sono segreti. Gli HMAC lavorano già tra le parti con il segreto. Strumento giusto per il lavoro giusto.

Lo scopo di un hash è quello di rilevare la corruzione (violazione dell'integrità), accidentale o intenzionale. Sebbene possa essere banale generare una collisione MD5 arbitraria, è ancora difficile creare un testo in chiaro significativo rispetto a una somma MD5 specifica.

Quindi, qual è lo scopo del tuo hash? Se è contro il rumore sulla linea (corruzione accidentale) md5 va bene. Se è contro un attaccante attivo sovvertire il testo in chiaro (cosa presumo dalla domanda) quale modello di minaccia assume che il checksum non può essere modificato se il testo in chiaro può?

Se la tua domanda è "sarebbe più difficile trovare un singolo documento che si scontri con due diversi algoritmi di checksum" la risposta è chiaramente sì. Ma perché? Cosa stai cercando di realizzare?

Se sei preoccupato della forza di un particolare algoritmo di hashing, usa uno più strong. Puoi, ovviamente, utilizzare due o più algoritmi, ma per ottenere qualche beneficio, tutti i tuoi destinatari dovrebbero controllare tutti gli hash.

Penso che sia probabile che alcuni client (software o umani) controllino solo uno, a questo punto il tuo multi-hash non è utile.

La mia raccomandazione sarebbe di usare solo una funzione hash più resistente alle collisioni.