Si le fichier est unicode / ansi / etc, vous pouvez créer un algorithme pour analyser quelque chose comme les 200 premiers caractères d'un fichier et voir s'il y a plus de caractères latins que d'autres caractères.
Je me souviens J'étais assez ennuyé quand j'ai essayé l'attaque par force brute XOR sur un simple exercice de projet euler, mais c'était facile et je devais juste chercher des mots anglais courants.
J'ai lu quelque part cela dans un logiciel de cryptage, la mise en œuvre est très importante, parfois plus importante que les alorithmes. Quand je lis cela, je me demande encore si on parle de sujets évidents comme les générateurs pseudo aléatoires, ou de détails plutôt moins évidents comme comment cacher le format du fichier que vous cryptez.
Par exemple, si vous cryptez un fichier, s'il s'agit d'un fichier PNG ou GIF, assurez-vous de supprimer le numéro / chaîne magique que ces formats de fichier contiennent, et s'il s'agit d'un fichier texte, n'utilisez pas de table ASCII: utilisez votre propre table de caractères, par exemple il suffit de mettre tous les caractères latins à 0, les nombres à 245-255, et ainsi de suite. vous pouvez également permutation, ou rot13, ou autre.
Les algorithmes tels que AES ou Blowfish / TwoFish sont "mathématiquement" sécurisés, car il a été prouvé qu'aucune attaque AUTRE QUE BRUTEFORCE n'a été testée comme suffisamment efficace: vous ne peut déchiffrer le texte qu'en trouvant la clé réelle.
Mais ces algorithmes ne sont efficaces que théoriquement, vous DEVEZ les implémenter en tenant compte d'autres facteurs pratiques tels que la taille du fichier, l'utilisation de la compression, l'encodage de texte, etc.
Par exemple, sachez qu'il serait tout simplement stupide de stocker le nom de fichier en texte brut à côté de votre fichier crypté.