Fichier contenant sa propre sum de contrôle

Est-il possible de créer un fichier qui contiendra sa propre sum de contrôle (MD5, SHA1, peu importe)? Et pour contrarier les jokers, je veux dire le total de contrôle en clair, pas le calculer.

J’ai créé un morceau de code en C, puis j’ai exécuté bruteforce pendant moins de 2 minutes et j’ai eu cette merveille:

The CRC32 of this ssortingng is 4A1C449B 

Notez qu’il ne doit y avoir aucun caractère (fin de ligne, etc.) après la phrase.

Vous pouvez le vérifier ici: http://www.crc-online.com.ar/index.php?d=The+CRC32+of+this+ssortingng+is+4A1C449B&en=Calcular+CRC32

Celui-ci est aussi amusant:

 I killed 56e9dee4 cows and all I got was... 

Code source (désolé, c’est un peu désordonné) ici: http://www.latinsud.com/pub/crc32/

Oui. C’est possible, et c’est commun avec les sums de contrôle simples. Obtenir un fichier pour inclure son propre md5sum serait très difficile.

Dans le cas le plus simple, créez une valeur de sum de contrôle qui fera que le module additionné sera égal à zéro. La fonction de sum de contrôle devient alors quelque chose comme

 (n1 + n2 ... + CRC) % 256 == 0 

Si la sum de contrôle devient alors une partie du fichier et est vérifiée elle-même. L’ algorithme Luhn utilisé dans les numéros de carte de crédit en est un exemple très courant. Le dernier chiffre est un chiffre de contrôle et fait lui-même partie du numéro à 16 chiffres.

Vérifie ça:

 echo -e '#!/bin/bash\necho My cksum is 918329835' > magic 

“Je souhaite que mon crc32 soit 802892ef …”

Eh bien, je pensais que c’était intéressant alors aujourd’hui, j’ai codé un petit programme Java pour trouver des collisions. Je pensais le laisser ici au cas où quelqu’un le trouverait utile:

 import java.util.zip.CRC32; public class Crc32_recurse2 { public static void main(Ssortingng[] args) throws InterruptedException { long endval = Long.parseLong("ffffffff", 16); long startval = 0L; // startval = Long.parseLong("802892ef",16); //uncomment to save yourself some time float percent = 0; long time = System.currentTimeMillis(); long updates = 10000000L; // how often to print some status info for (long i=startval;i 

Le résultat:

 49.825756% through - done 2140M so far - 1731000 tested per second - 1244s till the last value. 50.05859% through - done 2150M so far - 1770000 tested per second - 1211s till the last value. Match found!!! Message is: I wish my crc32 was 802892ef... crc32 of message is 802892ef 

Notez que les points à la fin du message font en réalité partie du message.

Sur mon i5-2500, il fallait environ 40 minutes pour rechercher tout l'espace crc32 de 00000000 à ffffffff, soit environ 1,8 million de tests / seconde. Il était au maximum un kernel.

Je suis assez nouveau avec java, donc tout commentaire constructif sur mon code serait apprécié.

"Mon crc32 était c8cb204, et tout ce que j'ai eu était ce t-shirt moche!"

Certes, c’est possible. Mais l’une des utilisations des sums de contrôle est de détecter la falsification d’un fichier – comment savoir si un fichier a été modifié, si le modificateur peut également remplacer la sum de contrôle?

Bien sûr, vous pouvez concaténer le résumé du fichier lui-même à la fin du fichier. Pour le vérifier, vous devez calculer le résumé de toutes les parties sauf la dernière partie, puis le comparer à la valeur de la dernière partie. Bien sûr, sans une forme de chiffrement, n’importe qui peut recalculer le condensé et le remplacer.

modifier

Je dois append que ce n’est pas si inhabituel. Une technique consiste à concaténer un CRC-32 de sorte que le CRC-32 de tout le fichier (y compris ce résumé) soit égal à zéro. Cela ne fonctionnera pas avec les résumés basés sur les hachages cryptographiques.

Je ne sais pas si je comprends bien votre question, mais vous pourriez faire les 16 premiers octets du fichier la sum de contrôle du rest du fichier.

Donc, avant d’écrire un fichier, vous calculez le hachage, écrivez d’abord la valeur de hachage, puis écrivez le contenu du fichier.

Si la question est de savoir si un fichier peut contenir sa propre sum de contrôle (en plus des autres contenus), la réponse est sortingvialement oui pour les sums de contrôle de taille fixe, car un fichier peut contenir toutes les valeurs de sum de contrôle possibles.

Si la question est de savoir si un fichier pourrait être composé de sa propre sum de contrôle (et de rien d’autre), il est sortingvial de construire un algorithme de sum de contrôle qui rendrait un tel fichier impossible: pour une sum de contrôle de n octets, du fichier et append 1. Puisqu’il est également sortingvial de construire une sum de contrôle qui se code toujours elle-même (c.-à-d. faire le dessus sans append 1), il est évident que certaines sums de contrôle peuvent se coder et d’autres pas . Il serait probablement très difficile de dire lequel de ces coefficients est une sum de contrôle standard.

Il existe une implémentation soignée de l’ Luhn Mod N dans la bibliothèque python-stdnum ( voir luhn.py ). La fonction calc_check_digit calculera un chiffre ou un caractère qui, ajouté au fichier (exprimé sous forme de chaîne), créera une chaîne Luhn Mod N valide. Comme indiqué dans de nombreuses réponses ci-dessus, cela permet de vérifier la validité du fichier, mais il n’ya pas de sécurité significative contre la falsification. Le destinataire devra savoir quel alphabet est utilisé pour définir la validité du modn Luhn.

Vous pouvez bien sûr, mais dans ce cas, le résumé SHA du fichier entier ne sera pas le SHA que vous avez inclus, car il s’agit d’une fonction de hachage cryptographique. Changer un seul bit dans le fichier modifie le hachage complet. Ce que vous recherchez est une sum de contrôle calculée à l’aide du contenu du fichier afin de correspondre à un ensemble de critères.

Sûr.

Le moyen le plus simple serait d’exécuter le fichier via un algorithme MD5 et d’intégrer ces données dans le fichier. Vous pouvez diviser la sum de contrôle et la placer à des points connus du fichier (en fonction de la taille du fichier, par exemple 30%, 50%, 75%) si vous souhaitez la masquer.

De même, vous pouvez chiffrer le fichier ou chiffrer une partie du fichier (avec la sum de contrôle MD5) et l’intégrer dans le fichier. Modifier J’ai oublié de dire que vous deviez supprimer les données de sum de contrôle avant de les utiliser.

Bien sûr, si votre fichier doit être facilement lisible par un autre programme, par exemple Word, les choses deviennent un peu plus compliquées car vous ne voulez pas “corrompre” le fichier pour qu’il ne soit plus lisible.

Il existe plusieurs manières d’intégrer des informations pour détecter des erreurs de transmission, etc. Les sums de contrôle CRC sont efficaces pour détecter des exécutions de flips consécutifs et peuvent être ajoutées de telle manière que la sum de contrôle est toujours égale à 0. codes correcteurs) sont cependant faciles à recréer et n’arrêtent pas les manipulations malveillantes.

Il est impossible d’incorporer quelque chose dans le message afin que le destinataire puisse vérifier son authenticité si le destinataire ne connaît rien d’autre de l’expéditeur. Le destinataire pourrait par exemple partager une clé secrète avec l’expéditeur. L’expéditeur peut alors append une sum de contrôle chiffrée (qui doit être sécurisée de manière cryptographique telle que md5 / sha1). Il est également possible d’utiliser un chiffrement asymésortingque où l’expéditeur peut publier sa clé publique et signer la sum de contrôle / hachage md5 avec sa clé privée. Le hachage et la signature peuvent alors être étiquetés sur les données en tant que nouveau type de sum de contrôle. Cela se fait tout le temps sur internet de nos jours.

Les problèmes restants sont alors 1. Comment le destinataire peut-il être sûr d’avoir la bonne clé publique et 2. Dans quelle mesure tout cela est-il sécurisé? La réponse à 1 peut varier. Sur Internet, il est courant d’avoir la clé publique signée par quelqu’un en qui tout le monde a confiance. Une autre solution simple est que le destinataire a obtenu la clé publique d’une réunion en personne … La réponse à 2 pourrait changer de jour en jour, mais ce qui est coûteux à forcer au jour sera probablement bon marché pour briser un peu le futur . À ce moment-là, de nouveaux algorithmes et / ou des tailles de clé plus grandes ont émergé.