Non non non non et non, vous n'avez pas saisi ce dont je parlais concernant la crypto.
Je parlais de SIGNER ses releases pas de les CRYPTER (même si dans l'absolue ça revient au même).
Petit cours d'intro à la crypto, ça détendra l'atmosphère (et peut-être que certains apprendront quelque chose ce soir
):
Notations:
M: message/ données en clair (lisible, pas crypté)
C: message / données cryptées (illisible, incompréhensible)
K1: clé d'encryptage
K2: clé de décryptage
E: algorithme d'encryptage
D: algorithme de décryptage
- une crypto classique de chez classique est à base d'algorithme de cryptage SYMETRIQUE. On a:
D = E^(-1) <--- D est l'algo "inverse" de E.
K = K1 = K2 <---- Même clé K pour crypter et pour décrypter
donc:
Encryptage d'un message M en cryptogramme C: C = E(M, K)
Décryptage d'un cryptogramme C et reconstitution du message M initial: M = D(C, K) = E^(-1) (C, K)
Le problème est qu'il faut garder K (le mot de passe) secret, sinon le message crypté C n'est plus en sureté. Pour transmettre des données à travers un réseau, ça oblige l'émetteur ET le récepteur à connaître le même mot de passe secret. => Problème de transmission du mot de passe + 2 fois plus de chance que le mot de passe soit compromis. Internet étant un réseau considéré très peu sûr, à cela s'ajoutent les risques d'interception de flux de données cryptées et les attaques de cryptanalyse pour "casser" l'algo & la clé utilisés.
Bien.
Passons aux choses intéressantes à présent:
Sans entrer dans des détails (passionnants pourtant) mathématiques, parlons de cryptage à clé publique.
Dans ce paradigme, D n'est pas la fonction réciproque de E, et K1 != K2. On a:
Encryptage d'un message M en cryptogramme C: C = E(M, K2)
Décryptage d'un cryptogramme C et reconstitution du message M initial: M = D(C, K1)
(K1, K2) est un couple de clés qui sont liées logiquement l'une à l'autre (ce ne sont pas 2 pauvres mots de passes choisis au pif selon l'humeur de l'utilisateur).
- L'une des deux clés (K1 par exemple) est dite
privée, c'est à dire secrète, seul l'utilisateur propriétaire (appelons le Bob) du couple de clé (celui qui a généré cette paire (K1, K2)) la connait.
- L'autre (K2 en l'occurence) est dite
publique, elle n'est pas secrète du tout, elle peut être librement partagée, donnée à tout le monde, et même disposée sur un serveur certifié de stockage de clefs publiques.
> Cela a pour conséquences que:
- Un personne lambda (appelons là Alice) pouvant librement connaitre K2, elle peut librement encrypter un message M, pour le transmettre à Bob.
- Bob, seul à connaitre K1, est LE SEUL au monde à pouvoir décrypter ce que Alice vient de lui envoyer sous forme cryptée.
> Par conséquent:
Si Bob et Alice veulent réciproquement communiquer ensemble de façon sécurisée, Bob doit avoir une paire de clés (K1, K2) en sa possession, Alice doit elle aussi avoir une paire de clés (K1', K2') en sa possession. Bob doit en outre connaitre K2'; Alice doit elle connaitre K2, ce qui n'est pas un problème.
Alors maintenant, passons à la signature:
Signer un message M sert à assurer son authenticité (comme un vraie signature quoi (même si une vraie signature est à mon goût la chose la plus insécurisée qui éxiste encore, bref)). Cela n'a pas pour but de rendre le message M illisible.
Reprenons le cas de Bob, qui possède sa paire de clé (K1, K2) (K1 secète, K2 connue du monde entier).
Si Bob encrypte M en cryptogramme C à l'aide de K1 (la clé normalement utilisée pour le décryptage, cf. explication précedente), alors n'importe qui peut décrypter C à l'aide de K2 (connue de tous).
Par contre, chose intéressante, Bob est LE SEUL à pouvoir encrypter M en C, i.e. il est le seul à pouvoir apposer sa signature sur M, à pouvoir AUTHENTIFIER M.
Voilà dans les grandes lignes comment ça fonctionne.
Pour ce qui est de la libre mise à disposition de la clé publique, effectivement, ça peut poser problème si un site qui l'affiche se fait hacké et si le pirate remplace la clé vraie clé publique K2 de Bob par la clé K2'' d'une paire (K1'', K2'') connue du pirate. Si le pirate en question y parvient, il peut par la suite signer des données truquées avec K1'' et Alice n'y verra que du feu.
Une solution toute simple pour éviter ce genre de désarrois:
il éxiste sur le net nombre de sites certifiés (Verisign,Veridis, etc...) permettant de déposer une clé publique associée à un nom/adresse mail dans une base de donnée sécurisée librement consultable (un annuaire en quelque sorte).
Il aurait donc suffit à D_A de se générer une paire de clés, de balancer sa clé publique sur un serveur de clés associer à Dark_Alex, et de signer ses releases pour éviter le gros bordel actuel.
J'espère que tout ceci vous aura été utile