Quand l'utilisation du CRC est-elle plus appropriée que MD5 / SHA1?


130

Quand est-il approprié d'utiliser CRC pour la détection d'erreurs par rapport aux fonctions de hachage plus modernes telles que MD5 ou SHA1? Le premier est-il plus facile à implémenter sur du matériel embarqué?

Réponses:


114

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.


1
@gili: vous pouvez toujours simplement xor les dwords ensemble pour obtenir un seul dword résultant.
Blindy

2
@Dustin: Vous avez tout à fait raison dans votre réponse, mais envisagez peut-être de changer «CRC est beaucoup plus efficace sur le plan informatique» en «CRC est beaucoup plus facile sur le plan informatique»? Les algorithmes MD5 / SHA-1 sont complexes, mais pas vraiment «inefficaces» IMO.
Coxy

1
@coxymla vous avez raison, le mot que j'aurais dû utiliser est "complexe" et non "inefficace". Merci!
définit le

27
Pour réduire tout hachage long à 32 bits, prenez simplement les 32 premiers bits.
orip

1
Si la sécurité est votre objectif, vous ne devriez jamais utiliser MD5, SHA-1doit également être évité, une variante de SHA-2est recommandée.
Peter

33

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 .


Partie la plus importante du lien dans cette réponse: "(...) même un CRC 2048 bits serait beaucoup moins sécurisé cryptographiquement qu'un MD5 128 bits"
Marc 2377

3
Bien que la réponse soit toujours correcte, MD5 et SHA1 sont au même niveau de sécurité de nos jours. En d'autres termes, seulement bon pour détecter les erreurs involontaires.
Piskvor a quitté le bâtiment le

21

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 .


Le lien est rompu. Peut-être pouvez-vous écrire vous-même l'explication? Sinon, la réponse est inutile.
ceving le

D'accord, je vais inclure la conclusion dans ma réponse.
Andre Luus

Bizarre, selon le benchmark ici , le CRC se débrouille plutôt bien en termes de vitesse et de nombre de collisions.
ostrokach

Très intéressant en effet. J'ai dû revoir l'étude à laquelle j'ai lié, mais si je devais deviner, cela doit être dû aux différentes implémentations de test. Si je devais prendre une décision, je choisirais les conseils de l'étude, cela semble être plus scientifiquement valable.
Andre Luus

D'après mon expérience de hachage de millions d'URL, CRC64 est entré en collision 8 fois et MD5 en collision 5. De toute évidence, MD5 était meilleur, mais CRC64 était un hachage formidable et beaucoup plus rapide et plus simple.
J.Dimeo

18

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 "crc32b" lorsque vous avez besoin de http://en.wikipedia.org/wiki/Cyclic_redundancy_check et que vous ne vous souciez pas de la sécurité.
  • 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:

    1. certains problèmes de sécurité lorsque vous vous souciez de la sécurité
    2. chaîne de hachage plus longue et sont plus lents que "crc32b" lorsque tout ce dont vous avez besoin est CRC

vous voulez dire des bits, pas des caractères
esskar

Pas vraiment. echo hash ('crc32', 'Le renard brun rapide a sauté par-dessus le chien paresseux.'); fait écho à "413a86af", soit une chaîne de 8 caractères. Btw, c'est un nombre 32 bits stocké au format HEX. Par exemple, "sha256" a un hachage de 256 bits, à nouveau stocké au format HEX, ce qui donne une chaîne de 64 caractères.
Martin

45
Ces résultats sont très trompeurs. Lorsque ces algorithmes de hachage sont appliqués à un grand ensemble de données ( Guerre et Paix au lieu de "The quick brown fox jumped over the lazy dog."), vous verrez à quel point le CRC est beaucoup plus rapide que MD5.
ubiquibacon

1
Il existe un cas intermédiaire (vérification en double dans les bibliothèques) où MD5 / Sha1 est la bonne solution: ils n'ont pas besoin de gérer le cas où un adversaire élabore soigneusement la collision de hachage extrêmement improbable, mais ils doivent gérer les collisions accidentelles. Donc: Détection des erreurs de bits et de la corruption: CRC32 Détection des collisions dans les bibliothèques: MD5 / SHA1 Applications contradictoires: Sha256 et supérieur. Bien sûr, si vous avez une bibliothèque avec des milliards d'entrées, vous devrez probablement également augmenter vos bits de hachage.
Dewi Morgan

PHP? sur une plateforme ARM, code embarqué, 16MHz un CRC32 de 46 octets, peut-être 12 microsecondes. Cela a une assistance matérielle. Même l'AES assisté par matériel serait plusieurs centaines de fois plus lent. La table de recherche non assistée CRC devrait toujours arriver dans environ 50 microsecondes.
ilgitano


9

Tout dépend de vos besoins et de vos attentes.

Voici de brèves différences entre ces algorithmes de fonction de hachage :

CRC (CRC-8/16/32/64)

  • n'est pas un algorithme de hachage cryptographique (il utilise une fonction linéaire basée sur des contrôles de redondance cyclique)
  • peut produire 9, 17, 33 ou 65 bits
  • non destiné à être utilisé à des fins cryptographiques car ne donne aucune garantie cryptographique,
  • ne convient pas pour une utilisation dans les signatures numériques, car il est facilement réversible 2006 ,
  • ne doit pas être utilisé à des fins de cryptage,
  • différentes chaînes peuvent générer la collision,
  • inventé en 1961 et utilisé dans Ethernet et de nombreuses autres normes,

MD5

  • est un algorithme de hachage cryptographique,
  • produisant une valeur de hachage de 128 bits (16 octets) (nombres hexadécimaux à 32 chiffres)
  • il s'agit d'un hachage cryptographique, mais il est considéré comme obsolète si vous vous inquiétez de la sécurité,
  • il existe des chaînes connues qui ont la même valeur de hachage MD5
  • peut être utilisé à des fins de cryptage,

SHA-1

  • 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,

  • un exemple de collision sha1 a été trouvé

  • 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).

Performance

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:


8

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.


6

CRC32 est plus rapide et le hachage ne fait que 32 bits.

Utilisez-le lorsque vous voulez juste une somme de contrôle rapide et légère. CRC est utilisé dans Ethernet.

Si vous avez besoin de plus de fiabilité, il est préférable d'utiliser une fonction de hachage moderne.


5

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.


1
CRC détectera toutes les modifications accidentelles de données si vous utilisez un polynôme approprié. 1/2 ^ 32 changements sont manqués si exactement les bons bits multiples sont modifiés.
Gerhard

Et avec un polynôme approprié, il détectera également toutes les erreurs de certaines classes courantes, par exemple les erreurs de rafale.
erikkallen

Je suis d'accord avec votre réponse, sauf que la question concerne les systèmes embarqués. Les performances d'un algorithme cryptographique peuvent être problématiques sur des systèmes embarqués plus petits.
Craig McQueen le

Je ne suis absolument pas d'accord avec cela. Les polynômes d'erreur CRC sont soigneusement choisis afin de pouvoir détecter de manière prouvée 1, 2, 3, 5 et les erreurs en rafale jusqu'à quelque chose comme 11 bits dans certains cas. Un hachage cryptographique est purement statistique, vous devez donc utiliser de grandes valeurs de résumé. 8-32 bits est irréaliste pour un condensé de hachage cryptographique et inutilement coûteux en cpu cyles et portes. Certainement pas une réponse à prendre en compte si vous travaillez sur des systèmes embarqués. Le seul moment où NE PAS utiliser un CRC est si vous devez faire face à un scénario d'adversaire intelligent.
ilgitano

5

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.


Un problème avec cette approche est que lorsqu'il est exécuté sur un fichier contenant un CRC32 intégré, le CRC résultant peut être indépendant des données du fichier (car si les données changent, le CRC32 sera modifié de manière à annuler la différence ). La fusion des données d'une manière simple avant de calculer le CRC32 éviterait ce problème.
supercat

1
@supercat - Je ne crois vraiment pas que ce soit réellement un problème. Si un fichier contient un en-tête crc32 qui est le crc32 du reste du fichier, alors lorsque le fichier est mis à jour, chaque bit de l'en-tête crc32 aura environ 50% de chances d'être différent. Les changements dans l'en-tête devraient suivre une distribution assez aléatoire. Je ne vois pas comment cela va aboutir à ce que le CRC32 (en-tête + données) soit toujours le même, ou ne dépend en aucun cas de la partie données du fichier.
teratorn

@teratorn: J'ai vu un certain nombre de fichiers qui ont un CRC32 à la fin, calculés de telle manière que le CRC32 du fichier entier, calculé en utilisant une constante de départ particulière, sera toujours une autre valeur constante. C'est assez courant avec des choses comme les images de code binaire. Si le lecteur DVD Acme 1000 utilise des images de code de taille fixe pour les mises à niveau du micrologiciel et s'attend à ce que chaque image de code ait un certain CRC32, alors une routine qui calcule les CRC32 de divers fichiers serait incapable de distinguer différentes images de code pour l'Acme 1000.
supercat

Le point du CRC dans ce cas est d'identifier rapidement que les fichiers sont différents. Si le CRC revient de la même manière, vous devez maintenant effectuer une comparaison binaire coûteuse, de sorte qu'un CRC intégré ne brise pas l'algorithme. Il se peut que certains fichiers finissent par être binaires comparés parce que le premier passage du CRC indique qu'ils PEUVENT être les mêmes, mais qu'il est peu probable qu'ils soient nombreux, et vous pouvez l'éviter en utilisant un polynôme personnalisé.
ilgitano

4

CRC32 est beaucoup plus rapide et a parfois un support matériel (c'est-à-dire sur les processeurs Nehalem). Vraiment, la seule fois où vous l'utiliseriez, c'est si vous vous interfacez avec du matériel ou si vous êtes vraiment serré sur les performances


4

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.


1

Le code CRC est plus simple et plus rapide.

Pour quoi avez-vous besoin?

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.