Et ? Ça ne le rend pas inviolable pour autant…
Le seul chiffrement dont on peut avoir la certitude qu’il est inviolable, c’est un chiffrement symétrique ET dont la clé est au moins aussi longue que les données à chiffrer.
Si la clé est plus courte que le message, et en particulier si elle est vraiment beaucoup plus courte (ce qui est pratiquement toujours le cas, puisqu’on n’utilise rarement des clés de plus de quelques dizaines d’octets) :
- si c’est un chiffrement basique (type XOR ou autre truc du genre), on est vulnérable à des attaques statistiques/heuristiques. En particulier, si on ne prend pas la peine d’obfusquer le type des fichiers qu’on a chiffré (et également le nom d’ailleurs, car un nom de fichier peut donner des informations sur son type… « facture » a plus de chances d’être un PDF qu’un MP3…), le début de la clé peut être cassé très très vite… Par exemple sur un JPEG, on va casser instantanément les 48 premiers bits de la clé + jusqu’à 16 autres bits de la clé selon la taille du fichier (si n est la taille de la clé en octets, on casse les premiers 48 bits si la taille du fichier est comprise entre xn et xn + 6, les premiers 56 bits si la taille du fichier est xn+7, les premiers 64 bits si elle est xn+8 et les 48 premiers + 16 autres (et dont on connait la position) dans les autres cas).
- si c’est un chiffrement avec des fonctions mathématiques complexes conçues pour se protéger contre les attaques statistiques de base, on est exposé à un risque de faiblesse dans ces fonctions mathématiques, et il est assez prétentieux d’imaginer avoir écrit une telle fonction infaillible…
Dans ce second cas, il est beaucoup plus raisonnable et prudent d’utiliser des fonctions déjà réputées pour leur robustesse, par exemple AES, dont les plus performantes attaques connues à ce jour ne font gagner qu’un facteur ~10 par rapport à un brute force, plutôt que d’écrire soi même une fonction en s’imaginant être capable de faire mieux que des experts du domaine…
