Quand le CRC est-il plus approprié que MD5 / SHA1?
Quand est-il approprié d'utiliser le CRC pour la détection d'erreur par rapport à des fonctions de hachage plus modernes telles que MD5 ou SHA1? Le premier est-il plus facile à implémenter sur du matériel embarqué?
Le CRC fonctionne très bien pour détecter les erreurs aléatoires dans les données pouvant survenir, par exemple, du brouillage du réseau, du bruit de ligne, de la distorsion, etc.
Le CRC est beaucoup moins complexe du point de vue informatique que MD5 ou SHA1. L'utilisation d'une fonction de hachage telle que MD5 est probablement excessive pour la détection d'erreur aléatoire. Cependant, l'utilisation de CRC pour tout type de contrôle de sécurité serait beaucoup moins sécurisée qu'une fonction de hachage plus complexe telle que MD5.
Et oui, le CRC est beaucoup plus facile à mettre en œuvre sur du matériel embarqué, vous pouvez même obtenir différentes solutions packagées sur IC.
Le CRC est conçu contre les modifications non intentionnelles des données. En d’autres termes, c’est un bon moyen de détecter les erreurs non intentionnelles, mais cela ne servira à rien de faire en sorte que les données ne soient pas traitées de manière malveillante.
Voir aussi this .
J'ai trouvé une étude qui montre comment inapproprié Les CRC sont des tables de hachage . Il explique également les caractéristiques réelles de l'algorithme. L'étude inclut é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 être utilisé avec une table de hachage. Il n'y a vraiment aucune bonne raison de l'utiliser à cette fin et je vous recommande de ne pas le faire. Si vous décidez d'utiliser CRC32, il est essentiel d'utiliser les bits de hachage de l'extrémité opposée à celle dans laquelle les octets de clé sont introduits. La fin de cette opération dépend de l'implémentation CRC32 spécifique. Ne considérez pas CRC32 comme une fonction de hachage "boîte noire" et ne l'utilisez pas comme un hachage à usage général. Assurez-vous de tester chaque application pour vous assurer de son adéquation.
[~ # ~] met à jour [~ # ~]
Il semble que le site est en panne. Le archive Internet a une copie si.
J'ai exécuté chaque ligne de ce PHP code dans une boucle de 1.000.000. Les résultats sont en 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 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:
- quelques problèmes de sécurité quand vous vous souciez de la sécurité
- chaîne de hachage plus longue et sont plus lents que "crc32b" lorsque tout ce dont vous avez besoin est CRC
Pour plus d'informations sur l'implémentation, la rapidité et la fiabilité du CRC, voir Guide pratique des algorithmes de détection d'erreur CRC . Il a tout sur les CRC.
Sauf si quelqu'un essaie de modifier vos données de manière malveillante et de masquer le CRC de modification, cela suffit. Utilisez simplement un "bon" polinomial (standard).
Vous ne dites pas ce que vous essayez de protéger.
Un CRC est souvent utilisé dans les systèmes embarqués pour lutter contre la corruption accidentelle des données, par opposition à la prévention des modifications malveillantes du système. Un exemple de lieux où un CRC peut être utile est de valider une image EPROM lors de l'initialisation du système afin d'éviter une corruption du microprogramme. Le programme d’amorçage du système calcule le CRC du code de l’application et le compare à la valeur stockée avant de permettre l’exécution du code. Cela protège contre la possibilité d'une corruption accidentelle du programme ou d'un téléchargement ayant é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 fichier de données par défaut ou de sauvegarde utilisé. Le CRC peut ne pas être valide en raison d'une panne de périphérique ou de la mise hors tension de l'utilisateur lors de la mise à jour du magasin de données de configuration.
Il a été dit qu'un hash offrait une plus grande probabilité de détecter une corruption qu'un CRC avec des erreurs sur plusieurs bits. C’est vrai, et la décision d’utiliser ou non un CRC de 16 ou 32 bits dépendra des conséquences sur la sécurité de l’utilisation d’un bloc de données corrompu et de la possibilité de justifier la probabilité 1 sur 2, 16 ou 2, sur 32 le bloc de données est incorrectement déclaré valide.
De nombreux périphériques ont un générateur CRC intégré pour les algorithmes standard. La série MSP430F5X du Texas propose une implémentation matérielle de la norme CRC-CCITT.
CRC32 est plus rapide et le hachage ne fait que 32 bits de long.
Utilisez-le quand vous voulez juste une somme de contrôle rapide et légère. Le 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.
Tout dépend de vos besoins et de vos attentes.
Voici quelques brèves différences entre ces fonction de hachage algorithmes:
CRC (CRC-8/16/32/64)
- est pas un algorithme de hachage cryptographique (il utilise une fonction linéaire basée sur des contrôles de redondance cycliques)
- peut produire 9, 17, 33 ou 65 bits
- non destiné à être utilisé à des fins cryptographiques car ne donne aucune garantie cryptographique,
- ne convient pas aux signatures numériques, car il est facilement réversible2006,
- ne devrait pas être utilisé à des fins de chiffrement,
- différentes chaînes peuvent générer la collision,
- inventé en 1961 et utilisé dans Ethernet et de nombreux autres standards,
MD5
- est un algorithme de hachage cryptographique,
- produisant une valeur de hachage de 128 bits (16 octets) (nombres hexadécimaux à 32 chiffres)
- c'est un hachage cryptographique, mais est considéré comme obsolète si vous vous inquiétez pour la sécurité,
- il y a 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) appelée digestion 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,
- n exemple de collision sha1 a été trouvé
- d'abord publié en 1993 (SHA-0), puis 1995 en tant que 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écurisée contre des adversaires disposant de ressources financières suffisantes, car en 2005, des cryptanalystes ont découvert des attaques sur SHA-1, suggérant qu'il n'était peut-être pas suffisamment sécurisé pour une utilisation continue.schneier. Le NIST américain recommande aux organismes fédéraux de cesser d'utiliser SHA1-1 pour les applications nécessitant une résistance aux collisions et d'utiliser SHA-2 après 2010 NIST .
Par conséquent, si vous recherchez une solution simple et rapide pour vérifier l’intégrité des fichiers (contre la corruption), ou pour des raisons simples de mise en cache en termes de performances, vous pouvez envisager le CRC-32, pour le hachage, vous pouvez envisager d’utiliser MD5, cependant, si vous développez une application professionnelle (qui doit être sécurisée et cohérente), pour éviter toute probabilité de collision, utilisez SHA-2 et les versions ultérieures (telles que SHA-3).
Performance
Quelques tests 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:
N'utilisez le CRC que si les ressources de calcul sont très restreintes (c.-à-d. Certains environnements intégrés) ou si vous devez stocker/transporter de nombreuses valeurs de sortie et si l'espace/la bande passante est restreint (les CRC étant généralement de 32 bits avec une sortie MD5 de 128 bits, SHA1). et autres 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 en cas de détection d'erreur accidentelle (plutôt que de détection de changement malveillant), les hachages sont meilleurs qu'un simple CRC. En partie à cause de la manière simple dont un CRC est calculé (et en partie parce que les valeurs de CRC sont généralement plus courtes que les sorties de hachage ordinaires et ont donc une plage de valeurs possibles beaucoup plus petite), il est beaucoup plus probable que, dans une situation où il existe deux erreurs ou plus , une erreur en masquera une autre pour que vous obteniez le même CRC malgré deux erreurs.
En bref: à moins d’avoir une raison pas d’utiliser un algorithme de hachage décent, évitez les CRC simples.
Je suis récemment tombé sur une utilisation du CRC qui était intelligente. L’auteur de l’outil d’identification et de suppression de fichiers jdupe (le même auteur du célèbre outil exif jhead) l’utilise lors de la première passe dans les fichiers. Un CRC est calculé sur les 32 premiers Ko de chaque fichier pour marquer les fichiers qui semblent identiques, mais 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 beaucoup de bits en moins de bits grâce à une opération de résumé. Les hachages servent à confirmer l'intégrité des messages et des fichiers.
Tous les algorithmes de hachage génèrent des collisions. Une collision survient lorsque plusieurs combinaisons de plusieurs bits produisent la même sortie avec moins de bits. La force cryptographique d'un algorithme de hachage est définie par l'incapacité d'un individu à déterminer quelle sera la sortie pour une entrée donnée, car s'il le pouvait, il pourrait construire un fichier avec un hachage qui correspond à un fichier légitime et compromet l'intégrité présumée. du système. La différence entre CRC32 et MD5 est que MD5 génère un hachage plus grand, 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 différents ou de fichiers à l'aide de 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 ce hachage 32 bits va être, je peux construire un fichier infecté qui entre en collision avec le fichier cible, qui a le même hash.
De plus, si je fais une transmission à 10 Mbps, alors la possibilité qu'un paquet soit corrompu juste pour contourner crc32 et continuer le long de la route jusqu'à la destination et l'exécution est très faible. Disons qu'à 10mbps je reçois 10 erreurs\seconde . Si je passe à 1 Gbit/s, je reçois maintenant 1 000 erreurs par seconde . Si je ramasse 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 000 erreurs de transmission, ce qui signifie que 1 million d'erreurs de transmission entraine la non-détection des données corrompues. À 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 produirait 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, que votre en-tête IP a un CRC32 et que votre TCP en-tête a un CRC32, ce qui s'ajoute aux valeurs les plus élevées. IPSEC peut utiliser MD5 ou SHA pour la vérification de 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 classiques, et elles restent TOUJOURS impossibles à des vitesses inférieures à 10 Mbps.
Le contrôle de redondance cyclique (CRC) a plusieurs versions courantes et plusieurs inhabituelles, mais est généralement conçu pour indiquer simplement quand un message ou un fichier a été endommagé en cours de transfert (plusieurs bits basculant). CRC32 en soi n’est pas un très bon protocole de vérification d’erreur par rapport aux normes actuelles dans les grands environnements d’entreprise, en raison du taux de collision; le disque dur d'un utilisateur moyen peut contenir plus de 100 000 fichiers et les partages de fichiers d'une entreprise peuvent en compter des dizaines de millions. Le ratio d'espace de hachage sur le nombre de fichiers est trop bas. CRC32 est peu coûteux à mettre en œuvre par ordinateur, alors que MD5 ne l’est pas.
MD5 a été conçu pour empêcher l’utilisation intentionnelle des collisions afin de donner à un fichier malveillant une apparence bénigne. Cela est considéré comme non sécurisé car l'espace de hachage a été suffisamment mappé pour permettre certaines attaques et certaines collisions sont prévisibles. SHA1 et SHA2 sont les nouveaux enfants sur le bloc.
Pour la vérification de fichier, Md5 commence à être utilisé par de nombreux fournisseurs car vous pouvez créer rapidement des fichiers à plusieurs octets ou plusieurs fichiers à la fois et les empiler au-dessus de l'utilisation et de la prise en charge de CRC32 par le système d'exploitation. Ne soyez pas surpris si, au cours de la prochaine décennie, les systèmes de fichiers commencent à utiliser MD5 pour la vérification des erreurs.
CRC32 est beaucoup plus rapide et prend parfois en charge le matériel (par exemple, sur les processeurs Nehalem). En réalité, la seule fois que vous l'utiliseriez, c'est si vous vous connectez avec du matériel, ou si vous êtes vraiment à la limite des performances.
Le code CRC est plus simple et plus rapide.
De quoi avez-vous besoin?