Suite au récent changement général de clés opéré au sein de Debian, j’en avais profité pour également changer ma clé et m’intéresser d’un peu plus près à Gnupg.
C’est en fouillant un peu que j’étais tombé sur le menu suivant :
Command> showpref
[ultimate] (1). Carl Chenet <chaica@ohmytux.com>
Cipher: AES256, AES192, AES, CAST5, 3DES
Digest: SHA1, SHA256, RIPEMD160
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modify
Hmm, AES, mais c’est un algorithme de chiffrement symétrique ça.
En fait après lecture de la documentation de Gnupg, il s’avère que pour chaque chiffrement, Gnupg chiffre les données avec un algorithme de chiffrement symétrique, ici l’AES256, à l’aide d’une clé partagée entre l’émetteur et le receveur. Cette clé ne sera utilisée que pour cet échange (on l’appelle aussi clé de session). Et c’est cette clé de session qui sera chiffrée avec un algorithme de chiffrement asymétrique avant d’être communiquée au receveur, ledit chiffrement asymétrique réalisé à l’aide de la clé publique du receveur. Le mode de chiffrement adopté par Gnupg est donc hybride, mélange chiffrement symétrique et asymétrique.
Ce qui nous est assuré ainsi, c’est qu’au pire l’algorithme de chiffrement asymétrique (le plus faible des deux selon la documentation Gnupg) compromis, seul le message actuel serait compromis, l’attaquant étant obligé de redéchiffrer une nouvelle clé de session pour accéder à un nouveau message. On est bien sûr déjà dans un cas extrême.
Note au passage que c’est en général partout comme ça : SSL par exemple est hybride aussi. La principale raison est que l’algorithme de chiffrement symétrique est beaucoup plus rapide (donc essentiel pour SSL et intéressant pour le chiffrement de gros fichier, dans le cas de GnuPG).
Comme le dit Yoho, il s’agit surtout d’accroître la vitesse que la sécurité. On peut aussi le présenter ainsi : la crypto symétrique est bien meilleure en termes de performances, mais c’est un cauchemar en termes de gestion de clés à grande échelle. La crypto asymétrique, c’est exactement l’inverse. En mélangeant ainsi les deux, on profite du meilleur des deux mondes.
Par ailleurs, il est faux de penser que les chiffrements symétriques sont plus faibles que les chiffrements asymétriques en général : tout dépend de la longueur de la clé. Dans le Schneier “Aplied Cryptography” on trouve un tableau de correspondance approximative entre chiffres symétriques et asymétrique, dont il ressort par exemple qu’un chiffrement symétrique avec une clé de 128 bits résiste à peu près aussi bien à une attaque par force brute qu’un chiffrement par un algo asymétrique avec une clé de 2304 bits. (Édition 1996, donc peut-être pas à prendre à la lettre, mais l’esprit reste juste.)
Par ailleurs, un avantage potentiellement utile en pratique de la clé de session, c’est que si dans la cadre d’une enquête judiciaire on doit dévoiler le contenu d’une correspondance, on peut en effet ne donner à la police que les clés de sessions adéquates, sans dévoiler sa clé privée, comme mentionné dans la page de man à l’endroit de –show-session-key et –override-session-key.
Note qu’il vaut mieux ne pas utiliser SHA1 pour le hashage (c’est le premier par ordre de préférence dans ta ligne « digest ».
Plus d’infos par là (et dans les liens du billet de Christian) : http://www.perrier.eu.org/weblog/2009/08/05#gpg-disaster
Yannick : exact, merci de l’avoir remarqué je n’ai pas fait attention.