a16z : Trois solutions privilégiées pour résoudre le problème central de la cryptographie à clé publique
TechFlow SélectionTechFlow Sélection
a16z : Trois solutions privilégiées pour résoudre le problème central de la cryptographie à clé publique
Il existe actuellement trois solutions : le répertoire de clés publiques, le chiffrement basé sur l'identité (IBE) et le chiffrement basé sur l'enregistrement (RBE).
Dédié à des analyses Web3 approfondiesRédaction : Noemi Glaeser, a16z crypto
Rédaction : Chris, Techub News
Dans la cryptographie à clé publique, un problème persistant consiste à associer correctement une clé cryptographique (par exemple une clé publique) à une identité spécifique concrète, comme une personne ou une organisation. Le cœur du défi réside dans l’existence d’un moyen public et cohérent de montrer la relation entre une identité et sa clé publique, afin que tous puissent utiliser ces clés publiques en toute confiance pour chiffrer des messages.
En l’absence d’une telle association explicite, il peut être impossible de déterminer à qui appartient une clé publique donnée, ce qui pourrait conduire à envoyer par erreur des messages chiffrés à la mauvaise personne, entraînant des fuites d'informations ou d'autres conséquences graves. Ce problème existe toujours dans l’écosystème Web3.
Pour résoudre ce problème, trois approches principales existent actuellement : le Répertoire de Clés Publiques (Public Key Directory), le chiffrement basé sur l’identité (IBE) et le chiffrement basé sur l’enregistrement (RBE). Ces trois méthodes présentent chacune des avantages distincts en matière d’anonymat, d’interactivité et d’efficacité. Par exemple, IBE repose sur une hypothèse de confiance forte, mais offre de meilleures performances en termes d’anonymat et d’efficacité dans certains cas. Cet article explore les applications de ces trois méthodes sur la blockchain et compare leurs forces et faiblesses respectives.
Les trois méthodes
La méthode classique pour associer une clé cryptographique à une identité est l'utilisation de l'infrastructure à clé publique (PKI), dont le composant central est un répertoire de clés publiques. Dans cette approche, l'expéditeur doit interagir avec une tierce partie de confiance — généralement une autorité de certification qui gère ce répertoire — afin d'envoyer un message chiffré.
Cependant, dans l'environnement Web2, la maintenance d'un tel répertoire implique des coûts élevés et des opérations complexes. En outre, les utilisateurs encourent le risque que l'autorité de certification abuse de son pouvoir.
Des cryptographes ont proposé des alternatives pour remédier aux limites de la PKI. En 1984, Adi Shamir a introduit le chiffrement basé sur l’identité (IBE), où l’identifiant d’une partie (comme un numéro de téléphone, une adresse e-mail ou un nom de domaine ENS) sert directement de clé publique. Cette méthode élimine le besoin d’un répertoire de clés publiques, mais crée un nouveau problème : elle nécessite une tierce partie de confiance (le générateur de clés) pour produire les clés privées.
En 2001, Dan Boneh et Matthew Franklin ont conçu la première construction pratique d’IBE. Toutefois, cette technologie n’a pas été largement adoptée, se limitant principalement à des écosystèmes fermés, tels que des déploiements d’entreprises ou de gouvernements. L’un des motifs de cet échec d’adoption pourrait être l’hypothèse de confiance forte requise — à savoir, faire confiance à une tierce partie pour la génération des clés privées.
Cependant, comme nous le verrons plus loin, ce problème de confiance peut être atténué en s’appuyant sur une tierce partie distribuée (un groupe de participants formant une majorité qualifiée), une structure qu’une blockchain peut facilement réaliser.
Avantages et inconvénients
Lorsqu’on compare ces différentes solutions cryptographiques, plusieurs facteurs doivent être pris en compte. Je formule ici deux hypothèses simplificatrices :
Les utilisateurs ne mettent pas à jour ni ne révoquent leurs clés : cela signifie que chaque clé utilisateur est supposée fixe tout au long de la discussion.
Les contrats intelligents n’utilisent aucun service externe de disponibilité des données (DAS) ou données « blob » hors chaîne : autrement dit, on suppose que les contrats intelligents dépendent entièrement des données présentes sur la chaîne, sans recourir à des services ou stockages hors chaîne.
Répertoire de Clés Publiques (Public Key Directory)
Toute personne peut appeler un contrat intelligent pour ajouter sur la chaîne un couple (id, pk) correspondant à un identifiant libre.
La PKI décentralisée utilise un contrat intelligent pour maintenir un répertoire associant chaque identité (ID) à sa clé publique. Ce répertoire est public et ne dépend pas d'une tierce partie centralisée. Par exemple, ENS (Ethereum Name Service) gère un mappage entre un nom de domaine (l’identité) et des métadonnées associées, notamment l’adresse cible (à partir de laquelle on peut déduire la clé publique via les transactions). ENS est un système plus complexe, car il stocke non seulement des clés publiques mais aussi d'autres métadonnées. La PKI décentralisée est fonctionnellement plus simple : le contrat intelligent maintient uniquement une liste liant chaque identité à sa clé publique.
Lorsqu’un utilisateur souhaite s’enregistrer, il génère d’abord une paire de clés (publique/privée), ou utilise une paire existante, puis envoie son identifiant (ID) et sa clé publique au contrat intelligent (éventuellement accompagné d’un paiement). Le contrat vérifie si cet ID est déjà pris. S’il est disponible, le contrat ajoute le couple (ID, clé publique) au répertoire. Une fois enregistré, n’importe qui peut interroger le contrat pour obtenir la clé publique associée à un ID donné, puis chiffrer un message destiné à cet utilisateur. Si l’expéditeur a déjà envoyé un message chiffré à cet utilisateur et possède déjà sa clé publique, il n’a pas besoin de consulter à nouveau le contrat. Après avoir obtenu la clé publique, l’expéditeur peut chiffrer normalement le message et l’envoyer au destinataire, qui utilisera sa clé privée pour le déchiffrer et récupérer le texte clair.
Examinons maintenant les avantages et inconvénients de cette méthode :
Chiffrement basé sur l’identité (IBE)
L’identité d’un utilisateur est représentée par sa clé publique : autrement dit, la clé publique sert non seulement au chiffrement, mais aussi d’identifiant unique. Toutefois, cette méthode dépend d’un ou plusieurs tiers de confiance chargés de générer et distribuer les clés. De plus, ces tiers doivent conserver durant toute la durée du système une clé maîtresse, pouvant être utilisée dans certaines situations pour déchiffrer ou effectuer d’autres opérations critiques.
Dans un système IBE, contrairement aux systèmes cryptographiques traditionnels, l'utilisateur ne génère pas lui-même sa paire de clés. Il doit s'inscrire auprès d'un générateur de clés de confiance. Ce générateur détient une paire de clés maîtresses (clé privée maîtresse msk et clé publique maîtresse mpk). Lorsqu’un utilisateur fournit son identifiant (ID), le générateur utilise la clé privée maîtresse (msk) et l’ID pour calculer une clé privée unique pour cet utilisateur. Cette clé privée doit ensuite être transmise à l’utilisateur via un canal sécurisé, généralement établi par un protocole d’échange de clés.
Pour l’expéditeur, le processus de chiffrement est simplifié : il suffit de télécharger une seule fois la clé publique maîtresse (mpk) du générateur, après quoi il peut chiffrer un message en utilisant uniquement l’ID du destinataire. Pour le destinataire, le déchiffrement est également simple : l’utilisateur inscrit peut utiliser la clé privée fournie par le générateur pour déchiffrer le message reçu.
La clé privée maîtresse (msk) doit être conservée indéfiniment, car elle est nécessaire en continu pour générer de nouvelles clés privées utilisateur. Contrairement aux systèmes SNARK, où la clé maîtresse est générée lors d’une configuration initiale de confiance puis peut être détruite, dans un système IBE, la clé msk ne peut pas être supprimée après l’initialisation.
Même si la clé privée maîtresse (msk) est bien protégée, chaque utilisateur inscrit doit néanmoins faire confiance au générateur de clés pour ne pas lire ses messages. En effet, le générateur peut à tout moment conserver une copie de la clé privée d’un utilisateur ou la recalculer à partir de la clé msk.
Le générateur pourrait aussi fournir à un utilisateur une clé privée défectueuse ou restreinte, capable de déchiffrer la plupart des messages mais incapable de déchiffrer certains messages spécifiquement filtrés par le générateur. Cela signifie que le générateur peut contrôler ou limiter la capacité de déchiffrement de l’utilisateur, exerçant ainsi un certain contrôle sur ses communications.
Chiffrement basé sur l’enregistrement (RBE)
Comme dans IBE, l’identité d’un utilisateur (par exemple une adresse e-mail ou un numéro de téléphone) sert directement de clé publique. Mais contrairement à IBE, ce système ne repose plus sur une tierce partie de confiance unique ou un groupe de validation (quorum). À la place, cette fonction est assurée par un « key curator ».
Nous allons étudier ici une construction RBE efficace, qui présente selon moi un avantage marquant par rapport aux autres constructions RBE pratiques : elle peut être déployée sur blockchain car elle repose sur des couplages (pairings), et non sur des réseaux euclidiens (lattice-based).
Dans un système RBE, chaque utilisateur génère lui-même sa paire de clés (publique et privée). Il doit également calculer, à partir de sa clé privée et d’une chaîne de référence commune (CRS), certaines valeurs de mise à jour (notées « a » sur le schéma). Ces valeurs servent aux opérations ultérieures du système. L’existence de la CRS signifie que le paramétrage du système n’est pas totalement sans confiance. Toutefois, la CRS peut être générée sur la chaîne par une procédure collaborative impliquant plusieurs participants, fondée sur une construction dite « powers of tau ». Tant qu’au moins un participant est honnête, la sécurité de la CRS est garantie.
Un contrat intelligent est configuré pour un nombre prédéfini d'utilisateurs N, regroupés en différents compartiments (buckets). Lorsqu’un utilisateur s’inscrit, il envoie au contrat son identifiant (ID), sa clé publique et les valeurs de mise à jour. Le contrat maintient un ensemble de paramètres publics (pp), distincts de la CRS. On peut voir pp comme un résumé compact de toutes les clés publiques des utilisateurs inscrits. Après réception de la demande d’inscription, le contrat vérifie la validité des valeurs de mise à jour. Une fois validées, il intègre la clé publique de l’utilisateur dans les compartiments appropriés de pp. Cette étape incorpore effectivement la clé publique du nouvel utilisateur aux paramètres publics du système.
Dans un système RBE, les utilisateurs doivent conserver localement certaines informations auxiliaires nécessaires au déchiffrement. Lorsqu’un nouvel utilisateur s’inscrit dans leur même compartiment, ces informations doivent être mises à jour. L’utilisateur peut surveiller la blockchain lui-même pour effectuer manuellement la mise à jour, ou bien le contrat peut fournir les dernières informations d’inscription, que l’utilisateur récupère périodiquement pour garder ses données de déchiffrement à jour.
Pour l’expéditeur, deux actions sont nécessaires :
Télécharger la chaîne de référence commune (CRS) : cela ne doit être fait qu’une seule fois, sans besoin de mise à jour ultérieure.
Télécharger les paramètres publics : l’expéditeur doit occasionnellement télécharger la version la plus récente des paramètres publics. Il est important que ces paramètres contiennent la clé publique du destinataire, mais il n’est pas nécessaire d’avoir la toute dernière version tant que la clé du destinataire y figure.
Ensuite, l’expéditeur utilise la CRS téléchargée, les paramètres publics et l’identifiant du destinataire pour chiffrer le message et l’envoyer. Ainsi, l’expéditeur n’a pas besoin de mettre à jour fréquemment ses données, tant que les paramètres incluent la clé du destinataire.
Lorsqu’un utilisateur reçoit un message chiffré, il commence par vérifier dans ses informations auxiliaires locales s’il existe une valeur satisfaisant une condition donnée (par exemple, passant un test de vérification). S’il ne trouve pas une telle valeur, cela signifie qu’il doit récupérer depuis le contrat les dernières mises à jour. Dès qu’il dispose de la bonne information auxiliaire, il peut l’utiliser conjointement avec sa clé privée pour déchiffrer le message et retrouver le texte original.
Cette solution est clairement plus complexe que les deux autres. Toutefois, elle nécessite moins de stockage sur la chaîne que le répertoire de clés publiques, et évite l’hypothèse de confiance forte d’IBE.
Paramètres concis :
La taille des paramètres stockés sur la chaîne croît de manière sous-linéaire avec le nombre d'utilisateurs, ce qui représente un gain significatif par rapport au répertoire de clés publiques (croissance linéaire). Cependant, ce n’est pas une taille constante, donc cet aspect reste inférieur à celui des systèmes IBE.
Chiffrement partiellement interactif :
L’expéditeur a besoin d’une copie des paramètres publics contenant la clé du destinataire. Cela implique une mise à jour des paramètres après l’inscription du destinataire, mais pas nécessairement pour chaque destinataire individuel, car une même mise à jour peut inclure plusieurs clés. Globalement, l’interactivité requise pour l’envoi de messages est supérieure à celle d’IBE, mais inférieure à celle du répertoire de clés publiques.
Déchiffrement partiellement interactif :
De façon similaire au chiffrement, le destinataire a besoin d’informations auxiliaires compatibles avec la version des paramètres publics utilisée lors du chiffrement. Lorsqu’un nouvel utilisateur s’inscrit dans un compartiment, les paramètres publics et les informations auxiliaires sont mis à jour. La valeur permettant le déchiffrement correspond à la version des paramètres en vigueur au moment du chiffrement. L’utilisateur peut choisir de récupérer périodiquement les mises à jour plutôt que de le faire immédiatement, sauf en cas d’échec de déchiffrement. Contrairement aux mises à jour des paramètres, demander fréquemment les mises à jour auxiliaires ne compromet pas la confidentialité.
Anonymat de l’expéditeur :
Comme dans le cas du répertoire de clés publiques, l’expéditeur peut chiffrer indépendamment un message (à condition d’avoir les derniers paramètres), sans avoir à interroger d’information spécifique au destinataire. Lorsque l’expéditeur lit des données sur la chaîne, celles-ci ne sont pas liées au destinataire (sauf s’il ne demande qu’un fragment spécifique des paramètres, ce qui pourrait divulguer une information partielle).
Transparence :
Bien que le système nécessite une configuration initiale de confiance (pouvant être distribuée ou gérée externement) pour produire une CRS corrigée, une fois cette phase terminée, il ne dépend plus d’aucune tierce partie ou groupe d’arbitrage. Bien qu’il repose sur un tiers coordonnateur (le contrat intelligent), le système est entièrement transparent : n’importe qui peut assumer le rôle de coordinateur ou vérifier l’honnêteté du fonctionnement en validant les transitions d’état (ce qui explique pourquoi il peut être implémenté comme contrat intelligent). En outre, les utilisateurs peuvent demander une preuve concise d’appartenance (ou de non-appartenance) pour vérifier s’ils ou d’autres sont inscrits dans le système. Ceci contraste avec IBE, où il est difficile pour la tierce partie de prouver qu’elle n’a pas secrètement divulgué les clés de déchiffrement (par exemple en conservant une copie ou en les transmettant à d’autres). En comparaison, le répertoire de clés publiques est pleinement transparent.
Ensemble d’identifiants restreint :
La version décrite ici est la forme de base de la construction RBE. Pour déterminer de manière transparente le compartiment d’un ID, les identifiants doivent suivre un ordre public et déterministe. Les numéros de téléphone peuvent être triés simplement, mais trier des chaînes arbitraires peut s’avérer très complexe, voire impossible, surtout si le nombre de compartiments est très grand ou infini. Ce problème peut être atténué en proposant un contrat séparé pour calculer ce mappage, ou en utilisant des méthodes comme le hachage cuckoo, proposées dans des travaux ultérieurs.
Anonymat du destinataire :
Cette méthode permet de chiffrer un message sans que le chiffré ne révèle l’identité du destinataire.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
a16z
