INTfs — Protocole pour un partage de fichiers crypté, privé et anonyme sur le réseau INT
(Cet article est une traduction de l’excellent article de Graytrain dont vous trouverez la version originale ici. Merci infiniment à lui pour son travail !)
Résumé
La transmission de données est l’une des fonctions essentielles de l’IoT. Les décisions prises au sein du réseau s’appuieront sur des données pour le faire. Les protocoles existants pour le stockage et la récupération de données dans un réseau distribué adoptent une approche générale et ne prévoient pas de contrôle de la confidentialité des protocoles. IPFS est le leader dans ce domaine mais se concentre sur l’Internet décentralisé. Utiliser le hachage de fichier comme clé de demande pour créer une image de qui-demande-quoi qui peut conduire à une rupture de l’anonymat. INTfs est une approche spécialisée du stockage décentralisé, établissant un pont entre INT et IPFS, qui intègre un protocole pour le cryptage asymétrique non interactif, les demandes de données en aveugle et la preuve de stockage pour la compensation de nœud avec INT Chain comme base transactionnelle.
Introduction
Vue d’ensemble et objectifs
IPFS fournit une base solide pour l’hébergement et le transfert de données distribuées. Il peut être utilisé en tant que cloud personnel, protocole de transfert de fichiers ou back-end HTTP pour un Internet décentralisé. Il combine la distribution de fichiers BitTorrent avec les structures de données Merkle DAG, fournissant une base robuste et sans confiance pour les systèmes de fichiers versionnés ou les chaînes de blocs. Il vous permet de télécharger n’importe quel fichier, quel que soit son format, et de le partager ou d’y accéder par son hachage. Étant donné qu’IPFS ne nécessite pas la capacité de lire le fichier, l’utilisateur est libre de télécharger des fichiers chiffrés mais ne propose pas de système d’indexation de clé ou de clé pour le faire.
D’autres projets ont cherché à utiliser IPFS comme protocole sous-jacent pour produire un service cloud distribué, mais là encore, ces réseaux reposent sur la capacité technique des utilisateurs à obtenir les clés de cryptage et à chiffrer le fichier eux-mêmes avant le téléchargement. Afin d’inciter les nœuds de stockage à participer à ces réseaux, ils introduisent leur propre jeton propriétaire pour les frais et les récompenses, obligeant les utilisateurs à obtenir ce jeton pour pouvoir utiliser le service.
INTfs cherche à résoudre ces problèmes en fournissant une structure pour l’indexation des clés de chiffrement, le chiffrement de fichiers et de messages et le stockage de données sur un réseau basé sur des transactions d’actifs réels, INT Chain. En utilisant le réseau de nœuds existant pour le stockage distribué et le mécanisme de consensus pour sécuriser le système de fichiers, garantir la synchronicité et répartir les frais, nous pouvons fournir tous les avantages des autres réseaux de cloud distribués, à moindre coût et sans jeton secondaire. Cela crée un système de fichiers distribué privé et anonyme avec une confiance minimale au sein d’un réseau existant.
INT Chain en tant que fondement transactionnel
INT Chain est une chaîne de blocs DPoS axée sur l’IoT dotée d’une structure multi-chaînes hétérogène permettant un débit élevé et une scalabilité facile grâce à l’ajout de sous-chaînes. La structure transactionnelle est basée sur un compte comme Ethereum avec une capacité de script limitée. Comme il n’est pas structuré sur des transactions UTXO, il permet plusieurs types de transaction pour le staking, les votes et l’enregistrement de nœuds. Cela crée une structure ouverte pour l’ajout de types de transaction et d’autres mécanismes de publication d’informations sur la blockchain. Le mécanisme de consensus DPoS permet un bloc time de 10 secondes, en faisant pivoter un groupe de 13 noeuds «Thearchy» faisant office de validateurs gérant une chaîne unique à 2 000 TPS dans son état actuel. L’intention d’INT est d’augmenter le nombre de nœuds de validation permettant l’ajout de sous-chaînes, la structure logique de chaque sous-chaîne étant définie pour prendre en charge les différents cas d’utilisation (par exemple, débit de transaction supplémentaire, transactions spécifiques à un dispositif IoT, contrats intelligents, transactions confidentielles, etc.).
Nous supposons que l’état actuel de INT Chain constitue la base transactionnelle et qu’il peut accepter les formats de transaction proposés dans ce document, ainsi que la sous-chaîne supplémentaire permettant de stocker les preuves associées à ce protocole. Les nœuds Thearchy assumeraient la responsabilité de stocker et de servir les fichiers.
Cryptage de données
Le cryptage des données peut être effectué avec des clés symétriques ou asymétriques. Les schémas de chiffrement asymétriques vous permettent de chiffrer des données avec une clé publique, éliminant ainsi le besoin de communiquer au préalable avec le destinataire, contrairement aux schémas de chiffrement symétriques. Les problèmes avec le chiffrement asymétrique sont les temps de calcul nécessaires pour chiffrer / déchiffrer et la taille des clés requises. Les clés symétriques sont beaucoup plus petites mais nécessitent un partage de la clé. La solution la plus pratique consiste à utiliser un système hybride de chiffrement à clé symétrique avec chiffrement asymétrique pour le partage de la clé utilisée pour le chiffrement.
La taille de la clé est la préoccupation suivante. Des clés plus petites facilitent la gestion des données, réduisent les besoins en matériel, réduisent la bande passante nécessaire pour la transmission et réduisent la consommation d’énergie dans les appareils mobiles. La cryptographie à courbe elliptique fournit des clés beaucoup plus courtes pour le même niveau de sécurité par rapport à d’autres cryptosystèmes comme RSA. Pour un niveau de sécurité de 128 bits, suffisamment puissant pour cette application, la longueur de la clé RSA est de 3072 bits, tandis qu’une clé ECC est de 256 bits.
Schéma de chiffrement intégré à courbe elliptique (ECIES)
ECIES est un système de cryptage hybride proposé par Victor Shoup en 2001 [Shoup01]. Il associe un mécanisme d’encapsulation de clé (KEM) à un mécanisme d’encapsulation de données (DEM) pour assurer la rapidité du cryptage symétrique et la sécurité du cryptage asymétrique avec l’efficacité de la génération de clés à courbe elliptique.
Il utilise les fonctions suivantes:
- Accord de clé (KA): fonction utilisée par deux parties pour créer un secret partagé.
- Fonction de dérivation de clé (KDF): fonction utilisée pour créer des paires de clés asymétriques.
- Hash: Fonction Digest.
- Symmetric Encryption (ENC): chiffrement utilisant une clé unique pour chiffrer et déchiffrer
- Message Authentication Code (MAC): information utilisée pour authentifier un message.
Etant donné que les paires de clés public-privé seront générées à l’avance et publiées, ce processus peut être entièrement effectué par la partie émettrice sans aucune communication entre elles.
En utilisant ce protocole pour chiffrer et communiquer un message, m:
- Nous générons d’abord une nouvelle paire de clés publique-privée appelée clé éphémère, représentée par la partie privée u et la clé publique U = u • G.
- À l’aide du protocole d’accord de clé, nous créons un secret partagé en prenant la clé privée éphémère et en la multipliant par la clé publique du destinataire, V.
- Prenez la clé secrète partagée, u • V, comme donnée d’entrée pour le fichier KDF, la sortie étant une concaténation de la clé MAC, k_mac, et de la clé de cryptage, k_ENC.
- Chiffrer le message m, en utilisant l’algorithme de chiffrement symétrique ENC avec la clé, k_ENC. Le résultat est ciphertext, c.
- Utilisez la fonction MAC avec ciphertext, c et la clé MAC, k_mac, pour générer un tag.
- Concaténez la clé publique éphémère, le tag et le cyphertext (U || tag || c) et envoyez ce cryptogramme au destinataire.
Pour que le destinataire décrypte le message m:
- Séparez le cryptogramme en ses parties constituantes, U, tag et c.
- Utilisez la clé publique éphémère récupérée, U, et la clé privée du destinataire, v, pour récupérer le secret partagé, u: v • U = (v·u)•G=u•V
- Générez le chiffrement et les clés MAC, k_ENC’et k_mac’, en utilisant le fichier KDF selon le même processus que l’étape 3 ci-dessus.
- Utilisez la fonction MAC avec le texte chiffré du cryptogramme, c, et la clé MAC, k_mac’, pour produire tag’. Si tag’ n’est pas égal à tag, l’échec de la vérification est impossible. Si égal, continue.
- Décryptez le cyphertext c en utilisant l’algorithme de chiffrement symétrique ENC avec la clé k_ENC. Le résultat est le message prévu m.
Normes
On constate que les normes suivantes produisent un cryptage puissant avec les vitesses de calcul les plus rapides [Mart15].
Pour les opérations sur les courbes elliptiques pour la génération de clés éphémères dans l’Accord de Clé, la courbe elliptique x sur le champ fini Extension Binaire 𝐺𝐹 (2 𝑚) sera utilisée [CPPbench]. Ceci est avantageux pour les implémentations matérielles car ses opérations telles que l’addition et la multiplication peuvent être effectuées par les portes logiques AND et XOR.
Accord de Clé (KA): Diffie-Hellman (DH) offre des avantages par rapport aux autres car il ne nécessite qu’une seule multiplication scalaire.
Fonction de Dérivation de Clé (KDF): KDF2 est largement utilisé et accepté en tant que norme.
Algorithmes de Hachage: afin d’optimiser la sécurité et de minimiser l’utilisation de la mémoire et de la bande passante, nous allons utiliser SHA-256.
Fonction de chiffrement symétrique (ENC): pour optimiser la sécurité et l’efficacité, nous utilisons AES-128 CTR qui ne nécessite aucun padding et est donc plus efficace. L’absence de padding réduit également la charge de décryptage.
Code d’authentification de message (MAC): afin d’optimiser la sécurité et de minimiser l’utilisation de la mémoire et de la bande passante, nous allons utiliser HMAC-SHA-256.
Le protocole INTfs utilisera ECIES pour digérer les hachages et chiffrer / déchiffrer les données et les messages.
INTfs — Protocole de transaction
INTfs fonctionnera comme une couche d’abstraction reliant les chaînes INT et IPFS. L’objectif du protocole n’est pas de changer le fonctionnement d’IPFS mais de fournir une structure d’interaction qui offre des mécanismes de paiement pour le stockage et la récupération des données, de manière à faciliter le cryptage des données avec confidentialité et anonymat pour la réception des données entre les parties. Il vous permet de chiffrer vos données sans avoir besoin de connaître le destinataire, de payer pour la récupération des données sans avoir à révéler ce que vous demandez, de télécharger le fichier sans révéler ce que vous êtes en train de télécharger, pour éviter de provoquer des fuites relatives aux fichiers téléchargés ou aux personnes ayant demandé le fichier.
La structure de base est la suivante:
Enregistrement de clés de cryptage
- Deux utilisateurs créent des clés publiques INT Chain, téléchargent le keystore et leur transfèrent des INT.
- Les utilisateurs créent ensuite des clés de chiffrement INTfs, téléchargent le keystore et créent une transaction de registre pour publier la partie publique de la clé dans la blockchain, en la liant à leur adresse INT.
Téléchargement et envoi d’un fichier
- L’utilisateur A souhaite envoyer un fichier à l’utilisateur B. L’utilisateur A entre l’adresse INT de l’utilisateur B et lui demande de sélectionner le fichier. Il demande ensuite pendant combien de temps ils souhaitent que le réseau INT stocke le fichier et toute note qu’ils souhaitent inclure dans le texte chiffré.
- Le portefeuille interroge le réseau pour connaître la clé publique de chiffrement de l’utilisateur B, chiffre le fichier sélectionné à l’aide du protocole ECIES spécifié ci-dessus avec la clé publique de chiffrement de l’utilisateur B. Il stocke ensuite le fichier crypté localement, nommé par son hachage de somme de contrôle IPFS.
- Le portefeuille chiffre ensuite le message m en utilisant ECIES avec la clé publique de chiffrement de l’utilisateur B, contenant le hachage de fichier, la taille du fichier et la note. Il prend ensuite la taille du fichier ainsi que la durée pendant laquelle l’utilisateur A souhaite stocker le fichier et détermine les frais. Il prépare ensuite la transaction de téléchargement avec l’adresse de l’utilisateur B, le cryptogramme (contenant le hachage du fichier), la durée de disponibilité, les frais et la signature.
- Une fois que le réseau a validé cette transaction, le portefeuille lance le téléchargement du fichier crypté dans IPFS.
Demander un fichier
- L’utilisateur B reçoit une transaction contenant un cryptogramme c, ECIES décrypte ensuite le cryptogramme avec la clé privée de l’utilisateur B pour révéler le hachage, la taille et la note du fichier.
- L’utilisateur B souhaite ensuite télécharger le fichier. Ils créent une transaction de demande contenant le hachage de fichier et le nombre de fois qu’ils souhaitent le télécharger.
- Le portefeuille de l’utilisateur B génère alors un nonce n aléatoire et hache (n || hachage du fichier). Le hachage de (n || hachage du fichier) est la clé de demande. Il enregistre ensuite la relation entre n, hachage de fichier et clé de demande, localement dans la bibliothèque de fichiers.
- Le portefeuille de l’utilisateur B prend alors sa clé de chiffrement publique V = v•G, puis crée un secret partagé S avec la clé de chiffrement publique Thearchy (qui est une clé de seuil 1-sur-n telle que définie dans [Erta07]), T = d•G. par exemple. S = v•T = v•(d•G) = d•Q
- Le portefeuille de l’utilisateur B utilise ensuite le secret partagé S pour chiffrer le message M, contenant nonce n, le nombre de téléchargements x et le hachage de fichier demandé à l’aide du protocole ECIES à déchiffrer par les noeuds de validation.
- Le portefeuille de l’utilisateur B utilise ensuite la taille du fichier et x pour déterminer les frais de téléchargement.
- Le portefeuille de l’utilisateur B prépare la transaction de demande avec le cryptogramme (contenant n, x et le hachage de fichier demandé), les frais et la signature.
- Une fois reçus par les noeuds de validation, ils déchiffrent c avec la clé privée du noeud de validation pour récupérer le hachage de fichier, le nonce et le nombre de fois que le nonce est valide. Ces informations sont stockées dans une base de données partagée liant nonce au fichier hash.
- Une fois cette transaction validée, la clé de demande est maintenant valide pour être utilisée pour le téléchargement.
Télécharger un fichier
- Pour exécuter le téléchargement, l’utilisateur sélectionne un fichier dans la bibliothèque de fichiers. Le portefeuille envoie ensuite la clé de demande aux nœuds.
- Les nœuds interrogent la blockchain pour voir si la clé ReqKey a été «utilisée». Sinon, le nœud publie une transaction «dépensée» contenant uniquement la clé ReqKey.
- Le nœud interroge ensuite la base de données de clés de hachage pour renvoyer le hachage de fichier et l’envoie à IPFS pour lancer le téléchargement.
Calcul des frais
Je n’ai pas pu proposer quelque chose qui réponde à toutes les exigences. Il faudrait tenir compte de la taille du fichier et de la durée de stockage pour le téléchargement de fichier, ainsi que de la taille du fichier et du nombre de téléchargements pour la récupération. Il devrait être suffisamment bon marché pour encourager son utilisation, car il s’agit là d’une extension du réseau, mais pas trop bon marché pour ne représenter qu’un coût supplémentaire sans véritable récompense pour les nœuds. Etant donné que le pool de validation contient un nombre limité de nœuds de stockage, il convient de déterminer une taille de stockage réseau optimale qui indiquerait également les exigences minimales du nœud Thearchy. Les frais devraient compenser le moins possible ce coût.
Le coût de stockage pour VPS est d’environ 0,10 USD par Go et par mois. Les frais doivent donc s’élever à au moins 1,30 USD par Go par mois (0,043 USD par Go par jour) avec le pool de recherche actuel est composé de 13 noeuds.
Des travaux supplémentaires seraient nécessaires pour définir les durées de stockage minimales, mais ils pourraient être divisibles par tranches de 10 secondes (par bloc de la chaîne principale). Le maximum peut être un stockage indéfini, mais une logique de frais devra être définie.
INTfs — Consensus et récompense
Preuve de stockage (PoSt)
Étant donné que la génération de blocs sur la chaîne principale est théoriquement beaucoup plus rapide que toute modification de la base de données de stockage, rechercher un consensus général sur l’état de stockage ou payer les frais de stockage des fichiers pour chaque bloc de la chaîne principale n’a pas beaucoup de sens. Ce qui aurait davantage de sens serait de définir une période de contrôle d’état de l’ordre de quelques minutes et de stocker ce contrôle par consensus comme un bloc sur une chaîne secondaire pouvant être utilisé pour l’autorisation de paiement de la redevance et une vérification indépendante.
La preuve de stockage proposée est un processus en deux étapes, la première étape consiste en un élagage de la base de données IPFS et la seconde étape en un échantillonnage aléatoire de hachages de racine d’arbre Merkle combinés pour créer un hachage unique dans une logique de Preuve de Travail qui servira de preuve de stockage.
La première partie de la machine des états sera dédiée à la rotation du stockage. Au début de chaque processus de création de bloc, les noeuds vérifieront la base de données contenant les durées de stockage. Si l’un des fichiers indique que le bloc actuel correspond à une fin de disponibilité, ils supprimeront les liens vers ce fichier.
La deuxième partie de la machine des états sera dédiée à la preuve que chaque nœud stocke les fichiers dans le temps. Comme il s’agit d’un protocole complémentaire à un réseau transactionnel plus vaste, il n’est pas nécessaire que l’algorithme de preuve par consensus soit complet d’un point de vue sécurité. Les nœuds doivent être testés de manière aléatoire, de sorte qu’il soit très difficile de simuler un résultat valide. Le risque associé au fait de ne pas disposer d’une vérification de stockage plus complète n’aurait aucun impact sur les transferts d’actifs sur la chaîne principale, mais uniquement sur la distribution des récompenses de stockage. La difficulté doit donc être telle qu’il en coûterait plus de falsifier que de récupérer les récompenses associées.
Le processus est le suivant. Dans cet exemple, nous supposons que le temps de blocage PoSt optimal est de 10 minutes ou de 60 blocs sur la chaîne principale:
- Une fois le bloc déclencheur créé sur la chaîne principale, tous les noeuds recherchent les fichiers à supprimer (discardHeight ≤ currentHeight).
- Une fois ce processus terminé, on dérive de manière déterministe un ensemble de challenge vertices à partir du hachage du bloc de la chaîne principale. On interroge le DAG IPFS local pour trouver les racines correspondantes pour tous les points de défi. Retourne les racines.
- Commencez le puzzle avec les quatre racines et un nonce. La difficulté devrait être telle que le temps de réponse moyen du nœud avec une solution ~ 1 minute.
- Si le nœud est le producteur de bloc actuel, envoyez une solution complète sous forme de proposition à tous les nœuds pour valider le travail.
- Si le nœud n’est pas le producteur de bloc actuel, envoyez une solution complète au nœud producteur de bloc pour valider le travail.
- Une fois que tous les nœuds ont validé le travail du producteur de bloc, signez le message et envoyez-le au producteur de bloc.
- Le producteur de blocs valide toutes les propositions et vérifie le travail de tous les nœuds indépendamment en hachant le nonce donné avec les points de défi calculés. On note l’état : valide ou invalide.
- Une fois que toutes les signatures ont été reçues, on créé un bloc avec la preuve du proposant, les racines du défi et toutes les épreuves de noeud avec leur signature. Le résultat est un bloc d’épreuves avec les points de défi donnés, en liaison avec le hachage de bloc qui les a créés, qui peut être vérifié indépendamment par n’importe qui, donnant une liste de tous les nœuds devant recevoir une récompense de stockage.
Ce processus suivra l’itération de la table ronde DPoS existante via les validateurs.
En n’incluant pas les racines dérivées de manière indépendante dans la proposition aux autres nœuds, vous êtes assuré (dans les limites de ce test) d’identifier ceux dont le DAG est incomplet. Lorsque vous validez leur hachage donné avec vos points, les hachages ne correspondent pas.
En exigeant un puzzle de hachage de style PoW avec une difficulté non négligeable et en exigeant une réponse de la part du nœud dans une plage spécifiée, il est plus difficile pour les nœuds de se coordonner pour produire de fausses preuves.
Mécanisme de récompense
Il existe peut-être une meilleure solution à ce problème, mais c’est le meilleur que je puisse proposer. Les frais envoyés lors de la transaction sur la chaîne principale seraient traités dans un contrat intelligent qui ajoute les frais et les durées pour définir un calendrier de récompenses par bloc. Il faut la durée, divisée par les frais, pour déterminer le mode de répartition de ces frais par récompense globale sur une période donnée. Ces informations sont stockées dans une base de données séparée.
Lors de la création d’un bloc PoSt, la chaîne principale exécuterait une transaction de type coinbase pour toutes les adresses fournissant une preuve d’état de stockage valide, les montants indiqués étant déterminés par le (bonus de stockage par bloc) divisé par (le nombre total de nœuds à récompenser).
Lors de la validation des transactions coinbase, le contrat intelligent contenant le pool de frais de stockage brûlerait un montant égal d’INT, maintenant ainsi une inflation nette nulle.
Les implications
La création de la structure transactionnelle telle que décrite nous permet de rompre les liens d’information entre les personnes chargées de l’upload, de la demande et du téléchargement. En chiffrant le fichier, seul le destinataire prévu peut le déchiffrer. En envoyant le hachage de fichier crypté à tLe destinataire, personne ne peut voir quel fichier est envoyé. En chiffrant la demande avec un nonce, personne ne peut voir quel fichier vous demandez. En lançant le téléchargement séparément par une clé de demande, le téléchargement ne peut pas être lié à une transaction de demande et est séparé d’une source de paiement.
Pour briser davantage les connexions et renforcer la confidentialité, le portefeuille du client peut émettre des demandes à partir d’une adresse différente de celle à laquelle les fichiers ont été envoyés et lancer des téléchargements à partir de tout logiciel, via une passerelle ou un VPN.
En spécifiant le nombre de fois où le nonce est bon, vous pouvez payer pour un téléchargement en masse et distribuer un lien avec la clé ReqKey. Les frais de stockage sont calculés en fonction de la taille et la durée de stockage définie par l’utilisateur découragera les gros fichiers et les bases de données stagnantes.
Cela n’a aucun sens de vous demander d‘envoyer des transactions à partir du périphérique sur lequel vous souhaitez télécharger. En payant le téléchargement et en créant votre clé de demande séparément du téléchargement, cela nous donne la possibilité d’utiliser ces clés à partir d’un appareil séparé.
En incorporant INTfs au-dessus du réseau INT, nous pouvons relier la machine des états au mécanisme de consensus du réseau sans avoir à créer un mécanisme autonome tolérant face aux pannes avec un jeton dédié. Cela réduit le coût global de l’intégration, ce qui rend le service compétitif et simplifie la mise en œuvre.
Comme ce protocole de stockage et de consensus est distinct du consensus de la chaîne principale et que les exigences de débit sont beaucoup moins importantes, les nœuds participants peuvent inclure un deuxième ensemble de nœuds, éventuellement un deuxième enregistrement pour ce travail. cela élargirait la portée géographique des nœuds, augmenterait le stockage et la bande passante pour l’ensemble du réseau.
INTfs ne demandera pas à l’utilisateur de chiffrer les fichiers stockés sur le réseau et peut même héberger des répertoires entiers de données.
Le système ECIES peut être plus généralement utilisé pour créer un cryptage asymétrique pour les applications de données IoT allégées, y compris les MANET.
Questions ouvertes
Calcul des frais
Il reste du travail à faire pour déterminer la logique et la tarification appropriée afin d’obtenir la participation souhaitée des nœuds et des utilisateurs. C’est du travail pour quelqu’un de plus intelligent que moi.
Décryptage du seuil du noeud de validation
Le décryptage de seuil a été passé sous silence dans la section Transaction de récupération de ce document. Pour chiffrer le message de manière à ce que l’un des noeuds du groupe de validation puisse le déchiffrer, une clé de seuil 1-sur-n est nécessaire.
Cette clé nécessite que tous les détenteurs de clés partagent des secrets afin de créer une clé publique agrégée. Le pool de validation n’étant toutefois pas statique, il devrait exister un système grâce auquel la clé de seuil de groupe est recalculée et distribuée lors de la saisie d’un nouveau validateur.
Les attaques
En théorie, il serait possible de forcer des données dans IPFS sans payer les frais de stockage en contournant complètement la transaction de téléchargement ou en transmettant au logiciel une transaction valide en tant que preuve de paiement autre que le fichier en cours de téléchargement. Des sauvegardes doivent être mises en place pour nettoyer la base de données de stockage des fichiers qui ne portent aucune date de suppression. Les utilisateurs ne pourront pas récupérer ces fichiers sans paiement, bien que les hachages ne soient pas connus.
Pour simuler une preuve de PoSt, il suffit de s’entendre avec un autre nœud pour recevoir les racines du défi à temps afin de trouver une solution au PoW dans les délais impartis. Je suis sûr qu’avec plus de réflexion et de discernement autour de la difficulté du PoW, cela peut être résolu ou du moins nettement moins probable.
Anonymat IP
Afin de rendre ce protocole plus anonyme, des passerelles et un routage inconscient pourraient être mis en œuvre pour les téléchargements de fichiers qui séparent davantage le téléchargeur de la mémoire du réseau.
À mesure que les transactions transitent sur le réseau, des informations sur l’origine et la provenance des transactions peuvent être divulguées à l’endroit où elles sont vues à la base dans les nœuds du réseau. Cela peut permettre de déterminer qui possède quelle adresse, simplement en surveillant les transactions à partir de cette adresse et en sélectionnant les nœuds qui les récupèrent en premier. Dandelion ++ est un protocole qui assure l’anonymat en p2p. L’implémentation de Dandelion ++ compléterait ce protocole, ce qui en ferait un protocole de récupération de fichiers totalement exempt de fuites d’informations.
Sur la confiance
L’objectif est de décomposer le graphique de transaction autant que possible. Pour que le réseau vous fournisse le fichier que vous voulez, vous avez besoin d’un moyen d’indiquer en quoi consiste ce fichier et où vous souhaitez l’envoyer. Cela semble être le plus petit dénominateur commun que vous pouvez trouver. Dans ce cadre, nous limitons les vecteurs d’attaque en chiffrant chaque étape et en rompant le lien de transaction, mais les nœuds Thearchy conservent certaines informations. Ils savent quelle adresse a posté quel fichier, quelle adresse a été payée pour le recevoir et quelques informations limitées sur qui l’a réclamé.
Nous pouvons minimiser cela davantage en régénérant la clé de seuil dans une période définie. Cela sera nécessaire au fur et à mesure que de nouveaux validateurs entreront dans le pool, mais si cela est fait régulièrement, cela rendrait les epoch précédentes de transactions de requête cryptées indécryptables et donc incapables de se lier à une clé de requête spécifique. Tout ce qui serait stocké est un nonce (nombre aléatoire) pour archiver la relation de hachage.
Notes et références
Le déroulement général du processus ECIES est basé sur les travaux de V. Gayoso Martínez, L. Hernández Encinas et C. Sánchez Ávila et leur travail présenté dans «Un aperçu du schéma de chiffrement intégré à courbe elliptique» [Mart10].
[Shoup01]https://www.shoup.net/papers/iso-2_1.pdf
[Mart10] http://digital.csic.es/bitstream/10261/32671/1/V2-I2-P7-13.pdf
[Chen17]https://pdfs.semanticscholar.org/a00d/79d4d9fac939469be3a04d34d6ec5b92bcdf.pdf
[CPPbench]https://www.cryptopp.com/benchmarks.html
[Erta07]https://pdfs.semanticscholar.org/fca5/8019046317d03328eb38b61ad5dcbf83c6f6.pdf
