Quel est le problème avec le cryptage XOR?
J'ai écrit un court programme C++ pour faire XOR sur un fichier, que je peux utiliser pour certains fichiers personnels (s'il est fissuré, ce n'est pas grave - je ne fais que me protéger contre les téléspectateurs occasionnels) En gros, je prends un mot de passe ASCII et à plusieurs reprises XOR le mot de passe avec les données dans le fichier.
Maintenant, je suis curieux, cependant: si quelqu'un voulait résoudre ce problème, comment s'y prendrait-il? Cela prendrait-il beaucoup de temps? Cela dépend-il de la longueur du mot de passe (c'est-à-dire quel est le big-O)?
Le problème avec le cryptage XOR est que pour les longues exécutions des mêmes caractères, il est très facile de voir le mot de passe. Ces longues exécutions sont le plus souvent des espaces dans les fichiers texte. Disons que votre mot de passe est de 8 caractères et le fichier texte comporte 16 espaces sur une ligne (par exemple, au milieu du tableau graphique ASCII). Si vous venez de XOR avec votre mot de passe, vous verrez que la sortie ont des séquences de caractères récurrentes. L'attaquant recherchait simplement un tel, essayait de deviner le caractère dans le fichier d'origine (l'espace serait le premier candidat à essayer), et dériverait la longueur du mot de passe de la longueur des groupes répétitifs.
Les fichiers binaires peuvent être encore pires car ils contiennent souvent des séquences répétitives de 0x00 octets. De toute évidence, XORing avec ceux-ci est sans opération, donc votre mot de passe sera visible en texte brut dans la sortie! Un exemple de format binaire très courant comportant de longues séquences de valeurs nulles est .doc.
Je suis d'accord avec Pavel Minaevexplication des faiblesses de XOR. Pour ceux qui sont intéressés, voici un aperçu de base de l'algorithme standard utilisé pour briser le chiffrement trivial XOR en quelques minutes:
Déterminez la longueur de la clé. Cela se fait en XORant les données chiffrées avec elles-mêmes décalé plusieurs nombres de places, et en examinant combien d'octets sont les mêmes.
Si les octets égaux sont supérieurs à un certain pourcentage (6% selon la deuxième édition de Bruce Schneier Applied Cryptography ), alors vous avez décalé les données de un multiple de la longueur de clé. En trouvant la plus petite quantité de décalage qui se traduit par une grande quantité d'octets égaux, vous trouvez la longueur de clé.
Décaler le texte chiffré de la longueur de clé, et XOR contre lui-même. Cela supprime la clé et vous laisse avec le texte en clair XORed avec le texte en clair décalé la longueur de la clé. Il devrait y avoir suffisamment de texte en clair pour déterminer le contenu du message.
En savoir plus sur Questions de chiffrement, partie 1
Le chiffrement XOR peut être raisonnablement * fort si les conditions suivantes sont remplies:
- Le texte brut et le mot de passe ont à peu près la même longueur.
- Le mot de passe n'est pas réutilisé pour crypter plusieurs messages.
- Le mot de passe ne peut pas être deviné, IE par dictionnaire ou par d'autres moyens mathématiques. En pratique, cela signifie que les bits sont randomisés.
* Sens raisonnablement fort, il ne peut pas être brisé par des moyens mathématiques triviaux, comme dans le post de GeneQ. Il n'est toujours pas plus fort que votre mot de passe.
En plus des points déjà mentionnés, le cryptage XOR est complètement vulnérable aux attaques en texte clair connues:
cryptotext = plaintext XOR key
key = cryptotext XOR plaintext = plaintext XOR key XOR plaintext
où XORring les textes en clair s'annulent, ne laissant que la clé.
Le fait de ne pas être vulnérable aux attaques de texte en clair connu est une propriété requise mais pas suffisante pour toute méthode de chiffrement "sécurisé" où la même clé est utilisée pour plus d'un bloc de texte en clair (c'est-à-dire qu'un tampon à usage unique est toujours sécurisé).
Façons de faire fonctionner XOR:
Utilisez plusieurs clés avec chaque longueur de clé égale à un nombre premier mais jamais la même longueur pour les clés. Utilisez le nom de fichier d'origine comme une autre clé, mais n'oubliez pas de créer un mécanisme pour récupérer le nom de fichier. Créez ensuite un nouveau nom de fichier avec une extension qui vous fera savoir qu'il s'agit d'un fichier crypté. La raison de l'utilisation de plusieurs clés de longueur en nombre premier est qu'elles entraînent la longueur de la clé XOR) à la clé A TIMES clé B en longueur avant qu'elle ne se répète. Compressez tous les motifs répétitifs du fichier avant il est crypté. Générez un nombre aléatoire et XOR ce nombre tous les X Offset (N'oubliez pas, ce nombre doit également être recréable. Vous pouvez utiliser un RANDOM SEED de la longueur de fichier).
Après avoir fait tout cela, si vous utilisez 5 clés de longueur 31 et plus, vous vous retrouverez avec une longueur de clé d'environ cent mégas!
Pour les clés, le nom de fichier étant un (y compris le chemin d'accès complet), STR (taille de fichier) + STR (Filedate) + STR (date) + STR (heure), clé de génération aléatoire, votre nom complet, une clé privée créée une seule fois.
Une base de données pour stocker les clés utilisées pour chaque fichier crypté mais conserver le fichier DAT sur une clé USB et NON sur l'ordinateur.
Cela devrait empêcher le motif répétitif sur des fichiers comme Images et Musique, mais les films, d'une longueur de quatre concerts ou plus, peuvent toujours être vulnérables et peuvent donc nécessiter une sixième clé.
Personnellement, le fichier dat est chiffré lui-même sur la clé USB (fichier Dat à utiliser avec Microsoft Access). J'ai utilisé une méthode à 3 clés pour le crypter car il ne sera jamais aussi grand, étant un répertoire des fichiers avec les clés associées.
La raison de plusieurs clés plutôt que de générer aléatoirement une très grande clé est que les nombres premiers multiplient rapidement et j'ai un certain contrôle sur la création de la clé et vous SAVEZ qu'il n'y a vraiment pas de nombre vraiment aléatoire. Si j'ai créé un grand nombre aléatoire, quelqu'un d'autre peut générer ce même nombre.
Méthode d'utilisation des clés: crypter le fichier avec une clé, puis la suivante, puis la suivante jusqu'à ce que toutes les clés soient utilisées. Chaque clé est utilisée maintes et maintes fois jusqu'à ce que le fichier entier soit chiffré avec cette clé.
Étant donné que les clés sont de longueur différente, le chevauchement de la répétition est différent pour chaque clé et crée ainsi une clé dérivée de la longueur de la clé une fois la clé deux. Cette logique se répète pour le reste des touches. La raison des nombres premiers est que la répétition se produirait sur une division de la longueur de clé, vous voulez donc que la division soit 1 ou la longueur de la clé, hense, prime.
OK, d'accord, c'est plus qu'un simple XOR sur le fichier mais le concept est le même.
Lance
Je protège juste contre les téléspectateurs occasionnels
Tant que cette hypothèse est vérifiée, votre schéma de cryptage est correct. Les gens qui pensent qu'Internet Explorer est "les internets" ne sont pas capables de le casser.
Sinon, utilisez simplement une bibliothèque de chiffrement. Il existe déjà de nombreux bons algorithmes comme Blowfish ou AES pour la cryptographie symétrique.
L'objectif d'un bon cryptage est de rendre mathématiquement difficile à décrypter sans la clé.
Cela inclut le désir de protéger la clé elle-même.
Le technique XOR est fondamentalement un chiffrement très simple facilement cassé comme décrit ici.
Il est important de noter que XOR est utilisé dans algorithmes cryptographiques .
Ces algorithmes travaillent sur l'introduction de difficultés mathématiques autour de lui.
L'antivirus de Norton utilisait une technique consistant à utiliser la lettre non chiffrée précédente comme clé de la lettre suivante. Cela m'a pris une demi-heure supplémentaire pour comprendre, si je me souviens bien.
Si vous voulez simplement arrêter le spectateur occasionnel, c'est assez bien; J'ai utilisé pour cacher des chaînes dans les exécutables. Cependant, cela ne résistera pas 10 minutes à quiconque essaie réellement.
Cela dit, de nos jours, il existe de bien meilleures méthodes de cryptage, alors pourquoi ne pas vous prévaloir de quelque chose de mieux. Si vous essayez de vous cacher de l'utilisateur "occasionnel", même quelque chose comme gzip ferait mieux ce travail.
Une autre astuce consiste à générer un hachage md5 () pour votre mot de passe. Vous pouvez le rendre encore plus unique en utilisant la longueur du texte protégé comme décalage ou en le combinant avec votre mot de passe pour fournir une meilleure distribution des phrases courtes. Et pour les phrases longues, faites évoluer votre hachage md5 () en combinant chaque bloc de 16 octets avec le hachage précédent - ce qui rend la clé XOR entière "aléatoire" et non répétitive).
RC4 est essentiellement XOR! Comme beaucoup de chiffrements de flux - la clé est la clé (sans jeu de mots!) Vous ne devez JAMAIS réutiliser la clé. JAMAIS!
Je suis un petit tard dans la réponse, mais comme personne ne l'a encore mentionné: c'est ce qu'on appelle un chiffre Vigenère.
Wikipedia donne un certain nombre de attaques de cryptanalyse pour le casser; encore plus simple, cependant, puisque la plupart des formats de fichiers ont un en-tête fixe, ce serait XOR l'en-tête en clair avec l'en-tête chiffré, vous donnant la clé.
Que "> 6%" mentionne GeneQ est l'indice de coïncidence pour le texte télégraphique anglais - 26 lettres, avec ponctuation et chiffres épelés. La valeur réelle pour les textes longs est de 0,0665.
Le <4% est l'indice de coïncidence pour le texte aléatoire dans un alphabet à 26 caractères, qui est 1/26, ou 0,385.
Si vous utilisez une langue ou un alphabet différent, les valeurs spécifiques seront différentes. Si vous utilisez le jeu de caractères ASCII, Unicode ou octets binaires, les valeurs spécifiques seront très différentes. Mais la différence entre l'IC du texte en clair et du texte aléatoire sera généralement présente. ( Les binaires compressés peuvent avoir des CI très proches de ceux de random, et tout fichier chiffré avec un chiffrement informatique moderne aura un CI qui est exactement celui d'un texte aléatoire.)
Une fois que vous avez XOR le texte contre lui-même, ce qui vous reste est équivalent à un chiffrement autokey. Wikipédia a un bon exemple pour briser un tel chiffre