Un mécanisme de cosignature fonctionnant sur le principe de quota peut être une réponse possible à la validation de transactions dans un groupe fermé d’entités. La difficulté est que chaque entité peut ne pas reconnaître la même composition du groupe du fait du traitement social des liens du groupe. Mais si le groupe est explicitement définit dans l’objet de groupe avec le quota attendu, alors cela devient jouable…
Mois : août 2019
Documentation technique de nebule – 020190821
Documentation technique de nebule
Version 1.3 – 020190821 Developpement
(c) GNU GPL 2010-2019 Projet nebule – www.nebule.org
— Copie en attendant la mise en ligne —
Continuer la lecture de Documentation technique de nebule – 020190821
Transcodage et translation
Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle, transcodage, Transcodage des liens dissimulés et Anonymisation des fichiers transcodés, il était apparu un problème avec le contenu des fichiers transcodés.
Le transcodage des identifiants des objets pour lesquels on dissimule des liens permet de stocker ces liens dans des fichiers non directement associés à l’identifiant de l’objet concerné. C’est en fait une translation d’identifiant.
Ces objets ‘virtuels’ translatés doivent pouvoir être partagés par transfert ou synchronisation sans risquer de dévoiler l’association entre l’identifiant en clair et l’identifiant translaté.
Le système de translation aujourd’hui mis en place est basé sur une clé unique de translation par entité. Cette translation doit être une fonction à sens unique, donc à base de prise d’empreinte (hash), y compris lorsqu’une ou plusieurs translations sont connues. Enfin, la translation doit être dépendante de l’entité qui les utilise, c’est à dire qu’une même clé peut être commune à plusieurs entités sans donner les mêmes translations.
PFS et liens dissimulés
La méthode de PFS sans connexion spécifique à nebule est sensible à la capture de trafic ou la surveillance des créations de fichiers directement sur un serveur compromis. C’est aussi vrai en regardant simplement la date des fichiers.
L’article décrivant le mécanisme est encore à rédiger.
Cependant, peut-être que la dissimulation de liens et le travail sur une système de fichier sans mémoire temporelle peuvent aider à renforcer cette PFS. A voir…
Monnaies, transactions et individus
Il existe deux méthodes pour gérer les échanges de valeurs entre deux entités, ou individus.
La première consiste à suivre des objets définis comme de la monnaie et de faire des transactions de réattribution de ces objets entre entités. Le solde pour une entité est l’addition de la valeur tous les objets de monnaie en possession de l’entité.
La seconde consiste à suivre pour chaque entité un indicateur de balance de la valeur dont dispose chaque entité. Le solde est à lecture immédiate et toute transaction consiste en la soustraction d’une valeur sur un compte couplé à l’addition de la même valeur sur un autre compte.
La seconde méthode ne fonctionne pas ou très mal dans le cadre d’une cryptomonnaie sans intermédiaire de confiance, c’est à dire sans une banque pour centraliser le compteur des valeurs des comptes. La transmission de valeur devient complètement impossible sans échange avec l’intermédiaire de confiance.
Mais la première méthode n’est pas forcément mieux loti. Elle permet dans le monde réel un échange de billets sans passer par un intermédiaire de confiance. Mais dans le monde informationnel (dit aussi virtuel ou numérique), la propriété d’unicité spatial et temporel n’existe plus. Et donc il faut sceller à la vue de tous une transaction avec un intermédiaire de confiance. Celui-ci peut être une chaîne de blocs, ça ne fait que décaler l’intermédiaire de confiance vers le code et ses concepteurs.
Continuons sur la réflexion d’une cryptomonnaie.
On voit aujourd’hui plusieurs acteurs étatique ou organisationnels générer de la monnaie virtuelle et/ou revendiquer sa régulation. L’extrême limite de cette pratique serait que tout le monde puisse générer sa propre monnaie… et donc qu’il y ai des taux de change entre les monnaies de tous les individus.
Chaque individu et chaque robot peut justifier d’une certaine quantité de travail par unité de temps, par exemple on peut supposer que l’humain dispose de 16 heures d’activité par jours. Dans ces 16 heures, on va réduire à 8 heures la part allouable à autrui. Mais cette capacité de travail n’a pas de valeur directe, ce n’est pas parce que l’on a une capacité de travail de 8 heures par jour que l’on va travailler 8 heures par jour. Cependant, chaque individu peut générer chaque jours une valeur, comme une monnaie, qui représente la capacité de travail journalier. Appelons la monnaie temporelle.
Il reste encore à donner de la valeur à cette monnaie temporelle.
D’un autre côté nous retrouvons des entreprises, regroupement d’individus, qui utilisent le temps de travail disponible des individus sur un patrimoine constitué d’outils de travail ou de données afin de transformer des objets, et donc d’ajouter de la valeur. Nous pourrions associer la monnaie temporelle des différents employés avec une sorte de monnaie patrimoniale afin de dégager une monnaie véhiculant de la valeur, laquelle monnaie serait rétrocédée en partie aux employés.
Comment seraient représentées ces différentes monnaies dans un système d’information ?
La réflexion n’est pas terminée…
Cosignature Рm̩thode de surcharge des signatures
Dans la continuité de la réflexion sur la cosignature, suite et orientation, voici une première réflexion sur un méthode alternative.
Une autre méthode est possible afin de remplir de rôle de co-signataires multiples à seuil sans répartition d’un unique secret saucissonné entre plusieurs entités ni nécessité de colocalisation spatial et temporel des entités signataires.
Le point de départ est un objet contenant la liste des combinaisons possibles de cosignatures, c’est à dire les différentes associations de signatures d’entités reconnues valides. La syntaxe de définition de ces associations peut prendre différentes formes. Soit on écrit toutes les associations des entités signataires possibles, soit on écrit les identifiants des entités signataires et la règle de quota attendu.
La signature d’un lien nécessite de s’accorder sur le champ de la valeur de la signature et sur le champ de l’entité signataire.
Le cÅ“ur de la méthode est de réaliser une surcharge progressive des signatures des différentes entités co-signataires jusqu’à obtenir le quota d’une combinaison valide. Cette surcharge est une sur-signature progressive du lien par les entités. Une première entité signe le lien, une seconde entité signe la valeur de la signature de la première, une troisième signe la valeur de la signature de la seconde, etc…
La signature n’étant pas une opération commutative, la vérification de la signature finale doit être vérifiée en réalisant les opérations successives de vérification de signatures avec les clés publiques des entités, mais en sens inverse des signatures. Le cas de tailles de clés différentes n’est ici pas traité.
Comme on réalise une sur-signature progressive et que l’ordre est important, il faut que cet ordre des entités signataires apparaisse quelque part. Il faut aussi que l’on fasse apparaître l’identifiant (ID ou hash) de la pseudo entité co-signataire. Pour cela on va utiliser le champ signataire. On place pour commencer l’ID de la pseudo entité co-signataire puis on concatène successivement et dans l’ordre de signature les ID des entités signataires.
Ce mécanisme nécessite à priori la réunion des différents signataires, ou d’une partie suffisante, afin de réaliser la signature du lien. Il est cependant possible de constituer progressivement la cosignature en sur-signant la signature commune et en s’ajoutant à l’entité signataire finale. Nous répondons bien dans ce cas à une cosignature sans colocalisation spatial ni temporel.
Billets et entité
La réflexion continue autour d’une implémentation d’une monnaie virtuelle.
L’idée que le billet électronique est une entité, donc un bi-clé cryptographique, est intéressante à étudier. Cela permet de le rendre autonome mais il faut dans ce cas considérer que sa clé privée devient publique ou connue de plusieurs autres entités, ce qui revient au même. On ne peut donc pas supprimer la nécessité de gérer la confiance via un tier de confiance ou une chaîne de blocs pour consolider le graphe des transactions.
Mais si ce billet électronique est constitué de la chaîne des entités du billets, alors on a un mécanisme d’anonymisation.
Lien de transaction
La réflexion continue autour d’une implémentation d’une monnaie virtuelle sur la base de nebule, donc une crypto-monnaie.
Dans ce cadre, une transaction peut/doit devenir notamment devenir immuable et définitive. Si il serait possible de mettre en place un tel mécanisme et algorithme avec des liens supprimables, il serait cependant plus judicieux et clair de disposer d’un lien explicitement non supprimable. Cela renforce la confiance dans le mécanisme. Ce serait un lien de transaction, type t ?
Cependant cela demande à modifier des parties critiques des algorithmes de traitement des liens… et les alourdis un peu…
Et comment gère-t-on l’oubli volontaire de ces liens ?