Longueur des données vs longueur du CRC
J'ai vu des CRC 8 bits, 16 bits et 32 bits.
À quel moment dois-je passer à un CRC plus large?
Ma réaction intestinale est qu'elle est basée sur la longueur des données:
- 1 à 100 octets: CRC 8 bits
- 101 - 1000 octets: CRC 16 bits
- 1001 - ??? octets: CRC 32 bits
EDIT: En regardant la page Wikipedia sur CRC et la réponse de Lott, voici ce que nous avons:
<64 octets: CRC 8 bits
<16 Ko octets: CRC 16 bits
<512 Mo octets: CRC 32 bits
Ce n'est pas un sujet de recherche. C'est vraiment bien compris: http://en.wikipedia.org/wiki/Cyclic_redundancy_check
Le calcul est assez simple. Un CRC 8 bits réduit tous les messages à l'une des 256 valeurs. Si votre message fait plus de quelques octets, la possibilité que plusieurs messages aient la même valeur de hachage augmente de plus en plus.
De même, un CRC 16 bits vous donne l'une des 65 536 valeurs de hachage disponibles. Quelles sont les chances que deux messages aient l'une de ces valeurs?
Un CRC 32 bits vous donne environ 4 milliards de valeurs de hachage disponibles.
De l'article de wikipedia: "la longueur totale maximale des blocs est égale à 2**r − 1 ". C'est en bits. Vous n'avez pas besoin de faire beaucoup de recherches pour voir que 2**9 - 1 est 511 bits. Avec CRC-8, plusieurs messages de plus de 64 octets auront la même valeur de somme de contrôle CRC.
L'efficacité d'un CRC dépend de plusieurs facteurs. Vous devez non seulement sélectionner la TAILLE du CRC mais également le POLYNOMIAL GÉNÉRATEUR à utiliser. Il existe des compromis compliqués et non intuitifs selon:
- Le taux d'erreur sur les bits attendu du canal.
- Si les erreurs ont tendance à se produire en rafales ou à s'étaler (la rafale est courante)
- La longueur des données à protéger - longueur maximale, longueur minimale et distribution.
Le document Cyclic Redundancy Code Polynominal Selection For Embedded Networks, de Philip Koopman et Tridib Chakravarty, publié dans les actes de la Conférence internationale de 2004 sur les systèmes et réseaux fiables donne un très bon aperçu et formule plusieurs recommandations. Il fournit également une bibliographie pour une meilleure compréhension.
http://www.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf
Le choix de la longueur du CRC en fonction de la taille du fichier est principalement pertinent dans les cas où l'on est plus susceptible d'avoir une entrée qui diffère de l'entrée "correcte" de trois bits ou moins que d'en avoir une qui est massivement différente. Étant donné deux entrées qui sont massivement différentes, la possibilité d'une fausse correspondance sera d'environ 1/256 avec la plupart des formes de valeur de contrôle 8 bits (y compris CRC), 1/65536 avec la plupart des formes de valeur de contrôle 16 bits (y compris CRC) , etc. L'avantage du CRC vient de son traitement des intrants qui sont très similaires.
Avec un CRC 8 bits dont le polynôme génère deux périodes de longueur 128, la fraction des erreurs à bit unique, double ou triple dans un paquet plus court que celui qui n'est pas détecté ne sera pas de 1/256 - elle sera nulle. De même avec un CRC 16 bits de la période 32768, utilisant des paquets de 32768 bits ou moins.
Si les paquets sont plus longs que la période CRC, cependant, une erreur à double bit ne sera pas détectée si la distance entre les bits erronés est un multiple de la période CRC. Bien que cela ne semble pas être un scénario très probable, un CRC8 sera un peu plus mauvais pour détecter les erreurs double-bit dans les paquets longs que pour détecter les erreurs "le paquet est totalement brouillé". Si les erreurs à deux bits sont le deuxième mode de défaillance le plus courant (après les erreurs à un seul bit), ce serait mauvais. Si quelque chose qui corrompt certaines données est susceptible d'en corrompre une grande partie, cependant, le comportement inférieur des CRC avec des erreurs à double bit peut ne pas être un problème.
Je pense que la taille du CRC a plus à voir avec le caractère unique d'un CRC dont vous avez besoin au lieu de la taille des données d'entrée. Cela est lié à l'utilisation particulière et au nombre d'éléments sur lesquels vous calculez un CRC.
Voici une belle évaluation "réelle" du CRC-N http://www.backplane.com/matt/crc64.html
J'utilise CRC-32 et la comparaison de taille de fichier et n'ai JAMAIS, dans les milliards de fichiers vérifiés, rencontré une collision CRC-32 et taille de fichier correspondante. Mais je sais que quelques-uns existent, lorsqu'ils ne sont pas forcément forcés d'exister. (Astuces/exploits piratés)
Lors de la comparaison, vous devez également vérifier les "tailles de données". Vous aurez rarement une collision de la même taille de données, avec un CRC correspondant, dans les tailles correctes.
Les données délibérément manipulées, pour simuler une correspondance, sont généralement effectuées en ajoutant des données supplémentaires jusqu'à ce que le CRC corresponde à une cible. Cependant, cela se traduit par une taille de données qui ne correspond plus. Tenter de forcer la force brute ou de parcourir des données aléatoires ou séquentielles de la même taille exacte laisserait un taux de collision vraiment étroit.
Vous pouvez également avoir des collisions au sein de la taille des données, simplement par les limites génériques des formules utilisées et les contraintes d'utilisation des bits/octets et des systèmes de base dix, qui dépendent des valeurs à virgule flottante, qui sont tronquées et écrêtées.
Le point auquel vous voudriez penser à agrandir, c'est quand vous commencez à voir de nombreuses collisions qui ne peuvent pas être "confirmées" comme "originales". (Quand ils ont tous deux la même taille de données, et (lorsqu'ils sont testés en arrière, ils ont un CRC correspondant. Reverse/byte ou reverse/bits, ou bits-offsets)
En tout état de cause, il ne doit JAMAIS être utilisé comme SEULE forme de comparaison, juste pour une forme de comparaison rapide, pour l'indexation.
Vous pouvez utiliser un CRC-8 pour indexer l'ensemble d'Internet et tout diviser en l'une des N-catégories. Vous VOULEZ ces collisions. Maintenant, avec ceux pré-triés, vous n'avez qu'à vérifier l'un des N-répertoires, à la recherche de "taille de fichier", ou "reverse-CRC", ou toute autre comparaison que vous pouvez faire pour cet ensemble de données plus petit, rapidement. ..
Faire un CRC-32 en avant et en arrière sur le même blob de données est plus fiable que d'utiliser le CRC-64 dans une seule direction. (Ou un MD5, d'ailleurs.)
Le CRC doit être choisi spécifiquement pour la longueur des messages, il ne s'agit pas seulement de la taille du CRC: http://www.ece.cmu.edu/~ koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf