URL: https://linuxfr.org/users/scandisk/journaux/cryptographie-un-article-de-vulgarisation Title: Cryptographie : un article de vulgarisation Authors: scand1sk Date: 2005年02月05日T00:29:03+01:00 Tags: enigma et turing Score: 0 Hop, pour un premier journal, un journal que j'espère utile. En passant sur un forum d'amateurs d'Histoire, je suis passé sur un topic parlant de la cryptographie lors de la seconde guerre mondiale (Enigma, Turing/Rejewski, toussa). Je me suis emballé et j'ai rapidement rédigé une réponse de mémoire, exposant mes connaissances d'amateur sur la cryptographie moderne. La réponse est rapidement devenue assez conséquente, et je me demande si elle ne pourrait pas servir de base à un article de vulgarisation plus complet. Je m'auto-cite :
Alan Turing est un personnage très intéressant et on le considère comme un des pères fondateurs des théories de l'Intelligence Artificielle et de la science de l'informatique fondamentale en général. En particulier, il a démontré qu'il existait des problèmes pour lesquels aucun algorithme ne trouverait jamais de solution (ce sont des problèmes indécidables). Il existe aussi des problèmes pour lesquels la durée d'exécution de l'algorithme évolue exponentiellement avec le nombre d'informations. Ces problèmes sont au coeur de la cryptographie moderne. Ainsi, si un programme met 2 secondes à casser une clé 8 bits (généralement en essayant toutes les clés possibles, les algorithmes de cryptage étant a priori mathématiquement conçus pour ne pas permettre d'autre méthode), il mettra 4 secondes à casser une clé 9 bits, 8 secondes à casser une clé 10 bits... A 16 bits, on en est déjà à 8 minutes, à 24 bits à 36 heures... A 128 bits, il faudrait un milliard de milliards de milliards d'années de calculs pour "casser" le cryptage ! On sent bien que l'augmentation de puissance des ordinateurs n'est pas une solution suffisante au décryptage... D'ailleurs ils est très facile d'augmenter la taille des clés. Une propriété très importante de ces algorithmes est que même en en connaissant parfaitement les rouages, il est impossible de décrypter des messages sans disposer de la clé de décryptage. Le problème, c'est que personne n'a réussi à démontrer mathématiquement que ce type de problèmes exponentiels existait ! Ou plutôt, on connaît des problèmes qu'on ne sait résoudre que de cette manière, mais personne n'a réussi à démontrer qu'il n'existerait pas une méthode susceptible de résoudre ces problèmes sans augmentation exponentielle des temps de calcul. Trouver de tels algorithmes est le travail de la majorité des chercheurs en intelligence artificielle aujourd'hui (ces algorithmes ont d'ailleurs des applications ailleurs qu'en cryptographie). De plus, face à un message crypté, il existe des méthodes basées sur les statistiques susceptibles d'aider au décryptage des messages. Cacher les messages cryptés dans des documents anodins (données musicales, images...) permet de renforcer encore la protection. D'autre part, même en supposant qu'on ait le moyen d'avoir des algorithmes de cryptage totalement incassables, la gestion des clés de cryptage et de décryptage est également quelque chose de très complexe. Actuellement, la plupart des méthodes de cryptage utilisent un système de "double clés", publique et privée. La clé publique permet de cryptage de message, et la clé privée en permet de décryptage. La clé publique est générée à partir de la clé privée, et il est normalement impossible de retrouver la clé privée à partir de la clé publique (en fait le problème est le même que pour le décryptage lui même, voir paragraphe ci dessus). De cette façon, la clé publique peut être envoyée à tout le monde sans problème, et vous serez le seul à pouvoir lire les messages codés avec la clé publique. Ce système de paire de clés permet également la "signature numérique" des messages : à partir du contenu du message et de la clé privée, on génère une "signature". Avec la clé publique, on peut vérifier que la signature n'a pu être réalisée qu'à partir de la clé privée. Ainsi, on est sûr que le message provient bien du possesseur de la clé privée associée à la clé publique dont on dispose. Il existe même des systèmes permettant de se prémunir contre les fausses clés (si je publie une clé publique en me faisant passer pour quelqu'un d'autre, je pourrais facilement signer des messages à son nom).Je sollicite l'avis des mou^W linuxéfèriens avisés, pour corriger les grosses coquilles (et en même temps parfaire mes connaissances sur le sujet). N'oubliez pas que je destine ce texte plutôt à un article de vulgarisation, mais à titre personnel je suis ouvert aux détails techniques. Pour info, les informations sur la complexité des algorithmes, et notamment l'absence de démonstration P=NP provient de plus ou moins vagues souvenirs d'un DEA d'IA, et la partie concernant les clé, de l'installation et configuration d'Enigmail (oui, j'ai pas été chercher bien loin). Et si ça intéresse quelqu'un, je mets la partie entre "blockquote" sous licence FDL. Là. P.S. Ah tiens, le correcteur orthographique de LinuxFR me rappelle qu'on dit "chiffrage" et non pas "cryptage". Je pourrais le corriger, mais ça serait long, et ça permettra de le rappeler.