Source: Noemi Glaeser, a16z crypto
Dans la Cryptographie, il y a toujours eu un problème, qui est de savoir comment associer correctement la clés chiffrées (comme la Clé publique) avec une identité spécifique (comme une personne ou une organisation). La clé est d’avoir un moyen public et cohérent d’afficher la relation entre l’identité et la Clé publique, afin que tout le monde puisse utiliser en toute confiance ces Clé publique pour chiffrer les informations.
Si la relation n’est pas clairement établie, il est possible que les autres ne puissent pas déterminer à qui appartient une Clé publique, ce qui pourrait conduire à l’envoi d’informations de chiffrement à la mauvaise personne, entraînant une fuite d’informations ou d’autres conséquences graves. Dans Web3, ce problème persiste.
Pour les problèmes susmentionnés, il existe actuellement trois solutions : l’annuaire de clés publiques, le chiffrement basé sur l’identité (IBE) et le chiffrement basé sur l’enregistrement (RBE). Ces trois méthodes ont chacune leurs avantages en termes d’anonymat, d’interactivité et d’efficacité. Par exemple, l’IBE nécessite une base de confiance solide, mais dans certaines situations, l’IBE se comporte mieux en termes d’anonymat et d’efficacité. Cet article vise à explorer l’application de ces trois méthodes dans l’utilisation hors chaîne de blocs et à comparer leurs avantages et inconvénients.
Trois méthodes
En général, une méthode courante pour associer le chiffrement des Clés secrètes avec des informations d’identité consiste à utiliser l’infrastructure à clé publique (PKI), dont le cœur est un répertoire de clés publiques. Dans cette méthode, la personne envoyant des informations doit interagir avec une tierce partie de confiance (c’est-à-dire l’entité maintenant ce répertoire, généralement une autorité de certification) pour envoyer des informations chiffrées.
Cependant, dans l’environnement Web2, la maintenance de ce répertoire de Clé publique nécessite des coûts élevés et des opérations fastidieuses. De plus, les utilisateurs sont confrontés au risque d’abus de pouvoir des autorités de certification.
Des alternatives proposées par les cryptographes pour résoudre les problèmes de l’infrastructure de clé publique (PKI). En 1984, Adi Shamir a proposé le chiffrement basé sur l’identité (IBE), où l’identité d’une partie (comme un numéro de téléphone, une adresse e-mail ou un nom de domaine ENS) peut être utilisée directement comme clé publique. Cette approche élimine la nécessité de maintenir un répertoire de clés publiques, mais introduit un nouveau problème: il faut compter sur un générateur de clés secrètes de confiance pour générer la clé privée.
En 2001, Dan Boneh et Matthew Franklin ont proposé la première construction IBE pratique, mais cette technologie n’a pas été largement adoptée, principalement utilisée dans des environnements fermés tels que les déploiements d’entreprises ou gouvernementaux. L’une des raisons pour lesquelles l’IBE n’est pas largement utilisée est qu’elle dépend d’une hypothèse de confiance forte, à savoir la confiance dans la génération de clés secrètes par un tiers.
Cependant, comme discuté dans la suite de cet article, ce problème de confiance peut être résolu en s’appuyant sur un plus long de confiance (c’est-à-dire un nombre légal de participants) et la technologie de la blockchain peut facilement y parvenir.
Avantages et inconvénients
Lors de la comparaison de ces différentes méthodes de chiffrement, de nombreux facteurs différents doivent être pris en compte. Je fais deux hypothèses ƒ8374656574839201 :
Les utilisateurs ne mettent pas à jour ou ne révoquent pas leur Clé secrète: cela signifie que dans la discussion, il est supposé que la Clé secrète de chaque utilisateur est fixe et ne change pas.
Les smart contracts n’utilisent aucun service de disponibilité des données hors chaîne (DAS) ou des données blob : en d’autres termes, cela signifie que les smart contracts dépendent entièrement des données hors chaîne, sans impliquer de services de données externes ou de stockage de données supplémentaires.
![]()
Répertoire des clés publiques
N’importe qui peut ajouter une entrée (id, pk) non utilisée au répertoire off-chain en appelant le smart contract.
![]()
La PKI de la décentralisation fait référence à un répertoire d’identités (ID) et de leurs Clés publiques maintenu via des smart contracts. Ce répertoire est public et ne dépend pas d’un tiers centralisé. Par exemple, prenons l’exemple de l’ENS, qui maintient une correspondance entre un nom de domaine (c’est-à-dire une identité) et les métadonnées associées, y compris l’Adresse résolue pour ce nom de domaine (à partir de ces transactions d’Adresse, on peut déduire la Clé publique). L’ENS est un système plus complexe, enregistrant non seulement la Clé publique, mais aussi d’autres métadonnées. La fonction de la PKI de la décentralisation est relativement simple : le smart contract n’a besoin que de maintenir une liste enregistrant la Clé publique correspondante à chaque identité.
Lorsqu’un utilisateur souhaite s’inscrire, il doit d’abord générer une paire de clés secrètes (clé publique et clé privée), ou utiliser une clé secrète existante, pour envoyer son ID d’identité et sa clé publique au smart contract (éventuellement moyennant des frais). Le smart contract vérifiera si cet ID est déjà enregistré par quelqu’un d’autre. S’il n’est pas utilisé, le smart contract ajoutera cet ID et sa clé publique au répertoire. Une fois l’inscription terminée, toute personne peut interroger le smart contract pour obtenir la clé publique correspondant à un ID donné, afin de chiffrer et d’envoyer un message à cet utilisateur. Si l’expéditeur a déjà chiffré un message à cet utilisateur auparavant et possède déjà sa clé publique, il n’a pas besoin de demander à nouveau la clé publique au smart contract. Une fois la clé publique obtenue, l’expéditeur peut l’utiliser comme d’habitude pour chiffrer le message, puis envoyer le message chiffré au destinataire. Ce dernier utilisera sa clé privée correspondante pour déchiffrer le message et le récupérer en clair.
Jetons un coup d’œil aux avantages et aux inconvénients de cette méthode :
Avantages et inconvénients du déchiffrement non interactif: le processus de déchiffrement ne nécessite pas d’interaction avec d’autres parties, le déchiffreur peut le faire indépendamment. Non succinct: le système peut être complexe, volumineux en termes de données ou nécessiter plus de ressources. Transparence: le système peut être transparent dans certains aspects, ce qui signifie que les opérations sont publiques et peuvent être vérifiées. Chiffrement interactif: le processus de chiffrement peut nécessiter une certaine interaction avec d’autres parties, ce qui augmente la complexité. ID arbitraire: les utilisateurs peuvent choisir librement ou utiliser n’importe quelle identité ID, sans être limités par un format ou des règles spécifiques. L’expéditeur n’est pas anonyme: l’identité de l’expéditeur peut ne pas être complètement anonyme dans le système.
Chiffrement basé sur l’identité (IBE)
L’identité de l’utilisateur est représentée par leur Clé publique, ce qui signifie que la Clé publique est utilisée non seulement pour le chiffrement, mais aussi comme identifiant unique de l’utilisateur. Cependant, cette méthode nécessite la dépendance à un ou plusieurs tiers de confiance, chargés de générer et de distribuer la Clé secrète. De plus, ces tiers de confiance doivent également conserver une Clé secrète principale tout au long du cycle de vie du système, cette Clé secrète principale pouvant être utilisée dans certains cas pour le déchiffrement ou d’autres opérations importantes.
![]()
Dans le système IBE, l’utilisateur ne génère pas sa propre paire de Clé publique et de Clé privée comme dans les systèmes de chiffrement traditionnels. Au lieu de cela, l’utilisateur doit s’inscrire avec un générateur de Clé secrète de confiance. Le générateur de Clé secrète possède une paire de Clé secrète principale (comprenant la Clé privée principale msk et la Clé publique principale mpk). Lorsque l’utilisateur fournit son identifiant, le générateur de Clé secrète utilise la Clé privée principale msk et l’identifiant de l’utilisateur pour calculer une Clé privée exclusive à cet utilisateur. La Clé privée générée doit être transmise à l’utilisateur par un canal sécurisé, généralement établi à l’aide d’un protocole d’échange de Clé secrète.
Pour l’expéditeur, le système IBE simplifie le processus de chiffrement. L’expéditeur n’a besoin de télécharger la clé publique principale (MPK) du générateur de clés secrètes qu’une seule fois, puis peut utiliser l’ID pour chiffrer le message. Pour le destinataire, le déchiffrement est également simple. Les utilisateurs enregistrés peuvent utiliser la clé privée que le générateur de clés secrètes leur a envoyée pour déchiffrer le texte chiffré reçu.
La Clé privée principale du générateur de clés (msk) doit être conservée à long terme car elle doit générer en continu de nouvelles Clés privées utilisateur pendant le fonctionnement du système. Cela diffère des systèmes SNARK où elles sont générées lors du processus de configuration de confiance mais peuvent être détruites une fois la configuration terminée. Dans le cas des systèmes IBE, la Clé privée principale ne peut pas être supprimée après l’initialisation comme dans SNARK.
Même si le maître Clé privée（msk）est bien conservé, chaque utilisateur enregistré doit quand même faire confiance au générateur de clés pour ne pas lire leurs messages. Cela est dû au fait que le générateur de clés peut sauvegarder une copie de la clé privée de l’utilisateur à tout moment, ou utiliser le maître Clé privée pour recalculer la clé privée de l’utilisateur.
Le générateur de clé secrète peut également fournir à l’utilisateur une Clé privée défectueuse ou restreinte, qui peut décrypter la plupart des messages, mais pas certains messages spécifiques définis par le générateur de Clé secrète. Cela signifie que le générateur de Clé secrète a la capacité de manipuler la capacité de décryptage de l’utilisateur, ce qui peut entraîner un certain degré de contrôle ou de restriction de la communication de l’utilisateur.
Avantages et inconvénients du stockage off-chain: Le stockage nécessaire sur le Bloc off-chain est faible ou constant, ce qui ne va pas augmenter avec le temps. Hypothèse de forte confiance: le système dépend d’un ou plusieurs tiers de confiance, ce qui signifie qu’il est nécessaire de faire confiance à ces tiers. Si ces tiers sont compromis ou peu fiables, la sécurité du système est menacée. Chiffrement non interactif: le chiffrement n’a pas besoin d’interagir avec d’autres parties, l’expéditeur peut le faire indépendamment. Anonymat de l’expéditeur: le système peut maintenir l’anonymat de l’expéditeur pour protéger la vie privée. Identifiant arbitraire: les utilisateurs peuvent librement choisir ou utiliser n’importe quel identifiant d’identité, sans être limités par un format ou des règles spécifiques.
Basé sur le chiffrement enregistré (RBE)
Comme IBE, dans ce système, l’identité de l’utilisateur (par exemple, l’adresse électronique ou le numéro de téléphone) sert directement de Clé publique. Mais contrairement à IBE, ce système ne dépend plus d’un tiers de confiance ou d’un groupe de quorum pour gérer la Clé secrète. Au lieu de cela, ce tiers de confiance est remplacé par un key curator.
Je vais discuter dans cette section d’une méthode efficace de construction de RBE, car je sais que cela présente un avantage significatif par rapport à d’autres constructions pratiques de RBE, car elle peut être déployée hors de la chaîne de blocs, car elle est basée sur des pairings plutôt que sur des lattices.
![]()
Dans le système RBE, chaque utilisateur génère sa propre paire de clés (composée d’une clé publique et d’une clé privée). Les utilisateurs doivent également calculer certaines valeurs mises à jour (marquées comme a dans le diagramme) en fonction de leur clé privée et d’une chaîne de référence publique (CRS). Ces valeurs mises à jour sont utilisées pour des opérations ultérieures dans le système. La présence de la chaîne de référence publique (CRS) signifie que la configuration du système ne peut être entièrement dénuée de confiance. Cependant, le processus de génération du CRS utilise une méthode de construction appelée tau puissance, qui peut être réalisée off-chain grâce à la collaboration de plusieurs participants. Tant qu’au moins un participant est honnête, ce CRS est sécurisé.
Le contrat intelligent a été configuré pour un nombre attendu d’utilisateurs N, qui sont regroupés dans différents compartiments. Lorsqu’un utilisateur s’inscrit dans le système, il doit envoyer son ID d’identité, sa clé publique et la valeur de mise à jour au contrat intelligent. Le contrat intelligent maintient un ensemble de paramètres publics pp, qui sont différents de la chaîne de référence publique (CRS) mentionnée précédemment. On peut considérer pp comme un résumé concis de la clé publique de tous les utilisateurs enregistrés dans le système. Après avoir reçu la demande d’inscription de l’utilisateur, le contrat intelligent vérifie la valeur de mise à jour pour en valider la précision. Une fois la validation effectuée, le contrat intelligent multiplie la clé publique de l’utilisateur dans les compartiments correspondants de pp. Cette étape équivaut à l’inclusion de la clé publique du nouvel utilisateur dans l’ensemble des paramètres publics du système, afin d’être utilisée ultérieurement.
Dans le système de chiffrement basé sur l’enregistrement (RBE), les utilisateurs doivent stocker localement certaines informations pour les aider à décrypter les messages. Lorsqu’un nouvel utilisateur s’inscrit dans le même groupe qu’eux, ces informations doivent être mises à jour. Les utilisateurs peuvent surveiller manuellement la chaîne de blocs pour mettre à jour ces informations ou les contrats intelligents peuvent fournir des informations sur les utilisateurs récemment inscrits, que les utilisateurs peuvent récupérer périodiquement pour maintenir leurs informations de décryptage à jour.
Dans ce système, l’expéditeur n’a qu’à faire deux choses :
Télécharger la chaîne de référence publique (CRS) : cela ne nécessite qu’un seul téléchargement et n’a pas besoin d’être mis à jour par la suite.
Télécharger les paramètres publics: L’expéditeur doit parfois télécharger les derniers paramètres publics. Pour l’expéditeur, il est important que ces paramètres publics contiennent la clé publique du destinataire, afin de ne pas avoir à télécharger la dernière version à chaque fois, tant que la clé publique du destinataire peut être trouvée.
Ensuite, l’expéditeur utilise le CRS téléchargé, les paramètres publics et l’identifiant de l’entité destinataire pour chiffrer le message et l’envoyer à l’entité destinataire. Cela signifie que l’expéditeur n’a pas besoin de mettre à jour fréquemment les données, tant que la Clé publique du destinataire est présente dans les paramètres publics.
Lorsqu’un utilisateur reçoit un message de chiffrement, il vérifie d’abord les informations auxiliaires stockées localement pour voir s’il existe une valeur correspondant à une certaine condition (par exemple, une valeur validée par une vérification). Si l’utilisateur ne trouve pas de valeur correspondant à la condition localement, cela signifie qu’il doit obtenir les dernières informations de mise à jour à partir du contrat intelligent. Une fois que l’utilisateur trouve une valeur auxiliaire appropriée, il peut utiliser cette valeur et sa clé privée pour déchiffrer le texte chiffré reçu et ainsi récupérer le message d’origine.
Évidemment, ce schéma est plus complexe que les deux autres. Mais il nécessite moins de stockage hors chaîne que le répertoire Clé publique et évite également l’hypothèse de confiance forte de l’IBE.
Des paramètres simples :
- La taille des paramètres stockés off-chain est sous-linéaire par rapport au nombre d’utilisateurs, ce qui est beaucoup moins que le volume de stockage requis par le répertoire de clés publiques (hausse linéaire), mais ce n’est toujours pas une constante, donc ce n’est pas aussi bon que les systèmes IBE (chiffrement basé sur l’identité) à ce titre.
chiffrement avec une certaine interactivité :
- Lors de l’envoi de messages, l’expéditeur a besoin d’une copie des paramètres publics contenant le destinataire cible. Cela signifie que l’expéditeur doit mettre à jour ces paramètres à un moment donné après l’enregistrement du destinataire, mais il n’est pas nécessaire de les mettre à jour individuellement pour chaque destinataire, car une mise à jour peut inclure les Clés secrètes de plusieurs destinataires. Dans l’ensemble, l’interaction lors de l’envoi de messages est plus importante que celle de l’IBE, mais moins que celle d’un annuaire de Clés publiques.
Décryptage avec une certaine interactivité :
- Comme le chiffrement, le destinataire a besoin d’une information auxiliaire qui correspond à la version des paramètres publics utilisée lors du chiffrement. Lorsqu’un nouvel utilisateur s’inscrit dans un groupe particulier, les paramètres publics et l’information auxiliaire sont mis à jour, ce qui permet de déchiffrer la valeur du texte chiffré correspondant à la version des paramètres publics utilisée lors du chiffrement. Les utilisateurs peuvent choisir de recevoir régulièrement des mises à jour de l’information auxiliaire, plutôt que de les mettre à jour immédiatement à chaque fois, sauf en cas d’échec de déchiffrement. Contrairement à la mise à jour des paramètres publics, obtenir plus fréquemment des mises à jour de l’information auxiliaire n’exposera pas les informations privées.
Expéditeur anonyme :
- De la même manière que pour le répertoire des Clés publiques, l’expéditeur peut chiffrer indépendamment les messages (tant qu’il dispose des paramètres les plus récents), sans avoir besoin de consulter des informations spécifiques liées au destinataire. Lorsque l’expéditeur doit lire des informations depuis hors-chaîne, ces informations ne sont pas liées au destinataire cible (à moins que l’expéditeur ne demande uniquement un paramètre spécifique pour un regroupement, mais cela pourrait divulguer partiellement des informations).
Transparence :
- Bien que le système nécessite une configuration de confiance (peut-être distribuée ou gérée de manière externe) et génère un CRS corrigé (chaîne de référence publique), une fois la configuration terminée, il ne dépend plus d’un tiers de confiance ou d’un groupe d’arbitrage. Bien qu’il dépende d’un tiers de confiance coordonné (Smart Contract), ce système est entièrement transparent, et n’importe qui peut agir en tant que coordinateur ou vérifier l’honnêteté de son fonctionnement en vérifiant les transitions d’état (c’est pourquoi il peut être mis en œuvre en tant que Smart Contract). De plus, les utilisateurs peuvent demander une preuve de (non) adhésion concise pour vérifier s’ils-mêmes ou d’autres personnes sont enregistrés dans le système. Cela diffère des systèmes IBE, où il est difficile pour un tiers de confiance de prouver qu’il n’a pas divulgué secrètement la Clé secrète de déchiffrement (par exemple, en conservant une copie secrète ou en la divulguant à d’autres). En revanche, le répertoire de Clé publique est entièrement transparent.
Ensemble d’identifiants restreint :
- Cette section décrit la version de base de la construction du RBE. Pour déterminer de manière transparente le groupe auquel appartient un identifiant, l’identifiant doit avoir un ordre commun et déterminé. Les numéros de téléphone peuvent être simplement triés, mais le tri de n’importe quelle chaîne peut être très complexe, voire impossible, car le nombre de groupes peut être très grand ou infini. Cela peut être atténué en fournissant un contrat distinct pour calculer cette correspondance, ou en adoptant la méthode de hachage cuckoo proposée dans un travail ultérieur.
Destinataire anonyme :
- Cette méthode permet de ne pas révéler l’identité du destinataire du texte chiffré.
