Smith440040
Messages postés dimanche 25 janvier 2009Date d'inscription
20 août 2009
Dernière intervention
-
11 juil. 2009 à 16:45 - Dernière réponse : Bacterius3869
Messages postés samedi 22 décembre 2007Date d'inscription
3 juin 2016
Dernière intervention
- 20 août 2009 à 18:32
slt,
j'ai trop chercher mais j'ai pas trouvé auccune choses sur le "Checksum 32 bit" et pas "CRC32" pouvez-vous m'aider???
Je cherche une fonction pour faire cette calcule, je peux la faire avec Hexworkshop
>> selectioner les données puis "Tools" puis "Generate checksum" puis le 3 eme choix "Checksum 32 bit"
mais comment faire ça sous Delphi??
merci
On a aussi des checksums sur 128, 256, 512 et même 1024 octets (même si les deux derniers soulèvent des questions légitimes de stockage : le hash du mot de passe est plus long que le mot de passe lol).
Un checksum est basé sur un algorithme déterministe bien défini. Pour le CRC32, f0xi a réécrit l'algorithme pour le calculer en Delphi. Il te suffit d'aller voir la source citée par jlen100 ...
Tu peux même créer ton propre algorithme non cryptographique si tu y tiens, la plupart des algos fait maison suffisent pour faire un checksum non cryptographique.
SNARPORY8
Messages postés mardi 13 février 2007Date d'inscription
10 août 2009
Dernière intervention - 7 août 2009 à 19:41
0
Merci
Je viens de faire une réponse identique à un autre message ( désolé pour la redifussion )
Comme son nom l'indique le Checksum32 est une valeur résultante sur 32 bits permettant de vérifier l'intégrité d'un ensemble de valeur.
Toutefois cette vérification est très simpliste et n'apporte qu'un niveau d'intégrité très limitée.
Pour s'en persuader, il suffit d'utiliser un nombre restreint de donnée ce qui permet de vérifier la valeur très aisément.
Exemple soit les caractères 1 2 3 4 5 ( ne pas mettre d'espace car cela reviendrai à ajouter d'autre valeurs ), le Checksum32 fourni pas un éditeurHexadécimal sera $000000A5, ( le checksum 32 est donc une simple addition modulo 2^32 de l'ensemble des données )( ceci a été vérifier avec plusieurs éditeurHéxadécimal mais pas avec celui faisant l'objet du message car je ne l'avais pas sous la main ! ), les mêmes valeurs dans un ordre différent donneront exactement le même résultat, et les caractères 1 2 1 2 9 ( toujours sans espece ) donneront également le même résultat.
Ceci semble contredire la définition sur Wikipédia qui indique le checksum32 comme un CRC,
car un CRC est un algorithme polynomial ( formule de calcul basé sur un polynome )
et le checksum n'a pas de polynome.
De plus, un CRC ne donne pas le même résultat pour un ensemble de valeur identique mais dans un ordre différent
le Checksum32 est une valeur résultante sur 32 bits permettant de vérifier l'intégrité d'un ensemble de valeur.
C'est quoi pour toi un "ensemble de valeurs" ? Pour moi ça représente un ensemble de définition (R, Z, les nombres premiers, ...). Le terme "donnée" serait plus approprié.
Toutefois cette vérification est très simpliste et n'apporte qu'un niveau d'intégrité très limitée.
Effectivement, selon le paradoxe des anniversaires, il suffit de 65536 calculs (que dalle, quoi) pour avoir 50% de chances de trouver une collision (deux données qui donnent la même valeur).
le checksum 32 est donc une simple addition modulo 2^32 de l'ensemble des données
Hou la la stop stop !! Non non et non ! Si c'était le cas, alors les données ($12, $21) et ($21, £12) auraient le même checksum. Et là autant dire que ça ne sert à rien. Les propriétés mathématiques des checksums ont beau être simples, c'est quand même plus évolué que ça ! Sauf si l'on utilise un checksum "rudimentaire".
Ceci semble contredire la définition sur Wikipédia qui indique le checksum32 comme un CRC
Ouf ça pique. Un checksum est une "somme de contrôle", qui sert à représenter des données de façon très réduite, afin d'en faciliter la comparaison, le stockage, etc ... Un CRC est un type de checksum, qui est conçu pour être utilisé sur des données de taille moyenne (supérieure à 1 Ko, mais pas au-delà de 2 Go).
De plus, un CRC ne donne pas le même résultat pour un ensemble de valeur identique mais dans un ordre différent
Je ne comprends absolument rien
________________________________
Je donne donc mon petit texte :
Un checksum est une somme de contrôle permettant de vérifier l'intégrité d'une donnée. Sa particularité réside dans le fait qu'il doit être difficile de trouver deux données résultant en un même checksum. Cependant, comme il doit pouvoir être rapidement calculé, sa complexité en souffre. Il utilise des propriétés mathématiques peu complexes, ce qui rend toute utilisation cryptographique d'un checksum aberrante, mais ces propriétés sont largement suffisantes pour la plupart des utilisations qu'on en fait (deux données ayant la même somme de contrôle ont très peu de chances d'être un jour confrontées). Son utilisation au niveau cryptographique, citée plus haut, est inutile, d'abord au visu de la faiblesse de ses propriétés mathématiques, mais également de son ensemble final, souvent limité à 32 bits pour un calcul plus rapide et un espace de stockage réduit. Ce qui fait que d'après le paradoxe des anniversaires, qui démontre qui pour tout ensemble restreint E d'une amplitude de X, et où chaque valeur de E est associé à une valeur aléatoire N (d'ensemble E, bien sûr), il suffit de Racine(X) calculs pour avoir une probabilité de 50% d'obtenir deux données associées à la même valeur N Dans notre cas, l'ensemble E a une amplitude de 2^32, il suffit alors de Racine(2^32) 2^16 65536 calculs. Ce qui représente moins d'un millième de seconde de travail sur un ordinateur moderne. Voilà pour son utilisation cryptographique. Nous pouvons donc conclure que le checksum est très utile dans la plupart des applications, citons par exemple WinZip (qui ne s'est jamais demandé ce que représentaient les 8 petits caractères dans la dernière colonne ?), pour vérifier rapidement si le fichier a eu un problème lors de sa décompression, mais qu'il présente néanmoins des limites importantes. Les applications modernes utilisent à présent des checksum 64, voire 128 bits, où alors basculent carrément dans les fonctions de hashage cryptographique (MD5, SHA, Whirlpool, RIPEMD, Tiger, Panama, ...), qui sont nettement plus sûres que les checksums.
Désolé pour le pavé, surtout que ce texte n'a pas vraiment de problématique (comme il n'y avait rien, j'ai opté pour "Définition du checksum").
SNARPORY8
Messages postés mardi 13 février 2007Date d'inscription
10 août 2009
Dernière intervention -10 août 2009 à 22:49
0
Merci
Effectivement bacterius le terme donnée est plus approprié,j'ai écris le message trop rapidement!
Mais, comme je l'ai visiblement mal expliqué précédemment les données $21 et $12 donne le même checksum_32 que les données $12 et $21 ( sur l'éditeur hexadécimal que j'ai sous la main au moins c'est le cas car cela donne $33 ! )
lorsque j'utilise le terme CRC je pense à un CRC16 ou CRC32 par exemple
Le programme de f0xi donne une très bonne réponse !
Mais, comme je l'ai visiblement mal expliqué précédemment les données $21 et $12 donne le même checksum_32 que les données $12 et $21 ( sur l'éditeur hexadécimal que j'ai sous la main au moins c'est le cas car cela donne $33 !
Ca dépend de l'algorithme. Si il s'agit d'une simple addition modulaire, alors oui, mais regarde, en CRC, MD5, SHA, Whirlpool, Panama, Tiger, LEA, MD6, SHA2, ... ça donnera bien quelque chose de différent
Non j'ai dû en oublier plein (CubeHash, MD2, MD4 (lol), Square, etc ...)
Et LEA ne devrait même pas être dans la liste, mais je le mets comme ça pour le fun
f0xi4304
Messages postés samedi 16 octobre 2004Date d'inscription
9 mars 2018
Dernière intervention -11 août 2009 à 15:29
0
Merci
@bacterius :
facile de faire un XOR, AND ou OR de tête :
A : 01110101 : $75
B : 10110011 : $B3
A and B = 00110001 : $31
A or B = 11110111 : $F7
A xor B = 11000110 : $C6
A shr 3 = 00001110 : $0E
A shl 4 = 01010000 : $50
B shr 2 = 00101100 : $2C
B shl 3 = 10011000 : $98
A rol 5 = 10101110 : $AE
B ror 3 = 10011101 : $9D
piv A = 10111010 : $BA
piv B = 01110011 : $73
A + B = 100101000: $128
c'est surtout le modulo qui fait sué :)
A mod B (de tête) ... heu ... $75 mod $B3 $75
B mod A (toujours) $B3 mod $75 $3D (surement)
a aidé 92 internautes ce mois-ci