Risposte:
CRC funziona perfettamente per rilevare errori casuali nei dati che potrebbero verificarsi, ad esempio, da interferenze di rete, rumore di linea, distorsione, ecc.
CRC è computazionalmente molto meno complesso di MD5 o SHA1. L'uso di una funzione hash come MD5 è probabilmente eccessivo per il rilevamento di errori casuali. Tuttavia, l'utilizzo di CRC per qualsiasi tipo di controllo di sicurezza sarebbe molto meno sicuro di una funzione di hashing più complessa come MD5.
E sì, CRC è molto più facile da implementare su hardware incorporato, puoi persino ottenere diverse soluzioni pacchettizzate per questo su IC.
MD5, SHA-1dovrebbe anche essere evitato, SHA-2si consiglia una variante di .
CRC è progettato contro modifiche involontarie nei dati. Cioè, è buono per rilevare errori involontari, ma sarà inutile come modo per assicurarsi che i dati non siano stati gestiti in modo dannoso.
Vedi anche questo .
Ho trovato uno studio che mostra come gli hash CRC inappropriati siano per le tabelle hash . Spiega anche le caratteristiche effettive dell'algoritmo. Lo studio include anche la valutazione di altri algoritmi di hash ed è un buon riferimento da mantenere.
Le conclusioni pertinenti su CRC per gli hash:
CRC32 non è mai stato progettato per l'uso della tabella hash. Non c'è davvero alcun buon motivo per usarlo a questo scopo, e ti consiglio di evitare di farlo. Se decidi di utilizzare CRC32, è fondamentale utilizzare i bit di hash dall'estremità opposta a quella in cui vengono inseriti gli ottetti chiave. Quale estremità dipende dall'implementazione specifica di CRC32. Non considerare CRC32 come una funzione hash "scatola nera" e non usarlo come hash generico. Assicurati di testare ogni sua applicazione per l'idoneità.
AGGIORNARE
Sembra che il sito non sia attivo. L' archivio Internet ne ha una copia .
Ho eseguito ogni riga di questo codice PHP in 1.000.000 di loop. I risultati sono nei commenti (#).
hash('crc32', 'The quick brown fox jumped over the lazy dog.');# 750ms 8 chars
hash('crc32b','The quick brown fox jumped over the lazy dog.');# 700ms 8 chars
hash('md5', 'The quick brown fox jumped over the lazy dog.');# 770ms 32 chars
hash('sha1', 'The quick brown fox jumped over the lazy dog.');# 880ms 40 chars
hash('sha256','The quick brown fox jumped over the lazy dog.');# 1490ms 64 chars
hash('sha384','The quick brown fox jumped over the lazy dog.');# 1830ms 96 chars
hash('sha512','The quick brown fox jumped over the lazy dog.');# 1870ms 128 chars
La mia conclusione:
Usa "sha256" (o superiore) quando hai bisogno di un ulteriore livello di sicurezza.
Non usare "md5" o "sha1" perché hanno:
"The quick brown fox jumped over the lazy dog."), vedrai quanto CRC è più veloce di MD5.
Per informazioni CRC su implementazione, velocità e affidabilità, consultare Una guida indolore agli algoritmi di rilevamento errori CRC . Ha tutto sui CRC.
A meno che qualcuno non provi a modificare i dati in modo dannoso e nasconda la modifica CRC è sufficiente. Basta usare un polinomio "buono" (standard).
Tutto dipende dalle tue esigenze e aspettative.
Ecco alcune brevi differenze tra questi algoritmi della funzione hash :
è un algoritmo hash crittografico,
produce un valore hash a 160 bit (20 byte) noto come digest del messaggio
è un hash crittografico e dal 2005 non è più considerato sicuro,
può essere utilizzato per scopi di crittografia,
pubblicato per la prima volta nel 1993 (come SHA-0), poi nel 1995 come SHA-1,
serie: SHA-0, SHA-1, SHA-2, SHA-3,
In sintesi, l'uso di SHA-1 non è più considerato sicuro contro avversari ben finanziati, perché nel 2005 i crittografi hanno scoperto attacchi su SHA-1 che suggeriscono che potrebbe non essere abbastanza sicuro per l'uso in corso schneier . Il NIST degli Stati Uniti consiglia alle agenzie federali di smettere di usare SHA1-1 per applicazioni che richiedono resistenza alle collisioni e che devono utilizzare SHA-2 dopo il NIST 2010 .
Pertanto, se stai cercando una soluzione semplice e veloce per controllare l'integrità di un file (contro la corruzione) o per alcuni semplici scopi di memorizzazione nella cache in termini di prestazioni, puoi considerare CRC-32, per l'hash che potresti prendere in considerazione di utilizzare MD5, tuttavia, se stai sviluppando un'applicazione professionale (che dovrebbe essere sicura e coerente), per evitare qualsiasi probabilità di collisione - usa SHA-2 e versioni successive (come SHA-3).
Alcuni semplici test benchmark in PHP:
# Testing static text.
$ time php -r 'for ($i=0;$i<1000000;$i++) crc32("foo");'
real 0m0.845s
user 0m0.830s
sys 0m0.008s
$ time php -r 'for ($i=0;$i<1000000;$i++) md5("foo");'
real 0m1.103s
user 0m1.089s
sys 0m0.009s
$ time php -r 'for ($i=0;$i<1000000;$i++) sha1("foo");'
real 0m1.132s
user 0m1.116s
sys 0m0.010s
# Testing random number.
$ time php -r 'for ($i=0;$i<1000000;$i++) crc32(rand(0,$i));'
real 0m1.754s
user 0m1.735s
sys 0m0.012s\
$ time php -r 'for ($i=0;$i<1000000;$i++) md5(rand(0,$i));'
real 0m2.065s
user 0m2.042s
sys 0m0.015s
$ time php -r 'for ($i=0;$i<1000000;$i++) sha1(rand(0,$i));'
real 0m2.050s
user 0m2.021s
sys 0m0.015s
Relazionato:
Non dici cosa stai cercando di proteggere.
Un CRC viene spesso utilizzato nei sistemi incorporati come controllo contro il danneggiamento accidentale dei dati anziché impedire la modifica di sistemi dannosi. Esempi di luoghi in cui un CRC può essere utile è la convalida di un'immagine EPROM durante l'inizializzazione del sistema per evitare la corruzione del firmware. Il bootloader di sistema calcolerà il CRC per il codice dell'applicazione e lo confronterà con il valore memorizzato prima di consentire l'esecuzione del codice. Questo protegge dalla possibilità di corruzione accidentale del programma o download non riuscito.
Un CRC può anche essere usato in modo simile per proteggere i dati di configurazione memorizzati in FLASH o EEPROM. Se il CRC non è corretto, è possibile contrassegnare i dati come non validi e utilizzare un set di dati predefinito o di backup. Il CRC potrebbe non essere valido a causa di un guasto del dispositivo o se l'utente ha rimosso l'alimentazione durante un aggiornamento dell'archivio dati di configurazione.
Ci sono stati commenti secondo cui un hash offre maggiori probabilità di rilevare la corruzione rispetto a un CRC con errori a più bit. Questo è vero e la decisione se utilizzare o meno un CRC a 16 o 32 bit dipenderà dalle conseguenze sulla sicurezza dell'utilizzo di un blocco dati corrotto e se è possibile giustificare la possibilità 1 in 2 ^ 16 o 2 ^ 32 di un blocco dati dichiarato erroneamente valido.
Molti dispositivi hanno un generatore CRC integrato per algoritmi standard. La serie MSP430F5X dal Texas ha un'implementazione hardware dello standard CRC-CCITT.
Utilizzare CRC solo se le risorse di calcolo sono molto ridotte (ovvero alcuni ambienti di incorporamento) o è necessario archiviare / trasportare molti valori di output e lo spazio / larghezza di banda è ridotto (poiché i CRC sono in genere a 32 bit dove un'uscita MD5 è a 128 bit, SHA1 160 bit e altre varianti SHA fino a 512 bit).
Non utilizzare mai CRC per i controlli di sicurezza poiché un CRC è molto semplice da "falsificare".
Anche per il rilevamento accidentale di errori (piuttosto che per il rilevamento di modifiche dannose) gli hash sono migliori di un semplice CRC. In parte a causa del modo semplice in cui viene calcolato un CRC (e in parte perché i valori CRC sono generalmente più brevi delle comuni uscite hash, quindi hanno un intervallo molto più piccolo di valori possibili) è molto più probabile che, in una situazione in cui vi siano due o più errori , un errore ne maschererà un altro in modo da ottenere lo stesso CRC nonostante due errori.
In breve: a meno che tu non abbia motivo di non usare un algoritmo hash decente, evita i semplici CRC.
Recentemente mi sono imbattuto in un uso di CRC che era intelligente. L'autore dello strumento di identificazione e rimozione della duplicazione dei file jdupe (lo stesso autore della popolare jhead dello strumento exif) lo usa durante il primo passaggio attraverso i file. Un CRC viene calcolato sui primi 32 KB di ciascun file per contrassegnare i file che sembrano essere gli stessi, inoltre i file devono avere le stesse dimensioni. Questi file vengono aggiunti a un elenco di file su cui eseguire un confronto binario completo. Accelera il controllo di file multimediali di grandi dimensioni.
Cominciamo con le basi.
In Cryptography, un algoritmo di hashing converte molti bit in meno bit attraverso un'operazione digest. Gli hash vengono utilizzati per confermare l'integrità di messaggi e file.
Tutti gli algoritmi di hashing generano collisioni. Una collisione si verifica quando diverse combinazioni di molti bit producono lo stesso output di meno bit. La forza crittografica di un algoritmo di hashing è definita dall'incapacità di un individuo di determinare quale sarà l'output per un determinato input perché se potessero potrebbero costruire un file con un hash che corrisponda a un file legittimo e compromettere l'integrità presunta del sistema. La differenza tra CRC32 e MD5 è che MD5 genera un hash più grande che è più difficile da prevedere.
Quando si desidera implementare l'integrità del messaggio, ovvero il messaggio non è stato manomesso durante il trasporto, l'incapacità di prevedere le collisioni è una proprietà importante. Un hash a 32 bit può descrivere 4 miliardi di messaggi o file diversi utilizzando 4 miliardi di hash univoci diversi. Se hai 4 miliardi e 1 file, hai la garanzia di avere 1 collisione. Bitspace da 1 TB ha la possibilità di miliardi di collisioni. Se sono un utente malintenzionato e posso prevedere quale sarà l'hash a 32 bit, posso costruire un file infetto che si scontra con il file di destinazione; che ha lo stesso hash.
Inoltre, se sto facendo una trasmissione a 10 Mbps, la possibilità che un pacchetto venga corrotto proprio per bypassare crc32 e continuare lungo la destinazione ed eseguire è molto bassa. Diciamo che a 10 Mbps ottengo 10 errori \ secondo . Se lo raggiungo fino a 1 gbps, ora ricevo 1.000 errori al secondo . Se sperpero fino a 1 esborso al secondo, allora ho un tasso di errore di 1.000.000.000 di errori al secondo . Supponiamo di avere un tasso di collisione di 1 \ 1.000.000errori di trasmissione, il significato 1 su un milione di errori di trasmissione fa sì che i dati corrotti non vengano rilevati. A 10 Mbps riceverei dati di errore inviati ogni 100.000 secondi o circa una volta al giorno. A 1 gbps accadrebbe una volta ogni 5 minuti. Ad 1 punto esadecimale al secondo, stiamo parlando più volte al secondo.
Se apri Wireshark, vedrai che la tua tipica intestazione Ethernet ha un CRC32, la tua intestazione IP ha un CRC32 e la tua intestazione TCP ha un CRC32, e questo è in aggiunta a ciò che possono fare i protocolli di livello superiore; ad es. IPSEC potrebbe utilizzare MD5 o SHA per il controllo dell'integrità oltre a quanto sopra. Esistono diversi livelli di controllo degli errori nelle comunicazioni di rete tipiche e ANCORA goof di tanto in tanto a velocità inferiori a 10 Mbps.
Cyclic Redundancy Check (CRC) ha diverse versioni comuni e diverse non comuni, ma generalmente è progettato per dire solo quando un messaggio o un file è stato danneggiato durante il trasporto (capovolgimento di più bit). CRC32 di per sé non è un ottimo protocollo di controllo degli errori secondo gli standard odierni in ambienti aziendali di grandi dimensioni e scalari a causa del tasso di collisione; il disco rigido degli utenti medi può avere fino a 100.000 file e le condivisioni di file in un'azienda possono avere decine di milioni. Il rapporto tra spazio hash e numero di file è troppo basso. CRC32 è computazionalmente economico da implementare mentre MD5 no.
MD5 è stato progettato per impedire l'uso intenzionale di collisioni per rendere un file dannoso benigno. È considerato insicuro perché l'hashspace è stato sufficientemente mappato per consentire il verificarsi di alcuni attacchi e alcune collisioni sono prevedibili. SHA1 e SHA2 sono i nuovi bambini del blocco.
Per la verifica dei file, Md5 sta iniziando a essere utilizzato da molti fornitori perché è possibile eseguire rapidamente file multigigabyte o file multiterrabyte e impilarli in cima all'utilizzo del sistema operativo generale e al supporto dei CRC32. Non stupitevi se entro il prossimo decennio i filesystem iniziano a usare MD5 per il controllo degli errori.