Attaque à texte clair connu : déduire une clé XOR répétée à partir d'un mot probable

Tous les autres exercices XOR vous donnent la clé et vous demandent de l'appliquer. Celui-ci vous prive de la clé, ce qui transforme la question du décodage en cryptanalyse. Le point d'entrée est l'identité la plus utile de toute la cryptographie symétrique : XOR s'annule lui-même, donc si ciphertext = plaintext XOR key, alors ciphertext XOR plaintext = key.

C'est ce réarrangement qui rend le texte clair connu si dangereux. Vous n'avez pas besoin du message entier, seulement d'un fragment. Les formats structurés vous offrent ce fragment gratuitement : les charges JSON, les en-têtes de fichiers, les bannières de protocole et le texte type des e-mails commencent tous de façon prévisible. Ici, le fournisseur indique dans sa documentation que chaque bloc de provisionnement s'ouvre par {\"vpn_user\":, soit douze octets connus.

Décodez l'hexadécimal en octets bruts, puis faites un XOR avec ces douze caractères. Sur la zone connue, le texte clair s'annule et la clé apparaît. La sortie affiche Gl4c13rGl4c1 : la clé Gl4c13r, suivie de ses cinq premiers caractères répétés. Cette répétition n'est pas du bruit, c'est la mesure elle-même. Le motif recommence après sept caractères, donc la clé fait sept octets de long, et c'est précisément parce que le mot probable est plus long que la clé que celle-ci peut être retrouvée en entier plutôt qu'en partie.

Au-delà du douzième octet, la sortie se dégrade en bruit, car l'atelier continue d'appliquer votre mot probable en boucle contre du chiffré réel dont vous ne connaissiez pas le texte clair. Cette transition marque la limite de ce que vous saviez réellement. Remplacer la clé par Gl4c13r déchiffre alors le bloc entier, ce qui constitue l'étape de vérification.

• Essayer de forcer la clé par force brute. Une phrase secrète alphanumérique de sept caractères représente un espace bien trop grand à deviner, et le mot probable rend cette approche inutile.
• Faire un XOR sur le texte hexadécimal au lieu des octets. From Hex doit venir en premier, sinon vous faites un XOR sur les caractères ASCII des chiffres hexadécimaux.
• Lire au-delà du mot probable. Seuls les douze premiers caractères de la sortie XOR avec le mot probable ont un sens, tout ce qui suit est du bruit par construction.
• Soumettre la répétition entière. Gl4c13rGl4c1 est la clé répétée. La clé elle-même est l'unité de sept caractères Gl4c13r.
• Soumettre le bloc déchiffré. La question demande la phrase secrète, pas le JSON qu'elle déverrouille.
• Se tourner vers Vigenère. Celui-ci ne transforme que les lettres et laisserait intacts la ponctuation et les chiffres du JSON.

Le XOR à clé répétée est de l'obfuscation, pas du chiffrement, et un texte clair connu le démonte en une seule étape. Tout élément prévisible dans le format de vos messages devient un oracle de récupération de clé.

• Ne protégez jamais des secrets avec un XOR contre une phrase secrète statique. Utilisez un chiffrement authentifié comme AES-GCM ou ChaCha20-Poly1305.
• Dérivez les clés avec une KDF adaptée et n'intégrez jamais de phrase secrète dans un logiciel client, où elle est récupérable par définition.
• Gardez à l'esprit qu'une clé plus courte qu'un préfixe prévisible est entièrement récupérable, la longueur de la clé et la structure du message sont donc des problèmes liés.
• Pour le provisionnement en particulier, délivrez des identifiants de courte durée depuis un serveur plutôt que d'embarquer une graine longue durée dans un bloc côté client.
• Traitez une graine OTP comme équivalente au second facteur lui-même. Récupérer ce bloc met en échec le MFA qu'il était censé renforcer.