Auteur/autrice : webmaster

Autorité temporaire : le maître des poupées

Une entité avait été généré en novembre 2012. Elle avait pour rôle de simuler une autorité de haut niveau. Voir l’article Autorité temporaire.

Le bi-clé de cette entité n’ayant pas été généré et manipulé dans des conditions spartiates de sécurité, il était difficile d’avoir pleinement confiance en cette entité.
Il fallait donc régénérer une nouvelle entité de façon plus propre.

Une machine a été installée de façon renforcée, et est prévue pour être manipulée hors réseau.
Tous les systèmes ont leurs faiblesses, et ont donc un besoin récurrent de mise à jour. Le système le moins vulnérable face à l’absence prolongée de mises à jours, c’est OpenBSD. C’est aussi actuellement le système le moins vulnérable par défaut. La non utilisation du réseau réduit très fortement les problèmes potentiels. Il est cependant possible, en cas de nécessité, de réaliser une mise à jour manuelle.
Le disque dur est partiellement chiffré.

Cette machine a donc permit de générer une nouvelle entité racine.
Ce rôle est toujours temporaire. Il ne se justifie que pour coller à un modèle de sécurité actuel, basé sur des autorités racines de confiance. On ne peut faire confiance à une entité que si elle est validée par l’entité racine. Cependant, ce modèle de sécurité n’a pas vocation à subsister en l’état. Soit il y aura d’autres autorités racines, soit elles disparaîtront toutes.

Puppetmaster, le nouveau maître des poupées est identifié comme :

88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

Et il reprend l’emplacement de l’ancien puppetmaster :

http://puppetmaster.nebule.org/

Pour l’instant, puppetmaster ne reconnaît aucune autre entité. Ce sera fait bientôt. Et le nouveau puppetmaster réformera (lien u) aussi officiellement l’ancien puppetmaster.
Le maître des poupées est mort, vive le maître des poupées!

OpenBSD echo off

Sous OpenBSD, c’est ksh par défaut et non bash.

Or la fonction read de ksh n’a pas d’option pour demander une saisie au clavier sans afficher ce que l’on tape, le retour clavier. C’est gênant pour la saisie d’un mot de passe par exemple. De son côté, la fonction read de bash l’accepte sous cette forme :

read -s -p "password" variable

Sous ksh, nous pouvons cependant préalablement désactiver le retour clavier, demander le mot de passe, et enfin réactiver le retour clavier. Comme ceci :

stty -echo
read variable
stty echo

Ca évite d’installer bash pour si peu…

Clé USB bootable chiffrée sous OpenBSD

Comment installer OpenBSD 5.2 sur une clé USB? Le rendre bootable? Et chiffrer le disque?

Je me suis basé sur ces deux tutoriels :

Il faut commencer par télécharger un CDROM d’installation (ici). Booter une machine sur le CD.

 La particularité, c’est d’utiliser sd0 comme disque d’amorçage et de chiffrer une partie de celui-ci. La partie chiffrée apparaît comme un second disque sd1 qu’il faut aussi partitionner. Comme sous Linux, une petite partie du système doit être présente non chiffrée pour pouvoir démarrer et demander le mot de passe qui ouvrira le disque chiffré. Cette partie non chiffrée, c’est la racine.

Il faut évidement derrière une machine capable de démarrer sur une clé USB.

La fin termine un peu abruptement. Continuer la lecture de Clé USB bootable chiffrée sous OpenBSD

Grandes migrations

Toutes les entités étaient accessibles via des liens en nebule.org .

Depuis une semaine, certaines entités ont changé de domaine. Les nouvelles localisations des entités concernées :

Les entités à usage publique restent dans le domaine nebule.org, c’est le cas de :

Ces localisations sont des domaines DNS, et de fait des serveurs http derrière. Cependant, la localisation est certes obligatoire pour retrouver une entité, mais elle n’est pas par nature strictement liée aux noms de domaines. Ni liée au réseau d’ailleurs. Certaines machines ne répondent pas à leur localisation (alpha.nebule.fr), et le type de localisation évoluera plus tard vers d’autres formes (ftp, smtp, xmpp, etc…).

Power and the Internet

Voici un essai intéressant publié par Mr Schneier sur son blog. Il y est question de l’évolution de l’Internet ainsi que des bouleversements qu’il introduit dans les rapports de forces entre les états (et pas que) et les administrés, c’est à dire le peuple. Toute évolution technologique introduit ce genre de bouleversement et c’est l’occasion de rendre le monde plus humain. Mais saurons-nous en profiter cette fois-ci ?

Je m’arrêterais sur la dernière remarque :
Either we fight for a seat at the table, or the future of the Internet becomes something that is done to us.
(Soit nous nous battons pour une place à la table, ou l’avenir de l’Internet deviendra quelque chose qui est fait pour nous à notre place.)

Liens :
– http://www.schneier.com/blog/archives/2013/01/power_and_the_i.html
– http://www.schneier.com

Ajout du 23/03/2013 :
– http://www.internetactu.net/2013/03/21/pouvoir-et-internet/
– http://www.framablog.org/index.php/post/2013/03/18/internet-etat-policier-surveillance
– http://www.technologyreview.com/view/512386/danger-lurks-in-growing-new-internet-nationalism/

Introduction à la cryptographie

Une avancée importante reste encore à faire. Elle est en théorie tout à fait réalisable et indispensable. Mais la mise en pratique doit se faire avec soin. Cette avancée, c’est le chiffrement des objets.

Ce chiffrement est optionnel. Il doit être résistant, c’est à dire correspondre à l’état de l’art en cryptographie appliquée. On doit être en mesure de parfaitement distinguer l’objet en clair de l’objet chiffré, même si le second est dérivé du premier.

Ceci est une proposition de travail.

Deux étapes de chiffrement

Les entités sont des objets contenant le matériel cryptographique nécessaire au chiffrement asymétrique. Cependant, le chiffrement asymétrique est très consommateur en ressources CPU (calcul). On peut l’utiliser directement pour chiffrer les objets avec la clé publique d’un correspondant, mais cela devient rapidement catastrophique en terme de performances et donc en expérience utilisateur. D’un autre côté, le chiffrement symétrique est beaucoup plus performant, mais sa gestion des clés de chiffrement est délicate. Pour améliorer l’ensemble, on mixe les deux. On essaie de profiter des avantages de chacun tout en réduisant les défauts.

Ainsi, on va aborder le chiffrement en deux étapes distinctes. Voici le schéma de l’ensemble que l’on va décomposer.

Pour la compréhension, ne pas oublier que les propriétés des objets sont elles-mêmes des objets…

Continuer la lecture de Introduction à la cryptographie

Cerberus et la mise en quarantaine d’objets

Une nouvelle entité est mise en ligne.

Cette entité à pour mission de lister les objets à bannir. Ce peut être par exemple du code malveillant.
Il faut bien sûr faire confiance à cette nouvelle entité… et supprimer automatiquement les objets référencés via cet objet particulier :

126520cc2d5453c68d070e80a38bea3c501cb2ef6284ec1edddc34b717739b8d
‘cerberus/danger‘.

L’entité est en ligne ici : http://cerberus.nebule.org/

Les scripts actuels de nebule ne le gère pas encore, mais ça viendra…

Problèmes en cours

Deux problèmes apparaissent avec le chronographe :

1/ La gestion du suivi des événements dans le temps via l’objet "nebule/objet/entite/suivi" et dérivés n’est as optimale. La période de temps exponentielle donne satisfaction même si elle pourrait être remplacée par une fonction beaucoup plus linéaire que le calque sur le découpage humain du temps (seconde, minute, heure, jour, mois, année). Le problème vient surtout que les caractéristiques des objets "nebule/objet/entite/suivi" et dérivés sont elles-même déplacées d’un objet à l’autre et ne sont plus directement disponibles pour l’objet d’origine.

2/ Je songe à remplacer l’objet "mime-type" par "nebule/objet/type", et l’objet "hash function" par "nebule/objet/hash". Cela implique de corriger une grande partie des scripts déjà en places. A voir…

Le lien et la subdivision d’objet

Un lien particulier avec pour action ‘s‘ permet de faire de la subdivision d’objet. A quoi cela sert-il ?

Il y a deux usages possibles de cette action.

Le premier usage est de permettre de scinder un objet volumineux en une multitude de morceaux, une multitude d’objet plus petits. Ces objets dérivés peuvent avoir des tailles identiques ou non. Ils doivent impérativement être non recouvrants et parcourir l’intégralité de l’objet parent.
En scindant un objet volumineux, il peut être transféré par morceaux vers différents emplacement (d’autres entités). Et donc une autre entité peut simultanément télécharger les multiples morceaux à des emplacements différents. Une fois tous les morceaux rassemblés, l’objet parent, l’original, peut être reconstitué.
C’est une des techniques nécessaires au fonctionnement du P2P par exemple.

Le deuxième usage, c’est de ne faire qu’un seul objet dérivé d’un objet parent plus grand. Cet objet dérivé fonctionne alors comme un extrait de l’objet parent. On ne peut pas reconstituer l’intégralité de l’objet parent à partir de l’objet dérivé.
Bien sûr, plusieurs extraits d’un objet peuvent être faits. Et un extrait plus petit encore peut être retiré d’un autre extrait. Rien ne limite le nombre d’objets dérivés. Rien ne garanti leur non-recouvrement ni qu’ils parcourent l’intégralité de l’objet parent.
L’usage peut par exemple être l’extrait d’une citation dans un livre, un extrait d’une musique, etc…

Actuellement, une subdivision est référencée par un objet contenant une et une seule ligne de type x-y. Mais peut-être serait-il intéressant de permettre plusieurs lignes de type x-y, cela créant un extrait contenant directement la concaténation des différents extraits d’un objet. Quel usage ?

Chronographe : 20 jours après

Le chronographe expérimental est lancé depuis maintenant 20 jours et quelques heures (CF Chronographe).
Il tourne toujours.

L’accès via le web est impossible. La page de bootstrap avait déjà été modifiée pour supporter un grand nombre de liens. La visualisation de l’entité est impossible via la page gnav.php . Il faut modifier le robot pour qu’il ne lie pas les traces de temps avec sa propre entité mais avec l’objet contenant "nebule/objet/entite/suivi".

En regardant de plus près, il faut une vingtaine de secondes pour lister tous les fichiers contenants des liens. Il y en a plus de 29000…
C’est encore exploitable, mais peut-être faudrait-il dans ce cas répartir les objets dans des sous-répertoires et alléger le système de fichiers qui n’est pas vraiment prévu pour ça. Le robot ne semble pas ralentir dans son fonctionnement malgré tout, c’est que les fichiers restent accessibles dans un temps raisonnable.

Le robot est recréé ce soir avec quelques correctifs.
kronos.nebule.org

Yubikey et la double authentification

Une des bêtes noires de la sécurité des utilisateurs et de leurs informations sur l’Internet est le mot de passe. Ou plutôt devait-on dire la multitude de mots de passes et de comptes utilisateurs qui vont avec.

Chaque service web nécessite un compte utilisateur pour être utilisé, normal. Ce qui est moins normal, c’est que cette identification reste assez strictement localisée au service en question. A part quelques tentatives qui n’ont remportée qu’un succès d’estime, chaque service gère jalousement ses utilisateurs. Il en résulte un multitude de comptes utilisateurs différents avec potentiellement autant de mots de passes.
La gestion de l’identité sur l’Internet est un vrai problème. La gestion des mots de passes associés encore plus. Même si l’on met le même mots de passe partout, il faut régulièrement le retaper. Et bien sûr, avec un mot de passe unique, on devient vulnérable au premier service qui ne sécuriserait pas correctement ceux-ci.

Yubico propose une solution basé sur le mot de passe à usage unique (OTP – One Time Password). L’ensemble fonctionne sur le principe de ‘ce que je connais‘ et ‘ce que j’ai‘. La double authentification repose donc sur deux moyens combinés de prouver son identité. On doit fournir les deux ou prouver que l’on détient les deux.

  1. ‘Ce que je connais‘, c’est typiquement un nom d’utilisateur et un mot de passe.
  2. ‘Ce que j’ai‘, c’est un objet dont je dispose. Cet objet doit être capable de prouver sa présence de façon numérique. C’est ici la YubiKey.
  3. ‘Ce que je suis‘, c’est le plus dur à obtenir… puisque c’est généralement ce que l’on cherche.

La clé YubiKey branchée en USB émule un clavier et envoie un mot de passe OTP lorsque l’on appuie sur un bouton de la clé. Ce mot de passe unique est dérivé de l’identifiant de la clé, d’un numéro de séquence, d’une empreinte CRC et de divers autres champs. Le tout est converti en caractères imprimables et envoyé comme si il était tapé sur un clavier.
Ce OTP est transmis au serveur en même temps que le nom d’utilisateur et éventuellement un autre mot de passe (double authentification). Le serveur le transmet au YubiCloud pour vérification et attend une réponse positive ou négative sur la validité de l’OTP pour donner l’accès au service à l’utilisateur… ou pas.
L’OTP change à chaque fois et ne peut être rejoué. Il peut donc être divulgué une fois utilisé.
La YubiKey peut être volée, sans le compte à utiliser (ou le deuxième mot de passe) elle est inutilisable.
Si double authentification, le mot de passe peut être volé (keylogger), il n’est pas utilisable sans la YubiKey à côté.

Une des propriétés intéressante de cet implémentation, c’est que l’on peut voir l’ensemble comme la transmission de messages chiffrés (symétrique) entre la YubiKey et la YubiHSM. Toutes les clés connaissent l’unique (ou pas loin) mot de passe secret de chiffrement. On fait confiance au matériel (les clés USB) pour savoir garder le secret.

Le système est de loin préférable à la simple authentification par mot de passe. Mais il n’en présente pas moins des problèmes :

  1. Une petite polémique est apparue sur la robustesse réelle du système. Un CRC16 permet de vérifier la validé du paquet. Ce CRC est inclus dans les données chiffrées et couvre donc 128-16=112bits. En jouant des paquets au hasard, il y a 1/(2*2^16) chances que la signature du CRC16 soit cohérente avec le reste. Si l’on compte qu’il faut statistiquement parcourir la moitié des valeurs pour en trouver une bonne, cela donne une probabilité de 1/(2^16). Cependant, dans les données chiffrées, il y a aussi le champ private identity de 6 bytes=48bits. Ce champs étant vérifié comme nul ou valide par les serveurs, la probabilité remonte à 2*1/(2^(16+48)) soit 1/(2^63). Ce qui sauve les meubles c’est que l’attaque doit passer par le réseau, la solidité réelle de l’ensemble est de 2^63 et non de 2^128…
  2. Il faut la coopération active des services qui authentifient les utilisateurs. La méthode d’authentification doit être modifiée pour supporter la vérification de l’OTP en liaison avec le YubiCloud, l’infrastructure qui valide réellement l’authentification. Pour les personnes qui gèrent elles-même leurs blogs ou autres services, c’est un réel gain. Mais pour un gros acteur de l’Internet c’est plutôt une ingérence sur un sujet sensible que sont les utilisateurs et tout ce qu’ils rapportent. Cela à donc autant de chance d’être adopté que d’autres solutions par le passé comme OpenID, faible.
  3. La solution nécessite une connectivité vers l’Internet et le YubiCloud pour valider l’authentification. Impossible donc de travailler hors-ligne. Il y a 5 serveurs dans le monde, c’est déjà pas mal mais c’est aussi encore trop peu pour résister à un DDOS ciblé. Et en cas d’absence de connexion prolongée aux serveur, tous les services associés sont eux-aussi paralysés. On a un point de défaut unique.
  4. Comment va se comporter l’ensemble lorsque le compteur anti-rejeu va boucler ? La clé ne marchera plus. La taille du compteur est de 15bits=32768 utilisations (avec branchement de la clé).
  5. Volontairement, la YubiKey ne peut être mise à jour. La clé est accessible en lecture seule, ce qui empêche la diffusion de virus et réduit la surface d’attaque de celle-ci. Mais que se passera-t-il quand, inévitablement, une faille sera trouvée sur cette clé ? Poubelle.

D’autres questions restent en suspend. L’analyse rapide de la documentation sur le site web de Yubico ne permet pas d’y répondre.

  1. Clé unique de chiffrement AES entre toutes les clés YubiHSM ? Ou une clé AES par YubiHSM ? Ce système de clés secrètes interdit notamment toute concurrence avec les mêmes clés. Utiliser la cryptographie asymétrique plutôt que symétrique aurait permit bien plus de choses et relevé la sécurité à plus long terme.
  2. Et si un serveur d’authentification du YubiCloud répond toujours OK même si les OTP sont invalides ? Quelle est la robustesse de l’infrastructure du YubiCloud ? La liaison entre les API côté clients et les serveurs API Validation Servers est chiffrée avec une clé partagée. Les serveurs KSM avec leurs YubiHSM sont indépendants des API Validation Servers. Mais si la clé AES semble bien protégée dans les YubiHSM, je n’ai pas vu de mécanisme de signature de la réponse.
  3. Yubico ne semble pas aimer la cryptographie symétrique, elle n’est employée nulle part. Dans un contexte entièrement centralisé autour de quelques serveurs, la cryptographie symétrique appliquée à tous les échanges reste cependant acceptable. Mais on en revient à une critique précédente, cela renforce l’unicité du point de défaillance de ces serveurs.

Qu’en penser ?
Toute la sécurité repose sur la/les clés AES des YubiHSM, la robustesse de la clé YubiKey et sur l’implémentation du chiffrement de l’OTP. La solution semble viable à court terme. Trop de défauts la condamne malheureusement à long terme.
Bref, c’est mieux que de se reposer uniquement sur le user/password, mais il faudra l’abandonner sans regrets au premier signe de faiblesse.

Liens :
– http://www.yubico.com/
– http://www.wired.com/wiredenterprise/2013/01/google-password/all/
– http://www.yubico.com/products/yubikey-hardware/
- http://static.yubico.com/var/uploads/pdfs/YubiKey_manual-2.0.pdf
– http://www.yubico.com/wp-content/uploads/2012/10/YubiCloud-OTP-Validation-Service-v1.1.pdf
– http://www.schneier.com/blog/archives/2013/01/googles_authent.html
– http://gonzague.me/yubico-yubikey#axzz2IzWaf5Dr
– https://bitcointalk.org/index.php?topic=85648.msg943612#msg943612
– http://openid.net/

Protocoles (a)symétriques

Un article sur le sentiment de stagnation de l’innovation (InternetActu.net) amène un commentaire (le premier) sur la symétrie de l’Internet et de ses protocoles.

Le commentaire relève l’asymétrie des acteurs, soit les fournisseurs de services et les clients/consommateurs. Il en découle logiquement des conflits d’intérêts. Le premier se trouve entre le client piégé et le fournisseur de service résolument fermé aux autres fournisseurs de services. Le deuxième conflit est révélé par l’actualité entre Free et Google, entre le transporteur de paquets et le nÅ“ud de services.
Cette asymétrie se retrouve dans les protocoles utilisés sur le réseau des réseaux.

La solution proposée serait de déployer des protocoles symétriques. Ceux-ci existent depuis des décennies mais sont peu employés. Ils permettraient de relier directement les gens entre eux sans les intermédiaires bien encombrants que sont les nÅ“uds de services. Et accessoirement, cela assurerait la neutralité du réseau et relancerait l’innovation pris en otage par les grosses sociétés.

Mon avis, c’est que le problème est bien réel mais cette solution me semble un peu superficielle. La façon de la mettre en avant fait un peu… commercial d’ailleurs, même si aucun produit n’est proposé derrière. Bref, comme souvent, c’est une mauvaise solution à un problème mal posé.
Oui le système des brevets est utile, mais complètement détourné de son but originel. A revoir si l’on veut relancer rapidement l’innovation par les petites sociétés. Il devait assurer la diffusion du savoir et des innovations contre des garanties. Il est aujourd’hui la base d’une guérilla juridique pour protéger coûte que coûte des positions commerciales au détriment… de l’innovation.
Oui l’Internet est asymétrique, et on n’y changera pas grand chose tant que la connexion de l’utilisateur restera… asymétrique. J’ai vu que ce problème a été abordé quelque part dans un commentaire comme étant une cause de problème. L’ADSL qui connecte une grande partie des utilisateurs est volontairement asymétrique, mais cela correspond à une optimisation liée aux usages des internautes depuis 15 ans. Ce n’est pas une cause de dissymétrie mais une conséquence. Et donc aucun changement n’est à attendre de ce côté là tant que les usages de l’Internet ne changeront pas.
Non les protocoles asymétriques ne résoudront pas le problème d’asymétrie de l’Internet. Que le protocole soit symétrique ou pas n’a pas d’importance. Bien qu’utilisant des protocoles symétriques, nous savons déjà aujourd’hui parfaitement faire dialoguer deux utilisateurs directement entre eux, le fameux Pair à Pair (P2P). Ce qui à de l’importance c’est l’usage, encore et toujours. Tant que l’on ne proposera pas à Facebook et consorts des alternatives utilisant les propriétés du P2P et potentiellement complètement acentrés, ça ne changera pas.

La translation d’adresse IP (NAT) sera, si elle ne l’est déjà, un plus grand frein à la symétrie des usages de l’Internet. Tant que plusieurs utilisateurs seront cachés derrière une seule adresse IP, ils sera difficile de leur donner un rôle autre que celui de consommateur. Le NAT sert aussi à faire de la sécurité pour les postes cachés, ou plutôt devrait-on dire que ça y contribue un peu (pas plus). Rien que pour ça, IPv6 (sans NAT) devrait être une des plus grosses priorités.

Retour au projet nebule. Celui-ci permet de répondre à l’asymétrie des usages non pas en faisant tomber les nÅ“uds de services ou en rendant le réseau complètement symétrique, mais en redonnant au réseau sa vraie place de transporteur. La symétrie est assurée (ou pas) par les liens entres objets, indépendamment du moyen de transport.

Liens :
– http://www.internetactu.net/2013/01/09/vers-une-stagnation-de-linnovation/
– http://www.internetactu.net/

Chronographe

Une nouvelle entité vient d’être mise en ligne : kronos

C’est un chronographe, il mesure le temps.
Et il le signe !

Toutes les minutes, l’objet 09531c684ca8804f671250db6d20403745f3e9c156eb1fad80945b9a4030105a est mis à jour avec en dernier la trace du temps.
Cet objet s’appelle ‘nebule/objet/entite/suivi/m00‘, la minute 0 du temps passé.
Le temps a dans nebule un écoulement linéaire et exponentiel. Il est linéaire pour des périodes de temps du même ordre de grandeur. Il est exponentiel lorsque l’on change d’ordre de grandeur.

Il y a encore quelques erreurs résiduelles dans les objets générés parce que le moteur de nebule et en cours de ré-écriture complète… et que c’est actuellement un peu buggé…
Mais l’idée est là et surtout : ça marche :-)

A quoi cela sert-il ? РR̩dig̩ !

Un premier texte explicatif sur l’utilité de nebule est rédigé dans une page.

Cette page est disponible sur le blog en haut à gauche.

C’est une résolution de cette nouvelle année, rendre le projet plus lisible.
L’étape d’après sera de le rendre plus visible…
Bonne année 2013 :-)


811ba947111090b4708da62494a84e5cfc13ea60e16dac94a678f395aa42da07

nebule et la donnée massive

Juste un petit article en écho à celui sur le RDF. C’est surtout le moyen d’introduire sur le blog les catégories :

Ceux-ci sont inclus dans la catégorie des réflexions.

Ainsi le blog de nebule peut commencer à être référencé sur ces mots clés, notamment.

Silent Circle et la crypto pour tous

La revue lemonde.fr sort un article ce jour sur la startup américaine Silent Circle.

Le système repose sur du chiffrement et de l’offuscation de communications. Jusque là, rien de nouveau sous le soleil. C’est une autre façon de ré-implémenter des composants existants. L’intérêt est plutôt dans la façon d’implémenter l’ensemble qui le rend facile d’utilisation. Continuer la lecture de Silent Circle et la crypto pour tous

Liaison secr̬te Рsuite

La réflexion sur la possibilité d’insérer des liens dans des objets (cf Liaison secrète) pose quand même un problème.

Comment vont être utilisés dans la vraie vie les liens insérés dans l’objet ?

Il faut en effet voir comment vont être pris en compte ces liens. Seront-ils ajoutés par certaines entités aux liens des objets concernés ? Ce qui du coup leur fait perdre leur caractère confidentiel, et donc l’intérêt du chiffrement de l’objet contenant ces liens. Et si ils ne sont pas ajoutés au reste des liens des objets concernés, comment vont faire ces entités pour exploiter ces liens ?

Deux réponses sont possibles.

La première est de déchiffrer l’objet pour extraire les liens et les stocker temporairement dans un emplacement strictement privé… et faire en sorte de les traiter en même temps que les liens naturellement attachés aux objets, c’est à dire aux liens publics. Cela nécessite à chaque déverrouillage d’une entité que celle-ci déchiffre tous ces objets pour en récupérer les liens, et de les supprimer systématiquement à chaque verrouillage. C’est facile et réalisable avec peu d’objets de ce type. Mais seront-ils si peu nombreux ? C’est loin d’être évident. Donc ce n’est pas une solution.

L’autre solution est de permettre d’insérer dans les liens un nouveau lien qui ferait référence à un autre objet comme contenant des liens. Cet objet peut ensuite être reconnu comme contenant des liens et être exploité en même temps que les liens normaux, c’est à dire non chiffrés. cette solution semble plus réaliste et viable que la première. Cependant, elle nécessite la mise en place d’un mécanisme pour les traiter spécifiquement.

Ne faut-il pas créer un nouveau type de lien dédié à ce problème ?
En l’état, le problème peut être résolu plus tard sans remettre en cause toute l’architecture des liens de nebule.