Version 1.2 (2001/01/31)

Je ne suis pas un expert en cryptographie et ce document ne contient pas La Vérité. Ce texte a été écrit avec l’intention d’intéresser le lecteur au domaine de l’encryption et encourager l’utilisation de logiciels de cryptage. Pour une source plus complète sur le sujet de l’encryption, consultez la section « Références » à la fin de ce texte.

Vos commentaires et corrections seront grandement appréciés, par courier électronique à mathieu@no-spam.bidon.ca. Vous trouverez la version originale et les versions futures de ce texte à l’adresse suivante :

http://www.bidon.ca/

Vous pouvez librement redistribuer ce texte, en autant que vous respectez la « GNU Free Documentation License » :

Copyright (c) Mathieu Lutfy (mathieu@no-spam.bidon.ca) Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation ; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

Depuis toujours dans le monde de la cryptographie (dont le plus vieux cas documenté aujourd’hui remonte à l’Égypte ancienne), il y a deux clans : les faiseurs de codes et les briseurs de codes. Des gens inventent de nouveaux codes pour augmenter leur niveau de sécurité ou de vie privée et les briseurs de codes essaient d’obtenir l’information codée.

Historiquement, les gouvernements ont à la fois construit des codes pour assurer que leurs communications internes restent privées (monde diplomatique, militaires, etc..) et en même temps ils cassent les codes de leurs ennemis pour des raisons évidentes. La majorité des paysans avaient rarement besoin d’encoder leurs données, ils pouvaient simplement marcher 100 mètres dans la forêt et parler à voix basse pour avoir une conversation privée.

Plus la société évoluait, plus l’encodage devenait répandu. Par exemple, les journaux avaient souvent (au fait, beaucoup de journaux le font encore aujourd’hui) une section où les lecteurs pouvaient poster un court message personnel. Il était moins coûteux de poster une annonce personnelle dans un journal, que de poster une lettre entre deux villes. Évidemment, puisque le journal était diffusé à un énorme bassin de population, n’importe qui pouvait lire ces messages. Si un couple d’amoureux communiquaient clandestinement (sans l’accord de leurs parents) par les annonces personnelles du journal, ils pourraient facilement se faire prendre.. sauf s’ils encodaient leurs messages. C’est ainsi que des formes primitives d’encryption ont commencé à être adoptées par le grand public.

Évidemment, si le grand public pouvait encoder, le grand public pouvait aussi casser le code. Certains scientifiques connus du monde de l’encryption avaient la réputation d’utiliser leurs temps libres pour décoder les messages parus dans les journaux.

Pourquoi l’encryption est-elle aujourd’hui, aux yeux de la majorité, qu’une notion obscure ?

Le plus gros problème, historiquement, c’est que l’encryption a toujours été perçue comme étant un outil de guerre. Les gouvernements n’ont jamais été très chauds à l’idée de partager avec le public leurs découvertes en encryption sous prétexte que ça donnerait à leurs ennemis une arme. Après tout, si l’outil sert à protéger des secrets d’État, c’est une arme au même titre qu’une bombe. Ce que les gouvernements disent moins, c’est qu’ils font autant d’espionnage que leurs ennemis et c’est pour eux une opération essentielle. C’est un peu la philosophie qui est à la base des lois répressives sur l’exportation de l’encryption aux États-Unis. La raison pourquoi j’insiste sur ce point, c’est qu’il n’y a rien de criminel à encrypter des données, mais les gouvernements insistent à faire circuler une image de "citoyen méfiant et louche" s’il utilise des méthodes d’encryption. Curieusement, l’attitude de nombreux gouvernements commence à ressembler à 1984, roman bien connu de George Orwell qui, peu après sa publica- tion, était souvent distribué clandestinement par des pays démocratiques dans des pays où régnait un gouvernement dictateur.

Concrètement, pourquoi devriez-vous encrypter ? Tout simplement parce qu’une conversation destinée à être uniquement entre un nombre défini de personnes devrait le rester. Même si vous n’avez rien à cacher, ce n’est pas un prétexte pour donner une carte blanche à quiconque décide d’en savoir plus sur vous, phénomène qui devient de plus en plus accessible grâce à la numérisation des données qui rend la tâche de fouineurs plus facile.

L’encryption peut augmenter le niveau de sécurité dans vos échanges par courier électronique (e-mail), que ce soit pour assurer la confidentialité d’un message ou pour conserver son intégrité (éviter qu’il soit modifié en cours de route). Vous pouvez aussi générer des signatures digitales sur des documents numériques (texte, image, son, etc..) et même si le destinataire ne possède pas de logiciel d’encryption, n’importe qui ayant votre clef publique (concept discuté plus tard dans ce document) pourra vérifier l’intégrité du document.

Ce texte est séparé en deux parties. La première partie (ce document) contient la théorie et des anecdotes sur l’encryption symétrique et asymétrique, deux concepts de base de l’encryption. La deuxième partie explique comment utiliser le logiciel GnuPG et comment intégrer l’utilisation de l’encryption dans un logiciel de courier électronique.

Les notions théoriques peuvent être ignorées si vous voulez simplement savoir comment encrypter des e-mails, mais si vous ne savez pas comment fonctionne le logiciel de cryptage utilisé, vous pourriez perdre toute liberté acquise par l’utilisation de l’encryption.

L’encryption symétrique est un processus qui peut être appliqué pour encrypter et décrypter un message. Un texte clair (plaintext) est encrypté à l’aide d’une clef déterminée à l’avance pour obtenir un texte encrypté (ciphertext), on peut décrypter en appliquant le processus inverse. C’est généralement le mode d’encryption le plus rapide et le plus souvent utilisé. Parmis les algorithmes les plus connus, nous retrouvons 3DES, Rijndael (AES) et Blowfish. De façon générale, nous ne manipulons pas ces algorithmes directement, puisque l’émetteur et le récepteur doivent connaître la clef. C’est à dire que l’émetteur doit trouver un moyen d’envoyer sa clef au récepteur sans que celle-ci soit interceptée. En autres termes, il veut envoyer un message qui sera privé, mais pour faire ça, il doit envoyer un message privé contenant la clef (cercle vicieux). Pire encore, la clef doit être changée entre chaque message, car les messages peuvent souvent contenir des mots clefs ou redondants qui pourraient donner un indice sur le contenu de la clef (au fait, il y a beaucoup d’autres raisons, mais ce serait trop long à décrire).

Les facteurs les plus importants pour obtenir une communication symétrique sécuritaire sont la taille de la clef, un bon système de création nombres aléatoires et la fiabilité de l’algorithme. La taille de la clef indique le nombre de différentes clefs possibles. Les ordinateurs sont de plus en plus rapides et peuvent ainsi vérifier toutes les clefs possibles pour un message quelconque afin d’en extraire la clef (brute force). Les nombres aléatoires génèrent les clefs, si l’on peu statistiquement éliminer des clef, la taille de la clef n’est pas une très bonne sécurité. Par exemple, quelqu’un pourrait se vanter d’utiliser une clef 256 bits (115,792,089,237,316,195,423,570,985, 008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 cles possibles), mais il arrive souvent que, par exemple, des logiciels mal testés génèrent dans 80% des cas les mêmes 30% des clefs possibles. Tant qu’à la fiabilité de l’algorithme, c’est simplement au sens mathématique. L’algorithme comme tel ne doit pas être un secret, un briseur de code ne devrait pas être capable de casser un code même s’il connaît toutes les spécifications de l’algorithme. Tout les algorithmes courramment utilisés (Rijndael, 3DES, Blowfish, etc..) sont publiquement disponibles, d’une part pour avoir plus de commentaires de la communauté scientifique (faiseurs de codes et casseurs de codes), mais aussi pour encourager l’interopérabilité.

Certaines compagnies, pour ne pas nommer Microsoft, ont tendance à utiliser des algorithmes propriétaires et vendent après 1 an de consultations internes des applications utilisant ces algorithmes. Ils ont favorisé un algorithme créé il y a un an à l’interne plustôt que d’utiliser des algorithmes publics qui depuis plus de 10 ou 20 ans sont toujours considérés comme étant fiables. L’outil en question, PPTP, une librarie permettant de faire un réseau virtuel par Internet (virtual private LAN), inclu dans Windows NT4 et 2000, a reçu plus d’une centaine de patch depuis que quelqu’un (qui ne travaille pas pour MS) a trouvé une faille dans l’algorithme (par reverse ingineering).

 Note : PPTP est l’équivalent de IPsec, débuté en 1992, standardisé en 1995, revisé en 1998 et des milliers de personnes continuent à l’étudier aujourd’hui pour y trouver des failles de sécurité.

 Note2 : MS Windows 2000 utilise maintenant IPsec, mais PPTP est encore disponible sous forme d’une composante optionnelle.

Lors de la Deuxième Guerre Mondiale, les Allemands donnaient à leurs officiers qui partaient en mission des livres contenant toutes les clefs pour tout les jours du mois (Au début de la guerre, ils utilisaient la même clef pour toute la journée. Quand ils se sont rendus compte que c’était une faille de sécurité exploitée par les Alliés, ils diffusaient la première clef encryptée par les codes prédéterminés, puis ils changeaient le code par un pattern prédéterminé). Les Alliés volaient ces livres et interceptaient une quantité significative de communications militaires (les messages allemands étaient souvent diffusés par télégraphes sans fil étant donné que les Alliés coupaient tout les fils de télégraphes terrestres des territoires envahis). — L’utilisation de l’encryption pendant la Deuxième Guerre Mondiale est un sujet beaucoup plus complexe. Si le sujet vous intéresse, il y a des références additionnelles à la fin de ce texte.

Les banques ont aussi eu de nombreux problèmes avec l’encryption symétrique. Des transactions étaient faites par lien téléphonique (pas nécessaiment par des lignes sécuritaires) et elles avaient des employés dont leur fonction consistait à voyager à travers le monde avec des malettes menottées contenant des clefs.

Bref, la sécurité de la clef est au coeur de l’encryption symétrique. Par contre, si les gouvernements et les banques avaient des problèmes à s’échanger des clefs d’encryption, comment un simple individu pourrait-il encrypter son courier ? C’est dans des situations comme celles-ci où les briseurs de code avaient un grand avantage sur les faiseurs de codes. Les gens pensaient que le coût du transport des clefs était le prix à payer pour encrypter et qu’il n’y avait pas de moyen de contourner le problème.

Pour un nombre "n" de personnes qui communiquent entre-eux, il faudra n(n-1)/2 clefs symétriques pour chaque paire de gens qui se parlent. Si vous voulez communiquer avec un autre usager par Internet, vous devrez probablement le rencontrer en personne pour échanger une clef symétrique. S’il y a 100 million d’internautes (et j’ai vraiment aucune idée combien il y en réellement), il leur faudra 4,999,999,950,000,000 clefs symétriques. Bref, c’est un système qui ne peu pas évoluer à plus grande échelle.

L’encryption asymétrique consiste à utiliser deux clefs différentes lors de la communication. Si Alice veut communiquer avec Bob, elle utilisera la clef publique de Bob pour encrypter et seul Bob pourra décrypter avec sa clef privée. Bob devra lui aussi aller chercher la clef publique d’Alice s’il veut lui envoyer un message.

En 1976, l’algorithme "Diffie-Hellman" (DH) est le premier algorithme d’encryption asymétrique à être publié et l’ancêtre des algorithmes qui ont été publié par après. Au fait, DH est un protocole où les deux partis négocient une clef commune par des moyens asymétriques (clef publique et clef privée), pour créer une lien symétrique. DH est toujours courant aujourd’hui, par exemple, c’est une des bases d’IPsec, qui est à la base des virtual private networks (VPN). Les détails du protocole sont intéressants, mais dépassent largement la portée de ce texte. Vous trouverez quelques ressources suggérées sur DH à la fin de cet article.

Note : Six ans plus tôt, des mathématiciens à Bletchley Park ont découvert un protocole semblable, mais l’information est restée secrète pendant plus de 20 ans.

L’algorithme RSA est est apparu un peu après DH, en 1977, inventé par Ron Rivest, Adi Shamir et Len Adelman (d’où RSA). C’est un des algorithmes les plus connus aujourd’hui, que ce soit pour des sites de commerce électronique ou des applications comme PGP (discuté plus tard dans l’article). RSA fonctionne aussi avec des clefs publiques et privées, mais la grande différence avec DH, c’est qu’Alice doit encrypter avec la clef publique de Bob, puis Bob décrypte avec sa clef privée. Avec DH, Alice encrypte avec une clef composée de sa clef publique et une partie de la clef publique de Bob, puis Bob décrypte avec une partie de sa clef privée et une partie de la clef publique d’Alice.

Jusqu’au 20 septembre 2000, un brevet forçait les concepteurs de logiciels à acheter une licence, mais l’algo est aujourd’hui disponible dans le domaine public. La majorité des développeurs qui travaillent sur des applications Libres n’avaient pas l’argent pour acheter la licence (qui de toute façon contredit la philosophie des Logiciels Libres), développaient à l’extérieur des États-Unis (au fait, la majorité de ces développeurs continuent encore aujourd’hui à refuser du code contribué par des citoyens des États-Unis parce que leurs lois sur l’exportation de l’encryption sont encore plutôt primitives, répressives et imprévisibles.

Bref, RSA consiste à multiplier deux gros nombres premiers (clef privée) pour obtenir un nombre quelconque qui formera la clef publique. Pour décrypter, il faut les deux nombres premiers qui sont à l’origine de la clef publique. Pour casser une clef privée, il suffit de factoriser le nombre public pour obtenir les deux nombres premiers qui forment la clef privée. Tout le monde sait comment casser des clefs privées, le problème, c’est qu’il n’y a pas de méthode magique pour factoriser, il faudrait essayer toutes les combinaisons possibles pour tenter de casser un message encrypté. Pour le moment, nous profitons donc du fait que les ordinateurs sont extrêmement lents et RSA reste une des méthodes les plus sécuritaires. Hélas, on ne peut pas arrêter le progrès. Avec un ordinateur quantique, nous pourrions casser des clefs privées en moins de quelques secondes. Sur papier, il existe déjà des méthodes pour cracker des clefs, comme il existe aussi de nouvelles méthodes pour transmettre des messages encryptés — voir les références, c’est un sujet trop compliqué pour ce texte.

Si vous aviez à cacher un secret pendant 5 à 10 ans, que feriez-vous ?

Vous devriez maintenant avoir une idée générale du fonctionnement de l’encryption. La prochaine section traitera d’un cas spécifique, le logiciel GnuPG (qui utilise le standart OpenPGP), logiciel couramment utilisé pour encrypter des couriers électroniques. Vous comprendrez aussi pourquoi j’ai attaché à ce texte une signature électronique et comment la vérifier.

 Rijndael : http://www.esat.kuleuven.ac.be/~rij...
 Diffie-Hellman : http://www.securityportal.com/topne...

 Diffie-Hellman : http://www.google.com/search?q=Diff…
 Bletchley Park : http://www.bletchleypark.org.uk/
 RSA : http://www.google.com/search?q=RSA+RFC -Ordinateur quantique : http://www.google.com/search?q=quan…

 Encryption quantique : http://www.google.com/search?q=quan…

 The Code Book : Simon Sighn (http://www.simonsingh.com/) ISBN:0-385-49532-3 Aussi disponible en français (et je le recommande)
 GNU Pricacy Handbook : http://www.gnupg.org/docs.html (français/anglais)

 Secret and Lies : Bruce Schneier, ISBN:0-471-25311-1
 Applied Cryptography : Bruce Schneier, ISBN:0-471-11709-9

Simon Sighn et Bruce Schneier pour m’avoir intéressé à l’encryption. :-) François (Tlex) : correction (sur RSA) et précision (sur PPTP)

Auteur : Mathieu Lutfy (mathieu à bidon.ca)