Réponses:
CRC fonctionne très bien pour détecter les erreurs aléatoires dans les données qui pourraient survenir, par exemple, en raison d'interférences réseau, de bruit de ligne, de distorsion, etc.
CRC est beaucoup moins complexe que MD5 ou SHA1 sur le plan du calcul. L'utilisation d'une fonction de hachage comme MD5 est probablement exagérée pour la détection d'erreur aléatoire. Cependant, utiliser CRC pour tout type de contrôle de sécurité serait beaucoup moins sûr qu'une fonction de hachage plus complexe telle que MD5.
Et oui, CRC est beaucoup plus facile à implémenter sur du matériel embarqué, vous pouvez même obtenir différentes solutions packagées pour cela sur IC.
MD5, SHA-1doit également être évité, une variante de SHA-2est recommandée.
Le CRC est conçu contre les modifications involontaires des données. C'est-à-dire que c'est bon pour détecter les erreurs involontaires, mais sera inutile pour s'assurer qu'une donnée n'a pas été manipulée de manière malveillante.
Voir aussi ceci .
J'ai trouvé une étude qui montre à quel point les hachages CRC sont inappropriés pour les tables de hachage . Il explique également les caractéristiques réelles de l'algorithme. L'étude comprend également l'évaluation d'autres algorithmes de hachage et constitue une bonne référence à conserver.
La conclusion pertinente sur le CRC pour les hachages:
CRC32 n'a jamais été conçu pour une utilisation de table de hachage. Il n'y a vraiment aucune bonne raison de l'utiliser à cette fin, et je vous recommande d'éviter de le faire. Si vous décidez d'utiliser CRC32, il est essentiel que vous utilisiez les bits de hachage de l'extrémité opposée à celle dans laquelle les octets clés sont introduits. La fin dépend de l'implémentation CRC32 spécifique. Ne traitez pas CRC32 comme une fonction de hachage «boîte noire» et ne l'utilisez pas comme hachage à usage général. Assurez-vous de tester chaque application pour la pertinence.
METTRE À JOUR
Il semble que le site soit en panne. L' archive Internet en a cependant une copie .
J'ai exécuté chaque ligne de ce code PHP en boucle 1.000.000. Les résultats sont dans les commentaires (#).
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
Ma conclusion:
Utilisez "sha256" (ou supérieur) lorsque vous avez besoin d'une couche de sécurité supplémentaire.
N'utilisez pas "md5" ou "sha1" car ils ont:
"The quick brown fox jumped over the lazy dog."), vous verrez à quel point le CRC est beaucoup plus rapide que MD5.
Pour obtenir des informations sur la mise en œuvre, la vitesse et la fiabilité du CRC, voir Un guide indolore sur les algorithmes de détection d'erreurs CRC . Il a tout sur les CRC.
À moins que quelqu'un ne tente de modifier vos données de manière malveillante et de masquer le changement, le CRC est suffisant. Utilisez simplement un polinôme «bon» (standard).
Tout dépend de vos besoins et de vos attentes.
Voici de brèves différences entre ces algorithmes de fonction de hachage :
est un algorithme de hachage cryptographique,
produit une valeur de hachage de 160 bits (20 octets) connue sous le nom de résumé de message
c'est un hachage cryptographique et depuis 2005 il n'est plus considéré comme sécurisé,
peut être utilisé à des fins de cryptage,
publié pour la première fois en 1993 (sous le nom SHA-0), puis en 1995 sous le nom SHA-1,
série: SHA-0, SHA-1, SHA-2, SHA-3,
En résumé, l'utilisation de SHA-1 n'est plus considérée comme sûre contre des adversaires bien financés, car en 2005, les cryptanalystes ont trouvé des attaques sur SHA-1, ce qui suggère qu'il n'est peut-être pas suffisamment sécurisé pour une utilisation continue schneier . Le NIST américain conseille aux agences fédérales de cesser d'utiliser SHA1-1 pour les applications qui nécessitent une résistance aux collisions et doivent utiliser SHA-2 après 2010 NIST .
Par conséquent, si vous recherchez une solution simple et rapide pour vérifier l'intégrité d'un fichier (contre la corruption), ou à des fins de mise en cache simples en termes de performances, vous pouvez envisager CRC-32, pour le hachage que vous pouvez envisager d'utiliser MD5, cependant, si vous développez une application professionnelle (qui devrait être sécurisée et cohérente), pour éviter toute probabilité de collision, utilisez SHA-2 et supérieur (comme SHA-3).
Quelques tests de référence simples en 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
En relation:
Vous ne dites pas ce que vous essayez de protéger.
Un CRC est souvent utilisé dans les systèmes embarqués pour vérifier la corruption accidentelle des données plutôt que pour empêcher la modification malveillante du système. Des exemples d'endroits où un CRC peut être utile sont de valider une image EPROM pendant l'initialisation du système pour se prémunir contre la corruption du micrologiciel. Le chargeur de démarrage système calculera le CRC pour le code d'application et le comparera avec la valeur stockée avant d'autoriser l'exécution du code. Cela protège contre la possibilité d'une corruption accidentelle du programme ou d'un téléchargement échoué.
Un CRC peut également être utilisé de manière similaire pour protéger les données de configuration stockées dans FLASH ou EEPROM. Si le CRC est incorrect, les données peuvent être marquées comme non valides et un jeu de données par défaut ou de sauvegarde utilisé. Le CRC peut être invalide en raison d'une défaillance de l'appareil ou si l'utilisateur a coupé l'alimentation pendant une mise à jour du magasin de données de configuration.
Il y a eu des commentaires selon lesquels un hachage fournit une plus grande probabilité de détection de la corruption qu'un CRC avec plusieurs erreurs sur les bits. Cela est vrai, et la décision d'utiliser ou non un CRC 16 ou 32 bits dépendra des conséquences pour la sécurité d'un bloc de données corrompu utilisé et de la possibilité de justifier la chance de 1 sur 2 ^ 16 ou 2 ^ 32 d'un bloc de données incorrectement déclaré valide.
De nombreux appareils ont un générateur CRC intégré pour les algorithmes standard. La série MSP430F5X du Texas a une implémentation matérielle de la norme CRC-CCITT.
N'utilisez CRC que si les ressources de calcul sont très restreintes (c'est-à-dire certains environnements embarqués) ou si vous devez stocker / transporter de nombreuses valeurs de sortie et que l'espace / bande passante est restreint (car les CRC sont généralement 32 bits où une sortie MD5 est 128 bits, SHA1 160 bit et d'autres variantes SHA jusqu'à 512 bits).
N'utilisez jamais le CRC pour les contrôles de sécurité car un CRC est très facile à «simuler».
Même pour la détection d'erreur accidentelle (plutôt que pour la détection de changement malveillant), les hachages sont meilleurs qu'un simple CRC. En partie à cause de la façon simple dont un CRC est calculé (et en partie parce que les valeurs CRC sont généralement plus courtes que les sorties de hachage communes, donc ont une gamme beaucoup plus petite de valeurs possibles), il est beaucoup plus probable que, dans une situation où il y a deux erreurs ou plus , une erreur en masquera une autre et vous vous retrouverez avec le même CRC malgré deux erreurs.
En bref: à moins que vous n'ayez des raisons de ne pas utiliser un algorithme de hachage décent, évitez les simples CRC.
Je suis tombé récemment sur une utilisation du CRC qui était intelligente. L'auteur de l' outil d' identification et de suppression de duplication de fichiers jdupe (le même auteur du populaire outil exif jhead) l'utilise lors du premier passage dans les fichiers. Un CRC est calculé sur les 32 premiers Ko de chaque fichier pour marquer les fichiers qui semblent identiques, les fichiers doivent également avoir la même taille. Ces fichiers sont ajoutés à une liste de fichiers sur lesquels effectuer une comparaison binaire complète. Il accélère la vérification de gros fichiers multimédias.
Commençons par les bases.
En cryptographie, un algorithme de hachage convertit de nombreux bits en moins de bits via une opération de résumé. Les hachages sont utilisés pour confirmer l'intégrité des messages et des fichiers.
Tous les algorithmes de hachage génèrent des collisions. Une collision se produit lorsque plusieurs combinaisons de plusieurs bits produisent la même sortie de moins de bits. La force cryptographique d'un algorithme de hachage est définie par l'incapacité pour un individu de déterminer ce que sera la sortie pour une entrée donnée, car s'ils le pouvaient, ils pourraient construire un fichier avec un hachage qui correspond à un fichier légitime et compromettre l'intégrité supposée du système. La différence entre CRC32 et MD5 est que MD5 génère un hachage plus important qui est plus difficile à prévoir.
Lorsque vous souhaitez implémenter l'intégrité du message - c'est-à-dire que le message n'a pas été falsifié en transit - l'incapacité de prédire les collisions est une propriété importante. Un hachage 32 bits peut décrire 4 milliards de messages ou fichiers différents en utilisant 4 milliards de hachages uniques différents. Si vous avez 4 milliards et 1 fichiers, vous êtes assuré d'avoir 1 collision. 1 TB Bitspace a la possibilité de milliards de collisions. Si je suis un attaquant et que je peux prédire ce que sera ce hachage 32 bits, je peux créer un fichier infecté qui entre en collision avec le fichier cible; qui a le même hachage.
De plus, si je fais une transmission à 10 Mbps, la possibilité qu'un paquet soit corrompu juste pour contourner crc32 et continuer vers la destination et s'exécuter est très faible. Disons qu'à 10 Mbps, j'obtiens 10 erreurs \ seconde . Si je monte cela jusqu'à 1 Gbit / s, j'obtiens maintenant 1000 erreurs par seconde . Si je pousse jusqu'à 1 exabit par seconde, alors j'ai un taux d'erreur de 1 000 000 000 d'erreurs par seconde . Supposons que nous ayons un taux de collision de 1 \ 1 000 000erreurs de transmission, ce qui signifie 1 erreur de transmission sur un million, les données corrompues passent sans être détectées. À 10 Mbps, les données d'erreur étaient envoyées toutes les 100 000 secondes ou environ une fois par jour. À 1 Gbps, cela se produisait une fois toutes les 5 minutes. À 1 exabit par seconde, nous parlons plusieurs fois par seconde.
Si vous ouvrez Wireshark, vous verrez que votre en-tête Ethernet typique a un CRC32, votre en-tête IP a un CRC32 et votre en-tête TCP a un CRC32, et c'est en plus de ce que les protocoles de couche supérieure peuvent faire; Par exemple, IPSEC peut utiliser MD5 ou SHA pour vérifier l'intégrité en plus de ce qui précède. Il existe plusieurs couches de vérification des erreurs dans les communications réseau typiques, et elles sont toujours gênantes de temps en temps à des vitesses inférieures à 10 Mbps.
Le contrôle de redondance cyclique (CRC) a plusieurs versions communes et plusieurs peu communes, mais il est généralement conçu pour simplement dire quand un message ou un fichier a été endommagé en transit (retournement de plusieurs bits). CRC32 en lui-même n'est pas un très bon protocole de vérification des erreurs par rapport aux normes actuelles dans les grands environnements d'entreprise scalaires en raison du taux de collision; le disque dur des utilisateurs moyens peut avoir plus de 100k fichiers, et les partages de fichiers sur une entreprise peuvent en avoir des dizaines de millions. Le rapport entre l'espace de hachage et le nombre de fichiers est tout simplement trop faible. CRC32 est peu coûteux à mettre en œuvre, contrairement à MD5.
MD5 a été conçu pour arrêter l'utilisation intentionnelle de collisions pour donner à un fichier malveillant un aspect bénin. Il est considéré comme non sécurisé car l'espace de hachage a été suffisamment mappé pour permettre à certaines attaques de se produire, et certaines collisions sont prévisibles. SHA1 et SHA2 sont les nouveaux enfants du quartier.
Pour la vérification de fichiers, Md5 commence à être utilisé par de nombreux fournisseurs, car vous pouvez créer rapidement des fichiers de plusieurs gigaoctets ou des fichiers de plusieurs octets et l'empiler en plus de l'utilisation et du support des CRC32 par le système d'exploitation général. Ne soyez pas surpris si dans la prochaine décennie, les systèmes de fichiers commencent à utiliser MD5 pour la vérification des erreurs.