Structure de donnés des liens v2:0

  • L : BH_BL_BS
    • BH : RF/RV
      • RF : APP:TYP
        • APP : nebule
        • TYP : link
      • RV : VER:SUB
        • VER : 2
        • SUB : 0
    • BL : RC/RL/RL…
      • RC : MOD>CHR
      • RL : REQ>NID>NID>NID…
        • REQ
        • NID : hash.algo.size
    • BS : RS/RS…
      • RS : NID>SIG
        • NID : hash.algo.size
        • SIG : sign.algo.size

BH_BL_BS

RF/RV_RC/RL/RL_RS/RS

APP:TYP/VER:SUB_MOD>CHR/REQ>NID>NID>NID/REQ>NID>NID>NID_NID>SIG/NID>SIG

nebule:link/2:0_0:020210308124933/l>hash.sha2.256>hash.sha2.256>hash.sha2.256_hash.sha2.256>sign.algo.size/hash.sha2.256>sign.algo.size

Structure

Fichiers

Pour chaque nœud va être associé un certain nombre de liens. Ces liens sont stockés, par nœuds, sous forme de fichiers dans le dossier des liens /l . Dans chaque fichiers, les liens sont séparés par un espace ou un retour chariot. Le retour chariot est à privilégier.

Liens

Chaque liens d’un fichier est composé de :

  • BH (blockhead) : Bloc d’entête.
  • BL (blocklinks) : Bloc de liens.
  • BS (blocksigns) : Bloc de signatures.

Chaque type de bloc est obligatoire et ne doit être présent qu’une seule fois. Lles blocs doivent être ordonnés BH, BL puis BS. Le séparateur inter-blocs est _ . Un lien a donc la forme :

BH_BL_BS

Blocs

Dans chaque bloc on va trouver des registres :

  • RF (regform) : Registre de forme. Bloc BH. Unique. Début.
  • RV (regversion) : Registre de version. Bloc BH. Unique.
  • RC (regchrono) : Registre de chronologie. Bloc BL. Unique. Début.
  • RL (reglink) : Registre du lien. Bloc BL. Multiple.
  • RS (regsign) : Registre de signature. Bloc BS. Multiple.

Les registres sont dédiés à des blocs particuliers. Tous les registres dédiés à un bloc doivent être présents dans le bloc. Certains registres doivent être unique dans leur bloc, d’autres peuvent être multiples. Certains registres sont forcément présent en début de bloc.

La structure des blocs est fixe même si certains registres peuvent être multiples :

  • BH : RF/RV
  • BL : RC/RL/RL/RL…
  • BS : RS/RS/RS…

Le séparateur inter-registres est / .

Registres

Certains registres vont contenir des éléments dans un ordre définit :

  • APP : application. Registre RF. Unique. Début.
  • TYP : type de contenu. Registre RF. Unique.
  • VER : version majeur. Registre RV. Unique. Début.
  • SUB : sous-version. Registre RV. Unique.
  • MOD : mode d’utilisation de la marque chronologique. Registre RC. Unique. Début.
  • CHR : valeur de la marque chronologique. Unique. Registre RC.
  • REQ : requête d’action sur le lien. Registre RL. Unique. Début.
  • NID (node id) : identifiant de nœud (ou de l’objet). Registre RL et RS. Multiple dans RL. Unique dans RS. Début dans RS.
  • SIG (sign) : valeur de la signature. Unique. Registre RS.

La structure des registre est fixe même si certains éléments peuvent être multiples :

  • RF : APP:TYP
  • RV : VER:SUB
  • RC : MOD>CHR
  • RL : REQ>NID>NID>NID…
  • RS : NID>SIG

Le séparateur inter-éléments est > ou : en fonction du registre concerné.

Éléments

Les blocs et registres sont structurants de l’information. Les éléments sont contenants de l’information.

  • APP = « nebule ».
  • TYP = « link ».
  • VER = « 2 ».
  • SUB = « 0 ».
  • NID : l’identifiant de nœud ou d’objet = hash.algo.size
    • hash = valeur de l’empreinte.
    • algo = famille d’algorithme utilisé pour le calcul de l’empreinte.
    • size = taille de l’empreinte
  • SIG : signature
    • sign = valeur de la signature
    • algo = famille d’algorithme utilisé pour le calcul de l’empreinte avant signature.
    • size = taille de l’empreinte

Vérifications

La vérification d’un lien se fait en trois étapes. La première étape va vérifier que le type et la version sont supportés. La seconde étape va permettre de vérifier la structure complète. La dernière va prendre les blocs BH et BL avec leur séparateur et vérifier la/les signature/s.

L’application qui exploite les liens va garder chaque registre de lien décomposé avec les entités signataires. Les signatures non reconnues seront ignorées.

Limites

Il y a un certains nombre de limites dans les quantités acceptables des registres et éléments que peuvent contenir un lien ainsi que de la taille des contenus. Ces limites ne sont pas définies dans le lien et ne sont pas dépendantes de la version du lien mais dépendent du paramétrage de l’application qui lit le lien.

Graphe des mises à jour – DAG

Comme on l’a vu dans l’article Objet de référence contre suivi du graphe des mises à jours il suffit de suive le graphe des mises à jour d’un objet de code afin de trouver la version la plus récente.

Le graphe orienté acyclique (DAG) permet une optimisation. En ajoutant eu fur et à mesure des mises à jour des liens supplémentaires vers des version beaucoup plus anciennes et pas juste la dernière, on crée des raccourcis dans le graphe et on accélère la recherche de la dernière version. Cependant cet usage doit être modéré afin de ne pas au contraire saturer la recherche de liens inutiles à lire, et à vérifier.

Lien, structure et nomenclature

La structure des liens est en cours de révision. La structure que l’on doit utiliser se doit d’être une représentation d’un arbre le plus équilibré possible afin d’accélérer le traitement et de permettre une réutilisation de code.

La structure de base est répartie en trois parties successives appelées blocs. Le premier est le bloc entête de version qui a pour rôle de définir la façon de traiter l’ensemble. Le second est le bloc des registres de liens. Le dernier est le bloc des signatures. Ces blocs sont obligatoires, sont non interchangeables et sont uniques. Les blocs sont séparés par le caractère _ .

La référence au bloc de la blockchain n’est pas anodine, le second bloc pourra contenir plusieurs liens que l’on pourrait appeler transactions. Il est dans ce cas facile d’ajouter dans ce bloc un lien vers le bloc précédent.

La partie la plus petite de cet arbre est appelée élément. Un élément peut être un identifiant d’objet, un horodatage, un champs action ou un identifiant de version. Cet élément est manipulé directement sans traitement. Il peut cependant être subdivisé soit avec un . soit avec un - . Le premier séparateur sert dans les identifiants d’objets afin de distinguer la valeur de l’empreinte et en extension l’algorithme utilisé.

Ce début de nomenclature n’est cependant pas clôt. L’ensemble des blocs ne peut plus être nommé lien au sens propre du graphe. Et il faut définir la forme du contenu du bloc de liens ainsi que du bloc des signatures.

Graphe et nomenclature

Dans nebule, les liens entre les objets forment ce que l’on nomme un graphe orienté.

Dans les graphes, un lien (ligne ou arête) relie deux objets (nœuds ou points). Dans nebule, les liens relient potentiellement plusieurs objets simultanément. Mais ce n’est pas incompatible avec la théorie. On relie principalement un objet source et un objet destination. L’objet d’opération (ou méta) peut être vu comme une sorte de coloration du lien. Et si un quatrième objet est présent, l’objet de contextualisation, il va surtout servir à réduire les liens que l’on prend en compte à instant donné, c’est plus comme un filtre.

Il ne semble pas opportun de renommer les objets et liens dans nebule. Cependant, il existe des objets un peu particuliers qui n’ont pas de contenu. Leur identifiant n’est pas généré par rapport à un contenu mais est directement généré, souvent aléatoirement. Par construction, ce genre d’objets ne devraient pas pouvoir être rattaché à un contenu. Au pire, même si un contenu était découvert pour l’un de ces objets, n’étant pas attendu il ne devrait pas être utilisé. Ces objets sans contenus par construction seront désormais appelés nœuds. En construisant un identifiant de nœud qui ne correspond en taille à aucun algorithme de hash, on s’assure qu’il ne sera jamais associé à un contenu. Si la taille de son identifiant correspond à un algorithme de hash, peut-être que ce nœud est en fait un objet dont on n’a pas eu le contenu.

Séparateurs et horodatage

Il y a deux philosophie de segmentation des données. La première consiste à encadrer les données, par exemple le XML ou le HTML. Chaque texte est encadré. Chaque partie est elle même encadrée. Les parties sont indépendantes et syntaxiquement interchangeables. Les encadrants sont obligatoirement ouverts et fermés. Il est possible de hiérarchiser les informations d’une partie en les plaçant dans des sous-parties incluses dans la partie. Les sous parties peuvent avoir les mêmes encadrants que la partie principale.

La seconde philosophie consiste à séparer les données. On ne délimite plus une donnée mais on marque la fin d’une donnée et donc implicitement le début de la suivante. L’absence de séparateur marque aussi la fin d’une donnée mais dans démarrer une autre donnée. Il existe bien un séparateur dans ce cas aussi mais il marque la fin d’un document… c’est à dire un niveau de données de plus haut niveau. Une hiérarchisation est possible en utilisant plusieurs séparateurs différents.

Cette seconde méthode a des avantages, et pas seulement en place économisée par rapport à des encadrants. Mais elle a comme inconvénient de consommer plus de (caractères) séparateurs.

Dans les liens nebule, la marque de temps à la norme ISO 8601:2004 consomme elle aussi de multiples séparateurs. Il n’est dès lors plus possible de les utiliser comme séparateur au même niveau ou au niveau supérieur. On peut cependant en gagner un, le / de séparation des périodes de temps est invalide pour un lien puisque la marque de temps doit impérativement être ponctuelle. C’est cette marque de temps qui va poser le plus de contraintes sur les séparateurs des liens… sauf à ne pas utiliser cette norme. Éternel débat en fait.

Il reste quand même plusieurs caractères utilisables comme séparateur :
_ / # = * % & @ $ ! ; ~ ( ) { } [ ] < >
Et hors concurrence avec la marque de temps :
- + :

Tout un monde…

Structure de liens et RDF

L’étude de la structure de liens à quatre champs objets (quoi quatre champs) crée un parallèle avec la structure du RDF et le bloc des blockchains.

La possibilité de permettre plus de trois champs dans la partie registre du lien crée de nouvelle possibilités certes à la marge mais qui peuvent avoir une utilité. Le premier est d’apporter un contexte à une opération entre source et destination. D’ailleurs, le champ méta devrait s’appeler opérateur. Et comme une opération peut avoir plusieurs contextes possibles le nombre de champs peut dépasser 4. Il faut cependant mettre une limite aux nombres de champs acceptables dans un lien.

signature_signataire_date_action_source_cible_opération_contexte

Mais plutôt que d’ajouter des champs, ou en plus, il est possible de prévoir de gérer deux registres de liens dans un même lien. Voir d’en gérer beaucoup plus. On s’approche là de la mise en forme d’un bloc chère aux crypto-monnaies. Dans cette forme, une partie commune contient la signature et la référence de temps. L’action doit rester associé au cœur du registre de lien. L’action permet aussi de marque un lien dissimulé et donc de le traiter comme tel. Cela nécessite de modifier la forme du lien

signature_signataire_date/action_source_cible_opération_contexte/action_source_cible_opération_contexte

Sous cette forme nous pouvons rejoindre la forme RDF en permettant la réutilisation de champs par indexation. Par exemple lien second cœur de lien peut référencer les objets 1 et 2, ou 1 et 4 du premier cœur de lien. Cela abrège l’écriture, prend moins de place mais complexifie la lecture.

signature_signataire_date/action_source_cible_opération/action_2_1_opération
signature_signataire_date/action_source_cible_opération_contexte/action_1_cible_opération_4

Une autre approche est de mieux délimiter le cœur de lien afin d’ajouter d’autres informations autour. Il n’y a pas une grande quantité d’information à ajouter, ce peut être de multiples signatures, notamment dans un système de cosignature à seuil. Et, à force d’ajouter des choses dans l’enregistrement des liens, il devient utile de placer une version. Les propriétés exploitables du lien seront directement liées à la version donnée. On arrive ainsi à trois types de blocs dans un lien : la version, les registres de liens et les signatures. Là encore la forme du lien enregistré se complexifie pour permettre de retrouver toutes ces parties sans ambiguïté. Et notamment, chaque partie doit être identifiée avec un préfixe, sauf la version si elle est placé avant le reste. La partie horodatage quand à elle doit aussi faire partie de ce qui est signé, dont elle migre vers les cœurs de liens.

(version)(lien/date_action_source_cible_opération)(lien/date_action_source_cible_opération_contexte/action_1_cible_opération_4)(signe/signature_signataire)(signe/signature_signataire)

Il faut cependant veiller à la défendabilité de la structure ainsi créée. Les signatures sont indépendantes les unes des autres et chaque signature doit couvrir la version et tous les cœurs de liens pris dans le même ordre. Jusque là la vérification des liens se faisait après reconstitution de chaque champs et nettoyage afin d’éviter une tentative de contournement. Ce nettoyage préliminaire peut être maintenu même si il sera plus gourmand en temps de calcul.

Cette forme apporte un nouvel intérêt. Puisque les signatures sont séparée, elles deviennent dissociables. Cela veut dire que l’on peut fusionner plusieurs liens identiques mais avec des signataires différents et donc gagner en place.

Champ action du lien – action supplémentaire de transaction

Il était possible de créer une nouvelle action dédiée aux transactions et non annulable, cf l’article Lien de transaction, ce qui aurait nécessité une grosse modification du code de la bibliothèque.

Finalement cette nouvelle action ne sera pas implémentée, il est possible avec la gestion des relations sociales spécifiques à une monnaie de supporter une suppression de transaction par son initiateur mais sans effet de cette suppression si la transaction a déjà été validée par ailleurs.  dans ce cas c’est comme si la transaction marqué par l’utilisateur était une demande de transaction et que celle-ci était validée par une autorité reconnue au niveau de la monnaie.

Oubli, nettoyage et suppression des liens

Suite des articles Nettoyage des liens et suite, et Suppression et oubli. Le sujet est déjà ancien et il y a eu quelques réflexions sur les objets mais rien de concert n’a été mis en place. Cette absence d’implémentation s’explique parce que la gestion des relations sociales dans les liens n’est pas assez avancée. Le but est double, gérer le stockage et améliorer les performances.

Cependant il est possible de continuer la réflexion notamment sur les liens qui n’ont pas les mêmes contraintes que les objets. La gestion des liens dissimulés dans des fichiers de liens spécifiquement nommés a créé une brèche dans le nommage strict des fichiers de liens. Une première tentative avait commencée avec le stockages de liens anciens dans des fichiers de liens avec un chaînage au fichier d’origine mais n’avait pas abouti du fait de plusieurs problèmes.

Aujourd’hui il est possible de gérer les liens suivant deux méthodes, l’ancienneté et/ou le surnombre. Et cela va trouver une solution dans deux type d’actions, la suppression ou la mise à l’écart dans des fichiers d’archivage datés dédiés. Il faut une option d’activation de l’oubli des liens, une option de sélection de la méthode et option de sélection de l’action. On peut envisager d’utiliser les deux méthodes simultanément.

Pour la méthode de l’ancienneté, il faut distinguer quel type de lien on doit garder disponible immédiatement. Cela veut dire des options par types de liens pour dire l’ancienneté maximale attendue. La notion de sociabilité des liens et intéressante aussi parce qu’il suffit de garder un seul lien signé par l’entité ayant le plus gros score social.

Pour la méthode du surnombre, il faut aussi distinguer le type de lien parce que certains liens sont indispensables au bon fonctionnement d’un objet. Pour chaque type de liens, on garde les liens les plus récents à concurrence du nombre autorisé. Il faut une option par type de liens de définition du nombre à garder pour chaque types. Peut-être faut-il prévoir une gestion sociale afin de pondérer l’ordre des liens et de garder les liens les plus pertinents.

Certains objets ont des rôles importants comme les codes des applications. Ils sont assez facile à gérer parce que les liens sont signés d’une autorité maîtresse du code. Cela va peut-être nécessiter la création d’un nouveau type social mixant strict et réputation pour les gérer encore plus facilement.

Pour l’action de suppression c’est facile, il suffit de ré-écrire le fichier des liens d’un objet en ne gardant que ceux désirés. Les autres liens sont oubliés et perdus localement. Il n’y a pas de mécanisme de corbeille, si besoin il faut basculer sur l’action de mise à l’écart.

Pour l’action de mise à l’écart, on ré-écrit les liens désirés dans le fichiers des liens de l’objet et on écrit les autres liens dans un autre fichier avec un nommage spécial. Ce nommage commence par l’identifiant de l’objet et se voit ajouter une marque de temps et une valeur aléatoire. L’identifiant permet de relier les liens contenus à l’objet concerné. La marque de temps permet de remonter dans le temps progressivement en cas de besoin. La valeur aléatoire empêche la récupération à distance des liens anciens. Le datage se fait à la journée, reste à choisir la base de temps utilisée.

La mise à l’écart de liens avec un horodatage permet un nettoyage facile à posteriori des liens anciens. Et cela permet aussi localement d’activer une utilisation des liens plus anciens sur la sélection d’une date de départ mais au prix de performances dégradées. Ce paramètre de recherche temporelle doit être un argument de l’URL des applications et doit être contrôlé par une option d’autorisation pour une entité déverrouillée ou non.

Ensuite il y a deux stratégies pour rechercher et traiter les fichiers de liens trop gros et/ou avec des liens trop anciens. Soit on fait une recherche globale systématique à intervalle régulier ou lorsque que les performances baissent. Soit on met en place lors de la lecture des fichiers de liens des détecteurs à seuils afin de détecter à l’usage les fichiers de liens nécessitant un nettoyage, et on les traitent immédiatement ou à intervalle régulier.

Lien à quatre champs objets – quoi

Suite des articles Lien à quatre champs objets et Structure du lien à quatre champs objets.

Avant de réorganiser le registre des liens il faut réfléchir aux besoins.

Ajouter un champs version du (registre du) lien est intéressant parce qu’il permettrait nativement des évolutions et des scissions dans la gestions des liens. La scission des liens n’est clairement pas un but parce qu’il introduit des incompatibilités de communications entre différentes communautés (comme les langues), mais c’est une possibilité qui serait ouverte.

Le cœur du registre des liens avec aujourd’hui un triptyque de champs source_destination_méta pourrait devenir un champs unique contenant des sous-champs en plus grand nombre (mais strictement limité). Ce champs unifié cœur du registre pourrait avoir 4 sous-champs pour source-destination-opération-contexte et recevoir en plus le champs action. Doit-il en avoir plus ? Est-ce que l’on peut utiliser un autre modèle type qui-quoi-quand-comment-pourquoi… ?

Le lien doit aussi pouvoir facilement supporter la dissimulation de lien, c’est à l’offuscation de du cœur du registre du lien.

Par contre, il n’est toujours pas opportun de gérer dans un lien de multiples cœurs de lien à la façon du RDF.

Si refonte du lien, cela entraînera un nouvellement complet des implémentations des librairies et des applications avec une incompatibilité forte avec l’existant.

Structure du lien à quatre champs objets

Suite de l’article Lien à quatre champs objets.

La présence d’un champs de lien supplémentaire reste à la réflexion très tentant.

Un lien à quatre champs peut avoir simplement la même structure que le le lien actuel en ajoutant un champs à la fin. Cependant il peut être intéressant, vu l’expérience sur les liens actuels, de changer significativement la structure du champs et notamment son ordre. Ce ré-ordonnancement permettrait aussi de résoudre d’autres problèmes plus accessoires.

L’un des problèmes aujourd’hui vu comme accessoire est le non typage algorithmique (hash) des empreintes des objets. Ce non typage se retrouve dans les champs des liens. On pourrait préciser celui-ci en fin de hash pour le stockage des objets et aussi dans les liens.

Un autre problème est plus conceptuel dans la structure des liens. On définit les champs source, destination et méta comme un triptyque sujet-complément-verbe. Mais la partie signature ne respecte pas cette philosophie. Et il se trouve aujourd’hui que la réflexion qui a mené la signature à être en début de lien n’a jamais été utilisée en pratique.

Enfin, une des dernières réflexions en cours concerne la multi-signature cumulative (cosignature). elle est possible avec le lien actuel moyennant une adaptation mineure du registre des liens. Mais cette nouveauté pourrait être améliorée et fiabilisée avec un nouveau registre qui l’inclut dès la conception.

Options et subordination

Suite des articles Liens des options et Lien à quatre champs objets.

Il paraissait intéressant de pouvoir définir les options d’une entité sous contrôle comme une instance sur un serveur. Cela voulait dire contextualiser le lien or les trois champs des liens de définition des options étaient déjà utilisés. Mais comme il est possible de fusionner le champs option avec le champs définissant de quelle option on traite, cela libère une champs pour une entité cible.

Les liens de modification des options ont été changés dans la bibliothèque nebule afin de prendre en compte ce changement. L’entité est en champs source. Le hash de la valeur de l’option est en champs cible. Et le champs méta contient le hash du nom de l’option préfixé par nebule/option/.

Et une nouvelle option subordinationEntity permet de définir une entité de subordination, c’est à dire une entité qui peut forcer les options. C’est utiliser typiquement pour définir les options d’une instance sur un serveur distant (qui n’est pas sous contrôle physique). Cette option est en lecture seule, c’est à dire qu’elle ne peut être modifiée que via le fichier d’environnement.

L’option doit renvoyer un identifiant d’entité mais plus tard il sera possible de mettre en groupe d’entités…

Le bootstrap affiche maintenant aussi cette entité de subordination dans la page d’interruption.

La documentation décrit cette évolution :

CCOL / Options via Liens

Dans les deux méthodes pour gérer les options, il y a le lien d’option. Toutes les options, à l’exception de celles dites en lecture seule, peuvent être définies par les liens d’options correspondants.
Toutes les options définis par des liens sont attachées à des entités. C’est à dire que le lien d’une option doit contenir l’entité à laquelle s’applique le lien. L’utilisation ou non de l’option se fait par l’entité si le lien lui appartient ou si elle est subordonnée à l’entité signataire du lien (voir CCOS). Les liens de l’entité de subordination sont prioritaires sur les liens propres.
Toutes les options inscrites dans le fichier des options sont dites forcées et ne peuvent être surchargées par un lien d’option.
La valeur de l’option doit être présente ou écrite dans l’objet correspondant. Si la valeur de l’option ne peut être lu, elle ne sera pas prise en compte. Le nom de l’option n’a pas besoin d’être écrit dans l’objet correspondant, il est déjà défini dans le code.
Les options définis par les liens ne sont pas prises en compte par la bibliothèque nebule en PHP procédurale du bootstrap.
L’option se définit en créant un lien :

  •     Signature du lien
  •     Identifiant du signataire
  •     Horodatage
  •     action : l
  •     source : ID entité visée
  •     cible : hash(valeur de l’option)
  •     méta : hash(‘nebule/option/’ + nom de l’option)

Liste des options non modifiables via des liens :

  •     Option ‘puppetmaster’
  •     Option ‘permitWrite’
  •     Option ‘permitDeleteObjectOnUnknowHash’
  •     Option ‘permitCheckSignOnVerify’
  •     Option ‘permitCheckObjectHash’
  •     Option ‘permitListInvalidLinks’
  •     Option ‘permitInstanceEntityAsAuthority’
  •     Option ‘permitDefaultEntityAsAuthority’
  •     Option ‘permitRecoveryEntities’
  •     Option ‘permitRecoveryRemoveEntity’
  •     Option ‘permitInstanceEntityAsRecovery’
  •     Option ‘permitDefaultEntityAsRecovery’
  •     Option ‘permitJavaScript’
  •     Option ‘modeRescue’
  •     Option ‘displayUnsecureURL’
  •     Option ‘subordinationEntity’

CCOS / Subordination

Une entité peut définir ses propres options mais peut aussi se voir défini ses options par une autre entité. C’est principalement utilisé afin de piloter des instances sur des serveurs distants.
La mise en place de ce mécanisme permet de maintenir autant que possible le contrôle sur un serveur que l’on ne maîtrise pas physiquement. Elle est mise en place via l’option subordinationEntity en lecture seule écrite dans le fichier des options. Cela veut dire aussi qu’une entité peut être compromise et pilotée à distance si le fichier des options est modifié par une entité tièrce.
La subordination peut être faite vers une seule entité, défini par son identifiant, ou pour un groupe d’entités. La gestion du groupe n’est pas encore fonctionnel, seule une entité peut être défini.
La subordination n’est pas prise en compte par la bibliothèque nebule en PHP procédurale du bootstrap.

Liens dissimulés et champs utilisés

Lorsque un lien est dissimulé, le cœur du lien à dissimuler est chiffré et placé comme un champs du lien de dissimulation.

Certains liens, en fonction surtout de leur type, peuvent avoir des champs cible et méta à zéro. Ces champs présents mais de valeur nulle ont une taille réduite et calculable. Cela veut dire que la taille du champs du lien dissimulation peut donner une bonne indication non des champs dissimulés mais du champs action du lien à dissimuler, c’est à dire du type de lien.

Cette détermination du type de lien en elle même n’est pas vraiment problématique mais peut être couplée à d’autres informations pour essayer de lever la dissimulation des champs, par exemple un changement de comportement d’une entité signataire ou destinataire du lien de dissimulation. Cependant comme le lien de dissimulation ne doit pas avoir de champs date signifiant, tel que définit dans l’article Schéma lien dissimulé – timestamp, la relation temporelle est difficile à mettre en évidence.

Un problème similaire va se poser avec les liens à dissimuler contenants des identifiants de tailles non conventionnelles, c’est à dire les objets virtuels. La taille résultant ne permet pas retrouver les champs du lien mais donne un indication sur le type d’un des champs.

A cause de la variation de taille non prévisible des champs des liens à dissimuler, il n’est pas possible d’ajouter un bourrage (padding) préventif fixe. Ce bourrage aurait pu simplement des zéros ajoutés au besoin au champs méta sans changer sa signification, ou des caractères espace.

Il est cependant possible d’ajouter un bourrage aléatoire de caractères espace de au moins trois fois la taille du champs source du lien à dissimuler, et de tout au plus cinq fois. Cette fonctionnalité est facile à ajouter lors de la dissimulation d’un lien et ne change ni sa vérification ni son traitement. C’est juste un peu d’espace consommé en plus pour les liens.

Identification de cosignataires

Suite de l’article Cosignature – méthode de surcharge des signatures.

Si la surcharge de signature dans le champs signature ne pose pas de problème, la désignation des entités signataires successives et leur ordre est plus complexe.

La première méthode proposée consistait à placer pour commencer l’ID de la pseudo entité co-signataire puis à concatèner successivement et dans l’ordre de signature les ID des entités signataires.

Mais si cela paraît suffisant pour retrouver les identifiants des différents signataires, la méthode n’est pas propre parce que l’on a un tas par défaut non structuré des entités signataires, informe. Et il peut être difficile de savoir que le lien est sur-signé en l’absence de signe clair.

Il est plus judicieux d’introduire un séparateur dans le champs signataire. La présence du séparateur implique automatiquement que le lien est sur-signé. Mais cela impose de revoir le code de validation et de traitement des liens.

Il est aussi possible de considérer les consignataires comme un groupe. Cependant la pseudo entité co-signataire ne peut pas être utilisée comme groupe parce que toutes les entités la constituant n’ont pas forcément signé le lien et ensuite parce que l’ordre de sur-signature n’est pas forcément cohérent avec l’ordre des entités, et le respect de l’ordre de vérification des signatures est indispensable. On peut imaginer aussi créer un groupe enfant du groupe de fait constitué par la pseudo entité co-signataire mais cela veut dire en pleine vérification des liens de synchroniser et lire un objet, donc conceptuellement de remonter d’un niveau. Donc ce n’est pas applicable.

Lien à quatre champs objets ?

Les réflexions initiales avaient montré qu’il était impossible de créer des liens entre objets de seulement deux champs, c’est à dire juste objet source et objet destination. Enfin, c’est possible mais ça n’est pas utilisable puisqu’il faut pouvoir indiquer dans le lien la relation faite entre les deux objets.

Le champs méta décrit la relation entre les deux objets source et destination. Ce champs méta est vu comme une information à propos de l’information principale, donc une méta donnée. Mais avec le temps il apparaît plus comme ayant le rôle d’objet opérateur, c’est à dire un descripteur de l’opération entre les objets source et destination.

La réflexion autour de la crypto-monnaie et de la messagerie pousse à considérer qu’un champs supplémentaire pourrait être utile comme contexte, c’est à dire de contextualisation du lien par rapport à un usage.

Un des usages serait par exemple la définition d’une option des applications. Ce lien contient en champs source le nom de l’option, en champs cible la valeur attribuée à l’option et en champs méta le fait que ce soit une option. Ajouter un champs permettrait de définir une option pour une autre entité.

Cependant le besoin d’un nouveau champs peut être aussi le signe d’une mauvaise structure de liens. Par exemple le champs méta du lien de définition d’une option est redondant avec son champs cible qui désigne une option particulière, sous-ensemble des options.

Et rajouter un quatrième champs aux lien va nécessiter la revu de tout le code actuel pour tenir compte de ce champs.

Il avait été pesé au début la possibilité, à l’extrême, de ne pas avoir de limite (ou en avoir une mais large) du nombre de champs. Cette façon de travailler aurait ralenti le code et il en aurait surtout résulté une perte de performance à cause d’une non optimisation des liens.

Quoiqu’il en soit, plus le temps passe plus la modification de la structure des liens deviendra délicate. Mais le gain aujourd’hui n’est pas jugé suffisant par rapport au travail à fournir pour évoluer vers des liens à quatre champs.

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.

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.

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 ?

Anonymisation des fichiers transcodés

Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle, transcodage et Transcodage des liens dissimulés, il apparaît un problème avec le contenu des fichiers transcodés.

Le fait qu’une entité synchronise des liens dissimulés que d’autres entités partagent et les range dans des fichiers transcodés peut révéler l’ID de l’objet transcodé. Et par tâtonnement on peut retourner ainsi le transcodage de tous les objets.

Il suffit qu’une entité attaquante génère un lien dissimulé à destination d’une entité attaquée concernant un objet en particulier. L’entité attaquée va alors ranger le lien dissimulé dans le fichier transcodé. L’entité attaquante peut alors rechercher quel fichier transcodé contient sont lien dissimulé et en déduire que ce fichier transcodé correspond à l’objet.

En plus, si le lien dissimulé n’a aucune action valable, il ne sera pas exploité, donc pas détecté par l’entité attaquée.

Il faut trouver une parade. Peut-être que l’on peut chiffrer les fichiers transcodé avec la clé de transcodage. A voir…

L’algorithme de transcodage doit être non réversible.

Transcodage des liens dissimulés

Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle et transcodage, voici le nommage des liens transcodés :

/l/HashEntitéDestinataire_HashObjetTranscodé

Cela répond aussi au problème du nettoyage puisque la forme du nom n’entre pas en conflit avec les ID des objets, il est discernable des fichiers de ségrégation des liens dissimulés et il est clairement rattaché à une entité.

La clé de transcodage ainsi que l’algorithme seront abordés plus tard.

Anonymisation/dissimulation des liens – transcodage

Suite à l’article Anonymisation/dissimulation des liens – ségrégation et temporalité et ségrégation partielle, la réflexion et l’implémentation sur le stockage et l’échange des liens dissimulés progresse.

La méthode de ségrégation des liens dissimulés développée est suffisante pour retrouver les liens dissimulés et les partager. Mais si le partage est efficace parce que l’on ne récupère que les liens dissimulés des entités connues, la lecture des liens n’est clairement pas efficace.

Lors de la consultation des liens d’une objet particulier, il faut lire tous les liens de l’objet, facile, et lire l’intégralité des liens dissimulés parce que l’on ne sait pas à l’avance quelle entité à dissimulé des liens pour cet objet. Il manque de pouvoir localement (indépendamment du partage) stocker les liens en fonction des objets source, cible et méta. Mais il faut aussi ne pas dévoiler cette association d’objets cités dans la partie dissimulée du lien, ce qui permet rapidement de lever la partie dissimulée.
Il est possible de transcoder les identifiants des objets cités par le lien dissimulé. On parle bien de travailler toujours sur des fichiers de stockage dédiés aux liens dissimulés, et donc indépendamment des liens non dissimulés. Ce transcodage doit permettre de ne pas révéler l’association entre les objets cités par le lien dissimulé. Ce transcodage peut être commun à tous les objets avec une clé de codage commune, ou chaque objet peut disposer de sa propre clé de codage. Et bien sûr, chaque entité dispose de sa/ses clés de transcodage, donc chiffrées avec la clé privée.
Un transcodage avec une clé unique est plus facile puisque l’on peut chiffrer cette clé et la stocker à un endroit unique, mais il est moins sûr que le transcodage à clés individuelles.
Pour commencer on va partir sur la base de la clé unique de transcodage.

Les liens dissimulés dans des fichiers transcodés sont lisibles publiquement et peuvent potentiellement être synchronisés mais ils n’ont pas vocation à remplacer les liens dissimulés dans les fichiers dédiés à la ségrégation et utilisés lors du partage des liens.

Le nettoyage des fichiers des liens dissimulés et transcodés devient un nouveau problème.
Plusieurs entités pouvant localement générer des liens dissimulés, et donc utiliser des clés de transcodage différentes, il n’y a pas de méthode de nettoyage générique des liens dissimulés dans les fichiers transcodés. Seule une entité peut faire le nettoyage de ses propres fichiers transcodés. Il faut donc que ces fichiers transcodés soient clairement associés à une entité.

Il est possible par contre de supprimer tous les fichiers transcodés d’une entité (ou plus). Il faut dans ce cas que l’entité, une fois déverrouillée, reconstitue ses fichiers transcodés.
Cela lève un nouveau problème, comment savoir que tous les fichiers transcodés sont présents et qu’ils sont à jour. Avec cette méthode, il ne faut pas que les fichiers dédiés à la ségrégation des liens dissimulés pour une entité soient manipulés par une autre entité parce que les fichiers transcodés ne seront pas synchrones. Et les transferts ne sont pas possibles.

Les entités ne doivent pas synchroniser les liens dissimulés des autres entités !

Il reste encore des réflexions à mener autour de cette méthode de transcodage.