Strumenti per sviluppatori · SHA calcolatore hash
Hash crittografico vs checksum: cosa CRC32 e xxHash non possono promettere
· Sfondo
sha-256 crittografia sicurezza
Anche CRC32, FNV e xxHash sono hash, ma non fanno promesse contro un avversario. Questo post spiega cosa distingue gli hash crittografici dai checksum e come scegliere in base al caso d'uso.
Quale hash per quale lavoro? — la scelta tra velocità e sicurezza avversaria
Le funzioni hash sono disponibili in tre categorie: checksum per il rilevamento di errori accidentali, hash non crittografici per la distribuzione e le prestazioni e hash crittografici per la sicurezza. Ogni categoria ha garanzie diverse e diversi compromessi in termini di velocità e dimensioni del digest. Un checksum come CRC32 è veloce e breve (4 bytes, 8 caratteri esadecimali) ma non offre protezione contro modifiche intenzionali. Anche un hash non crittografico come xxHash o MurmurHash è veloce ed è utile per le tabelle hash e la distribuzione dei dati, ma non offre protezione contro un avversario che vuole provocare una collisione. Un hash crittografico come SHA-256 è più lento e produce un digest più lungo (32 bytes, 64 caratteri esadecimali), ma offre resistenza alla preimmagine e resistenza alle collisioni: proprietà di sicurezza che proteggono da un avversario.
Scegliere la funzione hash sbagliata per il tuo caso d'uso è un errore di sicurezza comune. L'utilizzo di CRC32 per verificare i download di file da una fonte non attendibile è inefficace; un utente malintenzionato può facilmente modificare il file e ricalcolare CRC32. Usare SHA-256 come funzione hash veloce in una tabella hash ad alta frequenza è uno spreco; CRC32 o un hash veloce non crittografico è sufficiente ed è più economico.
Checksum per errori accidentali: progettazione di CRC per rilevare i bit flip nella trasmissione
I checksum sono progettati per il rilevamento degli errori durante la trasmissione o l'archiviazione, dove si presuppone che gli errori siano casuali e accidentali. CRC (Cyclic Redundancy Check) è stato originariamente progettato per rilevare i bit flip nella comunicazione. Un CRC32 produce un digest da 32 bit. Se un frame viene danneggiato da inversioni casuali di bit durante la trasmissione, CRC32 quasi certamente cambierà, avvisando il ricevitore di richiedere la ritrasmissione. CRC può rilevare fino a un certo numero di errori di bit a seconda del polinomio; per i casi d'uso più comuni, viene rilevato in modo affidabile un singolo capovolgimento di bit o una raffica di pochi capovolgimenti di bit.
CRC è deterministico ma non crittografico. Dato un file e il relativo CRC32, un utente malintenzionato può modificare il file e ricalcolare CRC32 in modo che corrisponda al valore previsto. Per un avversario che conosce il polinomio CRC, produrre una collisione è semplice. CRC non è mai stato concepito per resistere alla modifica intenzionale; serve esclusivamente per il rilevamento di errori accidentali. I sistemi storici come i file ZIP e i file JPEG utilizzano CRC per questo scopo. I protocolli moderni utilizzano CRC per il rilevamento rapido degli errori all'interno di canali crittografati o autenticati, non come controllo di integrità autonomo.
Hash non crittografici per la distribuzione: FNV, MurmurHash e xxHash nelle tabelle hash e nel partizionamento
Gli hash non crittografici come FNV-1a, MurmurHash e xxHash sono progettati per velocità e uniformità nelle tabelle hash e nel partizionamento dei dati. Hanno una latenza molto bassa e vengono utilizzati in situazioni in cui è necessario partizionare i dati su server o bucket senza preoccuparsi delle proprietà di sicurezza. Se stai creando una cache e devi mappare una chiave su un numero di bucket, è appropriato un hash veloce. MurmurHash è stato progettato esplicitamente per l'uso con tabelle hash ed è più veloce di SHA sulla maggior parte dell'hardware. xxHash è più recente e ottimizzato per CPU moderne con cache di grandi dimensioni e vettorizzazione.
Questi hash non sono crittografici perché non resistono agli attacchi di preimmagine (trovare un input che produce un digest specifico) o agli attacchi di collisione (trovare due input diversi che producono lo stesso digest). Un utente malintenzionato può calcolare l'algoritmo hash e trovare input che si scontrano o che producono un output target. All'interno di un ambiente affidabile (un cluster in cui tutti i nodi sono sotto il tuo controllo), ciò è accettabile. Se un utente non attendibile può controllare l'input, un hash non crittografico è vulnerabile ad attacchi di collisione che riducono le prestazioni (il caso peggiore della tabella hash è la ricerca lineare quando tutte le chiavi si scontrano) o producono altri effetti collaterali.
Cosa aggiungono gli hash crittografici: preimmagine e resistenza alle collisioni contro un aggressore intenzionale
Gli hash crittografici come SHA-256, SHA-384 e SHA-512 forniscono resistenza alla preimmagine: dato un digest, è computazionalmente impossibile trovare qualsiasi input che produca quel digest. Forniscono anche resistenza alle collisioni: è computazionalmente impossibile trovare due input diversi che producano lo stesso digest. Queste proprietà proteggono da un avversario che vuole falsificare un download, creare un certificato falso o manomettere un messaggio. Il costo è la velocità: SHA-256 è più lento di CRC32 e più lento di xxHash sulla maggior parte dell'hardware.
SHA-1 è crittograficamente danneggiato (le collisioni sono pratiche) e non dovrebbe essere utilizzato per nuovi scopi di sicurezza, ma è comunque calcolato per la compatibilità legacy. SHA-256, SHA-384 e SHA-512 rimangono forti e sono le scelte standard per l'hashing crittografico. "2" in SHA-2 indica la seconda famiglia di algoritmi SHA (il primo è l'originale SHA-1; SHA-3 è una famiglia più recente ma viene utilizzata raramente per questo scopo).
Gli hash crittografici aggiungono proprietà antagoniste; questo articolo evita affermazioni sulla velocità relativa non supportate
Corrispondenza di cinque scenari alla famiglia di hash corretta: in primo luogo, i frame di rete trasmessi su un canale affidabile crittografato con AES: CRC32 è appropriato. La crittografia protegge dalle modifiche e CRC rileva la corruzione accidentale. In secondo luogo, tabelle hash o hashing coerente per il bilanciamento del carico: un hash non crittografico come xxHash è appropriato. La velocità è importante e l'ambiente è affidabile. In terzo luogo, è necessario verificare l'integrità del download da una fonte non attendibile: SHA-256. Un utente malintenzionato potrebbe modificare il file e il checksum, ma non l'hash crittografico senza violare SHA-256.
In quarto luogo, firme e certificati digitali: SHA-256 è obbligatorio ed è combinato con un algoritmo asimmetrico come RSA o ECDSA. La firma dimostra che l'hash non è stato modificato dopo la firma. In quinto luogo, la deduplicazione dei file caricati dagli utenti: SHA-256 è necessaria perché gli utenti potrebbero caricare deliberatamente file progettati per entrare in collisione con file esistenti in un hash non crittografico. Se la deduplicazione è basata su xxHash, un utente malintenzionato può caricare un file con lo stesso hash di un altro file ma contenuto diverso, facendo sì che il sistema scarti il caricamento in modo errato.
Esempio pratico: abbinamento di cinque scenari (frame di rete, mappe hash, verifica dei download, firme, deduplicazione dei caricamenti degli utenti) alla famiglia giusta
Il costo della scelta di un hash crittografico per ogni caso d'uso è un sovraccarico delle prestazioni. SHA-256 è più lento di CRC e più lento di xxHash. In un hot loop, un pezzo di codice che viene eseguito milioni di volte al secondo, questo sovraccarico è evidente. In una fase di impostazione o in un'operazione batch, è trascurabile. Il quadro decisionale è: un avversario ha un incentivo a provocare una collisione? Se sì, utilizza SHA-256. In caso negativo, e se la velocità è importante, utilizza un hash più veloce. Se la sicurezza è più importante della velocità, utilizza SHA-256 a prescindere.
Un errore comune è utilizzare MD5, un vecchio hash crittografico che ora non funziona più. MD5 è stato progettato in 1992 e le collisioni sono state dimostrate in 2004. L'utilizzo di MD5 per qualsiasi scopo di sicurezza non è sicuro. A volte viene riscontrato nei sistemi legacy e in situazioni in cui la velocità è una priorità, ma non esiste uno scenario in cui MD5 sia la scelta giusta oggi: se hai bisogno di velocità, usa xxHash; se hai bisogno di sicurezza, usa SHA-256. Non utilizzare mai MD5.
La mappatura degli scenari rimane qualitativa perché il rendimento e il comportamento in caso di collisione necessitano di prove specifiche dell'implementazione
L'hashing delle password è una quarta categoria, distinta sia dai checksum che dagli hash crittografici generici. Non utilizzare SHA-256 per eseguire l'hashing delle password. Utilizza invece una funzione di hashing della password come bcrypt, scrypt o Argon2, che sono deliberatamente lente e includono un salt. Un hash crittografico veloce come SHA-256 rende economico indovinare la password: un utente malintenzionato può provare milioni di tentativi al secondo. Una funzione di hashing della password è progettata per rendere ogni tentativo costoso in CPU e memoria, quindi indovinare una password complessa richiede ancora più tempo di quanto qualsiasi utente malintenzionato possa aspettare. L'hashing delle password è un caso d'uso specializzato con requisiti propri.
Il calcolatore di hash ToolAcre SHA non supporta l'hashing delle password e non offre deliberatamente MD5, parametri personalizzati e hash veloci. È uno strumento per elaborare digest standard SHA per la verifica e il controllo dell'integrità, non per l'autenticazione o l'archiviazione di password.
Conclusione: avversario o non avversario: utilizza il calcolatore di hash ToolAcre SHA quando qualcuno potrebbe manomettere i dati
La scelta dell'algoritmo hash è una decisione fondamentale che influisce sia sulle prestazioni che sulla sicurezza dell'intero sistema. Un digest è affidabile tanto quanto l'algoritmo che lo ha prodotto. Se scegli CRC32 per la verifica del file, il digest non fornisce alcuna protezione contro la modifica intenzionale. Se scegli SHA-256 per una tabella hash, stai sprecando risorse. Conoscere le proprietà e i compromessi di ciascuna categoria ti consente di scegliere correttamente.
Il calcolatore hash ToolAcre SHA fornisce da SHA-1 a SHA-512, coprendo gli hash crittografici importanti per la maggior parte dei casi d'uso. Non offre CRC32, xxHash o MD5 perché ognuno di questi è la scelta giusta in contesti specifici (CRC per il rilevamento degli errori in un canale attendibile, xxHash per le prestazioni in un ambiente controllato, niente per MD5) e offrirli senza enfatizzare quando utilizzarli incoraggerebbe gli errori. La calcolatrice serve per calcolare i digest crittografici standard. Utilizza la riga di comando con `crc32`, `xxh64` o strumenti equivalenti se hai bisogno di questi hash. Per la verifica del download, le impronte digitali dei certificati, i commit git e casi d'uso simili in cui un avversario potrebbe manomettere i dati, raggiungi SHA-256 tramite il calcolatore hash ToolAcre SHA.