Mois : juillet 2014

Les entités et le code

La remise en forme du code de nebule en php orienté objet amène son lot de questions.

Les entités de nebule

Les entités principales de nebule ont actuellement des noms mais ne sont reliées à leurs fonctions respectives que par leur usage dans le code.

Pour que ce soit plus clair dans le code, le nom est un peu trop hermétique. Je le remplace donc par un nom contenant directement le rôle. Ainsi, kronos par exemple s’appellera toujours kronos mais sera mémorisé dans une variable nommée time master. Et il en est ainsi pour toutes les entités qui ont un rôle dans nebule :

  • puppetmaster, ne change pas de nom, c’est l’entité qui chapeaute toutes les autres, le maître ;
  • cerberus, hérite du rôle et du nom security master, le maître de la sécurité ;
  • bachue, hérite du rôle et du nom code master, le maître du code ;
  • asabiyya, hérite du rôle et du nom directory master, le maître de l’annuaire ;
  • kronos, hérite du rôle et du nom time master, le maître du temps.

Les possibilités de gestion pour l’utilisateur

La sécurisation du code amène aussi des questions sur l’organisation de la gestion de certaines parties de la sécurité. Notamment, jusqu’où peut-on permettre l’ajout de droits à une entité normale ?

Cette entité peut vouloir utiliser des extensions externes au code d’origine tel que diffusé par bachue. Cela peux se faire en relation avec la définition d’autorités locales. L’ajout d’une traduction de l’interface en est un bon exemple. L’entité bachue peut aussi diffuser ou permettre la diffusion de plusieurs codes utilisables par une entité.

Plus on donne de droits à un utilisateur, plus il risque de se faire corrompre par un code malveillant. Il faut trouver un juste milieu. Le code et la gestion du bootstrap doit rester la plus saine possible dans tous les cas.

Redéfinition de puppetmaster

L’entité puppetmaster est celle qui contrôle toutes les autres, donc qui contrôle tout. C’est le point fort de la hiérarchie des entités, et aujourd’hui la moins vulnérable. Mais c’est aussi l’entité qui présente le plus grand risque pour l’ensemble puisqu’elle est unique et que sa compromission serait fatale à tout l’ensemble.

C’est le même problème que le système de certificats présente aujourd’hui. Quoique, c’est pire encore pour le système de certificats puisqu’il existe beaucoup d’autorités de certifications racines et que la compromission d’un seule casse la confiance de tout le système. Dans l’ensemble, ce système de certificats est bien fait à part cette horreur de monstre à têtes multiples. Un vrai trou conceptuel dans la sécurité. Les gouvernements et le grand banditisme l’ont déjà corrompu depuis quelque temps à leur avantage.

Pour l’entité puppetmaster, l’idée est de partir en sens inverse. Au lieu de divulguer cette entité à de multiples personnes et organismes dont l’intégrité et l’honnêteté sont loin d’être garanties, on ne diffuse qu’une partie du pouvoir de l’entité puppetmaster. Une personne seule ne doit pas pouvoir utiliser l’entité. Chaque lien doit être validé, et donc signé, par un corpus de plusieurs clés représentant l’entité. Par exemple, on peut partir sur dix sous-clés de l’entité, associées deux à deux.

On peut implémenter la vérification du quotas de sous-clés ayant signées un même lien. Mais cette façon de faire est un droit faible puisqu’il ne repose que sur du code. On peut, j’espère, trouver une implémentation mathématique permettant de mettre en place une signature unique combinaison de plusieurs clés.

Il faut aussi résoudre un problème organisationnel et non technique. En combien de parties découpe-t-on l’entité ?
Dans notre exemple dix sous-clés associées deux à deux, on a un pouvoir de la clé maître répartie en cinq couples de clés. Chaque clé d’un couple a le pouvoir du couple. Le couple ici fait référence au couple humain. Et le cinq peut faire référence à tout un tas de choses…
Est-ce la meilleur répartition ? Celle-ci doit-elle répondre à une organisation physique ? Philosophique ? Spirituelle ? Mystique ? etc…

Partage simplifié d’une entité

Pour l’utilisateur d’un logiciel de communication, mémoriser un mot de passe complexe est une tâche ardue, voir sans intérêt.

Le problème est le même avec les pages web, leurs noms doivent être facile à retenir et à retaper sans faute. Et il en est ainsi pour les correspondants dont il faut se souvenir au pire de leurs adresses emails ou au mieux de leurs noms ou pseudonymes. Dans certains cas, il faut se souvenir du pseudonyme et du site web sur lequel on peut trouver un correspondant.
Le projet nebule vise notamment à fédérer des identités en même temps que les données. Mais cela entraîne inévitablement l’utilisation d’identifiants globalement uniques, donc longs.
Certains projets comme minilock visent à essayer de réduire ces identifiants avec des encodages comme le Base58.

On peut aussi utiliser uniquement une localisation, c’est à dire adresse de type http ou email. Ainsi, pour une adresse http, il faut héberger à une adresse précise une entité par défaut. Si un hébergeur veut gérer plusieurs entités, il ne pourra pas les garder facilement dans le même espace, le même nom de domaine, mais il devra au contraire les séparer dans des espaces différents. Mais est-ce vraiment la solution ?

Dans l’article sur le Détournement de liens de mise à jour (CF blog sylabe), on a vu qu’il était possible de créer une sorte de pseudonyme d’entité nebule. C’est un détournement du lien de mise à jour depuis un objet fictif vers, dans notre cas ici, une entité définie. Prenons comme exemple un prénom Fabio auquel correspondrait un objet fictif fab10. Ainsi, sur une instance de nebule, cet objet reverrait systématiquement vers l’entité de l’utilisateur. Ça résout le problème localement.

Cependant, on peut facilement imaginer que tous les utilisateurs qui ont se prénom vont avoir des prétentions sur cet objet fictif. Comment va se résoudre le conflit ?
Assez mal en fait. Si on a des amis en commun, on devrait rapidement retrouver le bon identifiant de l’entité. Mais ça se corse si on a deux entités avec des prétentions sur ce pseudo dans nos entité proches. Dans ce cas, c’est le calcul social qui va déterminer l’entité qui pourra hériter du pseudo, et cela fait une chance sur deux de ne pas tomber sur la bonne entité…
En plus, on peut imaginer aussi que dans une situation de harcèlement ou de dénigrement, des entités agressives essayent aussi de s’approprier le pseudo. Cela pourrait rendre le pseudonyme difficile à utiliser puisqu’il ne renverrait que rarement à la bonne entité.

Cette méthode est donc loin d’être parfaite. Elle peut être raisonnablement utilisée soit dans un petit groupe d’utilisateurs soit si elle est associée à une localisation http, email, etc…

Réservoir d’Internet

On peut faire des réserves de à peu près tout, le l’électricité, du gaz, de l’eau, de l’argent, de l’or, de la connaissance, etc… Mais on ne peut pas faire de réservoir de l’Internet.

L’Internet est une connexion au monde pour échanger de l’information. Mais l’information que nous échangeons est de plus en plus difficile à conserver ou simplement à consulter hors connexion.

Évidemment, les données que nous échangeons sont rafraîchies au fil de l’eau et donc la connexion est nécessaire. Certaines applications permettent de télécharger des données pour être consultées hors ligne. Mais ce n’est pas le cas des navigateurs par défaut, ou ce n’est plus le cas pour certains.

En travaillant sur l’échange d’objets, et donc de données, avec nebule on crée la possibilité de récupérer localement tout un tas d’objets liés entre eux, et donc tout un tas de données liées. Et ces données liées, c’est le début d’un réservoir de données.
Ça donne à réfléchir…

Cryptographie et clé de session

Dans nebule, à chaque fois que de la cryptographie intervient avec des entités d’un côté et du contenu de l’autre, on utilise de la cryptographie asymétrique et de la cryptographie symétrique.

La clé de session est l’un des éléments importants. Elle assure en quelque sorte le lien entre l’entité et le contenu. Le contenu peut être soit un objet soit un lien. La clé de session, c’est le mot de passe de la cryptographie symétrique pour chiffrer/déchiffrer le contenu. La clé de session est chiffrée/déchiffrée avec respectivement la clé publique ou la clé privée d’une entité.

La clé de session est le pivot du processus de chiffrement. Elle aurait pu être intégrée au contenu chiffré, ce qui nécessite une extraction pour le déchiffrement. Mais au titre de pivot, dans nebule elle est volontairement mis en avant et isolée plutôt que cachée comme une banale donnée technique.

Lors du processus de chiffrement d’un objet, la clé de session est un objet à part entière et lui aussi chiffré avec une clé privée d’entité.

20130209 nebule - schema crypto

Lors du processus d’offuscation d’un lien, son chiffrement en fait, la clé de session aurait pu aussi être fusionnée dans le registre avec le champ contenant le lien chiffré LienChiffré. Mais au contraire, elle occupe un champ à part entière CléSession.

Signature_Signataire_TimeStamp_c_EntitéCible_LienChiffré_CléSession

Cette sanctuarisation de la clé de session entraîne apparemment une plus grande complexité des processus de chiffrement. Cependant, cela apporte une grande simplification dans la gestion des objets chiffrés, mais rien pour la gestion des liens offusqués. Si un objet chiffré doit être partagé avec plusieurs entités, une clé de session différente entraînerait la nécessiter de rechiffrer l’objet source pour tous les destinataires, càd le chiffrement symétrique et asymétrique. Avec une clé de session autonome, il suffit juste de la rechiffrer pour tous les destinataires la clé de session, donc juste opération de chiffrement asymétrique. Pour un petit objet, le gain est négligeable, mais il ne l’est pas pour un gros objet (plusieurs fois la taille de la clé de session).
Je rappelle que le chiffrement asymétrique est beaucoup plus gourmand en ressources processeur et en mémoire que le chiffrement symétrique.

On peut aussi imaginer que la clé de session soit réutilisée pour le chiffrement de plusieurs objets ou de plusieurs liens. Si c’est pour une seule entité, cela permet de ne réaliser le chiffrement asymétrique qu’une seule fois. Cela crée une sorte de groupe d’objets ou de liens, ceux-ci regroupés par leur clé de session commune. Il est aujourd’hui possible d’envisager deux cas où plusieurs objets ou plusieurs liens pourraient utiliser la même clé de session :

  1. La diffusion d’objets très fortement liés entre eux et qui auraient tout intérêts à « voyager » ensembles. Idem pour des liens fortement couplés comme lors de la nébulisation d’un objet.
  2. L’utilisation de matériels peu performants pour lesquels il serait incontournable de n’avoir à calculer qu’un seul chiffrement asymétrique pour plusieurs objets et/ou plusieurs liens.

Il faut cependant garder à l’esprit que ces deux cas entraînent un risque sur la divulgation de ces objets et liens. Si un seul d’entre eux est retransmit pour autrui, c’est à dire que sa clé de session est repartagée, alors c’est tous les autres qui sont de fait divulgués. Ces exceptions doivent être évitées à tout prix ou toujours utilisées avec intelligence et extrêmes précautions.

Une clé de session doit toujours être robuste et utilisée pour un seul objet ou un seul lien.

Nommage multiple et protéiforme

Dans nebule, les objets ont forcément un identifiant. Ils ont aussi parfois un nom. Typiquement, c’est le cas lorsque l’objet a pour source un fichier nébulisé.

shot-2014-07-18_20-07-59

Le nom est un texte de caractères compréhensible par les humains. Déjà, en fonction des langues, il se peux que ce texte ne soit pas compréhensible pas tout le monde. Mais on exclut déjà par principe les caractères non imprimables, même si en réalité ça n’a pas beaucoup d’importance. Il vaut mieux que le texte n’ai pas de retour à la ligne, mais ça peut être interprété, traduit et pris en compte à l’affichage.

Pour un fichier, le nom (qui inclus le chemin) a deux rôles :

  1. le classement sommaire par sujets en fonction du chemin et parfois du nom ;
  2. la description sommaire du contenu, un peu comme un titre.

Dans nebule, le nom que l’on peut donner à un objet a le même rôle que le nom pour un fichier. Il donne un titre à l’objet. Par contre, le classement des objets intervient peu avec le nom que ceux-ci pourraient avoir. Ce serait plutôt le rôle de groupes et de nÅ“uds, concept encore en cours d’affinement. Pour un objet, lui donner un nom c’est le lier à un autre objet qui contient le nom avec un lien de type l.

Si un fichier ne peut avoir qu’un seul nom, un objet peut en avoir plus. Il est possible de créer plusieurs liens vers différents objets à utiliser comme noms. Les propriétés de liens multiples et concurrents sont valables aussi pour le nommage.
Lors de l’affichage, comme dans l’exemple ci-dessus, il faut faire un choix. Soit on affiche tous les noms, ce qui peut rapidement devenir problématique et difficilement compréhensible par l’utilisateur. Soit on affiche qu’un seul nom, celui affiché étant celui qui a le plus grand score dans le calcul des relations sociales. C’est cette dernière solution qui est adoptée aujourd’hui.

Mais on peut faire encore mieux. Rien n’interdit un lien pour un titre de renvoyer vers une image. D’ailleurs, ce peut être tout objet sans distinction. C’est l’interprétation du titre qui ici prend son importance. Si on n’interprète que du texte alphanumérique sur une seule ligne, les autres objets seront ignorés comme titre.
Si on décide de prendre en compte aussi les images, il ne sera peut-être pas opportun d’utiliser une image de grande résolution, lourde. On peut utiliser à la place les miniatures, des images dérivées, pour l’affichage comme titre. Les miniatures d’images seront d’ailleurs très régulièrement utilisées lors de l’affichage.
Pour un film, on va peut-être utiliser soit une image fixe soit une petite séquence animée, l’une comme l’autre extraite du film.

L’affichage final peut dans certains cas prendre en compte simultanément plusieurs objets titres mais de types différents. Par exemple accepter une image et un texte, ou un morceau de film, un son et un texte…
Protéiforme ne veut pas dire en forme de protéine mais bien de formes multiples.
Tout est question d’interprétation et de stratégie d’affichage. Tout est possible, aussi.

Dans sylabe, comme dans nebule, une entité a un nom constitué d’un petit texte, un prénom et même un préfixe sur le même principe. Mais elle peut aussi depuis peu avoir une image, typiquement une photo d’identité. Le nommage multiple et protéiforme existe donc déjà.

N̩buleuse soci̩tale et confiance РChiffrement par d̩faut

La relation entre les êtres humains est resté assez stable dans son contenu mais à beaucoup évolué dans sa forme avec la technique. Le la taille d’un village, d’une tribu, la dimension du réseau social d’un individu a fortement grandi et a cessé de coller à sa zone géographique proche. Mais il n’a pas forcément grossi pour autant, il ne s’est que dilaté. Il garde d’ailleurs une forme nébuleuse dense au centre et distendu en périphérie.
Le téléphone a accéléré la vitesse de transmission des informations et de fait a permis d’étendre encore plus la portée des échanges, et donc l’influence des individus. Cette extension a fini par atteindre sa taille limite, celle du monde.
Mais les échanges d’informations ne se limitent pas à l’influence, politique, des autres. On y retrouve des choses qui n’ont pas grand intérêt à première vue comme la correspondance familiale ou la propagation de la culture. Cependant, ces deux exemple ont une importance profonde dans l’identité de l’individu d’une part et de la société d’autre part.
Le réseau social individuel n’est plus depuis longtemps calqué sur son influence physique directe. Si il n’est pas évident de parler de réseau social d’un groupe d’individus, ou société, on peut quand même se raccrocher à son influence directe. Et l’influence des sociétés ne sont que rarement exactement calquées sur leurs influences physique directe, c’est à dire sur les frontières d’un pays.
Une société ne doit pas être vue comme une forme nébuleuse unique de relations sociales mais comme une forme nébuleuse sociétale composée d’une multitudes de formes nébuleuses entremêlées. Une société est composée d’une multitude de formes nébuleuses individuelles avec quelques structures communes, mais surtout, pour les individus, avec une majorité de liens au sein de la nébuleuse sociétale. Le nationalisme ou communautarisme, du point de vue du réseau social, sont des tentatives pour imposer des structures uniques fortes et donc de forcer la nébuleuse sociétale à se scinder en de multiples formes sous-sociétales. Il existe une multitude de formes sous-sociétales susceptibles de développer une forme de communautarisme puisqu’il est en pratique impossible d’avoir une nébuleuse individuelle approchant la forme nébuleuse sociétale dans son ensemble. Le nationalisme use de sa forme de nébuleuse sociétale pour revendiquer une influence physique y compris hors des frontières de l’état qui le définit à l’origine.
Le réseau Internet est un support d’information, il permet de diffuser la connaissance à tout un chacun. Mais ce n’est pas sont seul rôle, il permet aussi de relier les individus. C’est à dire qu’il sert de support universel à la forme nébuleuse des relations sociales d’un individu. Nous avons encore des échanges sociaux directs entre individus, instantanés, mais ils ne sont plus ni exclusifs ni même nécessaires ou systématiques.
Le projet nebule se doit donc de faciliter le partage de l’information, de la connaissance, mais il se doit aussi de faciliter les échanges sociaux entre individus. Le projet nebule doit être capable de coller au plus prêt de la nébuleuse de l’information d’un individu, mais aussi de la nébuleuse de son réseau social.

La messagerie telle qu’elle a commencée était un message manuscrit sur un support papier ou équivalent et pouvait mettre plusieurs mois pour arriver à destination… quand ça arrivait…
Aujourd’hui, un message traverse le monde en quelques secondes avec une très grande probabilité d’arriver à destination. Le plus long, c’est maintenant d’attendre que le destinataire ouvre son message. Tout le monde fait confiance à la messagerie électronique et à une bonne confiance dans les échanges postaux nationaux et internationaux.

Et puis il y eu Edward SNOWDEN.

La confiance, c’est la capacité du système à fonctionner tel que l’on s’attend à ce qu’il fonctionne et à être résistant aux tentatives de détourner son fonctionnement.
Là, subitement, on a une grosse crise de confiance. On se dit qu’on ne va peut-être pas laisser tous ses Å“ufs dans le même panier. Le projet nebule peut sous cet éclairage paraître un peu trop intrusif et exclusif (des autres).

Cette crainte vis-à-vis du projet nebule est à la fois recevable, et non recevable.
Le projet sylabe, annexe de nebule, est une implémentation suivant les paradigmes actuels en terme d’échange de l’information, et surtout en terme de concentration de l’information. Il est conçu volontairement dès le début pour centraliser les données sur un serveur de l’Internet. C’est cette concentration sur une machine que l’on ne maîtrise pas qui pose de gros problèmes aujourd’hui. C’est cette concentration sur des machines chez des grosses sociétés au USA qui permet à la NSA (entre autres) de violer l’intimité numérique des individus sans raison valable. Et c’est fait de telle façon que les individus gardent confiance dans cette concentration de leurs données.

Mr SNOWDEN a cassé la confiance que nous avions dans la concentration de nos données, la confiance pour ces grosses sociétés américaines, et la confiance dans l’Internet même. Il a montré que quelque chose ne fonctionnait pas bien. Mais il l’a fait pour que ça s’améliore, pour que nous fassions les efforts nécessaires pour reconstruire l’Internet et la confiance que l’on attend de lui.

Le projet sylabe est donc un reliquat de ce passé. Mais il apporte quand même quelque chose pour le futur. Il centralise les données mais contient les graines de leur décentralisation complète.
Si tout le monde n’est pas prêt aujourd’hui à installer un serveur pour héberger ses données, on y arrive quand même de façon détournée. Certains installent des boîtiers NAS, c’est déjà une forme de réappropriation de ses données. Toutes les maisons ont une box qui fait office de centre multimédia, de NAS. La domotique arrive tout doucement (depuis 20 ans). Ainsi, une instance sylabe pourra être un jour implémentée facilement dans un boîtier pour non seulement héberger nos donnés mais aussi pour nous permettre d’échanger avec nos amis.
Le projet sylabe, une fois implanté ailleurs que sur des serveurs centralisés permettra la mise en place complète de la vision de la nébuleuse de nos informations, complètement décentralisée mais centrée sur nous.

Il reste à traiter le problème de l’anonymat. C’est en cours de définition et d’implémentation.
Cet objectif à part entière, dans le contexte actuel, nécessite qu’une entité puisse nativement et par défaut chiffrer tous ses objets et offusquer tous ses liens, ou presque tous. Cette possibilité sera intégrée rapidement dans le projet sylabe.

Google+ et l’anonymat

Dans un article, le réseau social Google+ revient sur les restrictions de nommage de ses utilisateurs. Il va maintenant être possible de choisir des pseudonymes de façon à profiter du réseau social en ligne tout en permettant un certain anonymat.

Il était temps…

L’étape suivant serait de permettre à tout utilisateur de pouvoir nativement créer des pseudonymes partiellement autonomes. L’idée est en cours de mise en place sur le projet sylabe. La condition du succès est bien sûr que qu’un pseudonyme puisse avoir une vie propre, ses propres relations et groupes (cercles sur G+) et que l’on bascule de façon équivoque de l’entité principale vers un pseudonyme. C’est un bon moyen de répondre à des besoins d’anonymisation tout en facilitant la gestion de l’anonymisation par les vrais utilisateurs.
Il faudra aussi déterminé si un pseudonyme apparait clairement comme tel dans les utilisateurs ou si sa vraie nature reste cachée pour préserver son efficacité.
Bien sûr, il faudra garder à l’esprit que monsieur Google aura accès à toutes les entités, que ce soit les vrais utilisateurs ou leurs pseudonymes. Cela répond dans ce cas aux problèmes légaux pour pouvoir remonter, sur décision d’un juge, à la personne physique derrière un pseudonyme.

PHP et programmation objet

La librairie de référence php est en cours de portage en programmation objet, ce qui est différent de la notion d’objet propre au projet nebule.

Je me base sur différents tutoriels :
– http://fr.openclassrooms.com/informatique/cours/programmez-en-oriente-objet-en-php
– http://jcrozier.developpez.com/tutoriels/web/php/programmation-orientee-objet/
– http://stephaneey.developpez.com/tutoriel/php/php5_nouveautes/
– http://alain-sahli.developpez.com/tutoriels/php/les-interfaces/
– http://blog.xebia.fr/2011/07/18/les-principes-solid/

Les implémentations que je vais essayer de suivre pour leur côté éprouvé… et logique :
РLe mod̬le MVC.
– La notation PEAR.
РLe mod̬le Design by contract (DbC).
РLe mod̬le SOLID.

Le modèle MVC est assez logique, à tel point que c’est déjà quasiment la forme adoptée par le code de la librairie et de sylabe aujourd’hui.

Voici l’organisation du code pour l’instant :
– class nebule
– class Object extends nebule
– class Entity extends Object
– class Link extends nebule
– interface ioInterface
– class ioFileSystem implements ioInterface
– class Metrology

Exception à la notation PEAR, la classe nebule commence avec une minuscule et non une majuscule. C’est la seule.

Il y a des choses que je vais tout de suite bannir :
– On commence par les parent::quelquechose. Trop de risque de confusion et d’erreur.

A compléter…

Prise d’empreinte homomorphique

Les objets manipulés par nebule sont identifiés, et donc référencés, par leurs empreintes respectives. Ces empreintes sont cryptographiques afin de pouvoir s’assurer que c’est bien le bon objet, afin de pouvoir avoir confiance dans l’intégrité de son contenu. Il est possible dans un seul cas d’avoir plus d’une empreinte par objet, c’est si celles-ci sont calculées avec des algorithmes différents (cf Collisions d’empreintes multi-algorithmique).

Cependant, si la propriété cryptographique des empreintes est indispensable à la confiance, elle entraîne un manque de souplesse dans le référencement des objets. Rien dans la valeur de l’empreinte ne trahis une partie de son contenu. L’empreinte cryptographique reflète uniquement l’intégralité de l’objet. On ne peux pas s’en servir pour retrouver des objets proches dans leur contenu. Tout au plus peut-on vérifier si deux objets sont identiques… ce qui n’a pas d’intérêt puisque dans ce cas c’est tout simplement le même objet.

Sub-division d’objet

La première solution pour résoudre ce problème est d’utiliser des sous-parties d’un objet comme des objets propres, et de les identifier comme tels. Le lien de type s permet justement de lié l’objet principal à ses morceaux.

C’est notamment ce qui est fait dans les logiciels de Paire-à-Paire (P2P – Peer to Peer). Pour qu’un fichier puisse être téléchargé depuis de multiples sources, celui-ci est pré-découpé en morceaux de taille identique pré-définit. Chaque morceau à une empreinte propre et peut être vérifié à la réception. Chaque morceau est téléchargé sur une et une seule source, mais plusieurs morceaux sont téléchargés simultanément depuis plusieurs sources. On augmente ainsi le débit réel de réception du fichier voulu même si les sources ont individuellement un faible débit d’émission. Évidemment, si chaque morceau est valide, le fichier dans son ensemble ne peut qu’être valide.

Une recherche sur mot clé peut avantageusement tirer partie de ce système puisqu’une recherche se fera uniquement sur l’empreinte du morceau correspondant à la recherche. Toute la difficulté est de bien choisir ces morceaux.

Pour du texte, c’est facile. Pour une recherche sur des images ou des vidéos, c’est déjà beaucoup moins évident. Mais quoique l’on trouve, c’est toujours une liste d’objets qui contiennent cette petite sous-partie même si le reste n’a absolument aucun rapport.

Empreinte homomorphique

Une autre solution consiste à essayer de trouver des objets qui ont le plus de contenu en commun. Ce serait une sorte de représentation miniature du contenu de l’objet. On veut quelque chose qui se rapproche plus de l’empreinte des doigts de pieds. On regarde d’abord que cela à bien la forme d’un pied, puis on regarde plus en détail certaines parties morphologiques pour déterminer si les deux pieds sont proches.

On pourrait partir sur le système de sous-découpage utilisé par le P2P. Chaque objet est découpé en petits morceaux de taille identique. Ainsi, si deux objets ont un ou des morceaux en commun, on pourra en déduire que ceux-ci sont proches.
Mais cette méthode pose un problème. Si on prend un objet et que l’on en fait une copie avec pour seule différence un caractère supplémentaire dans le premier bloc de données, alors tous les blocs seront vus comme différents alors que les objets ont clairement des parties communes.
On pourrait imaginer essayer d’optimiser la méthode en travaillant sur des blocs de tailles variables. Mais quels critères adopter pour ajuster les tailles de blocs en fonction des données ?

Je propose une méthode comme base de réflexion à défaut pour l’instant d’être adoptée.
Si on regarde le travail d’un logiciel de compression de données, on constate qu’il recherche les occurrences multiples de données dans l’ensemble d’un document. Il le fait sans tenir compte de la sémantique de ce qu’il trouve. Ainsi des mots très proches sémantiquement ne seront pas agrégés parce que différents. Ensuite, le logiciel de compression fait un classement statistique pour déterminer les occurrences multiples qu’il serait avantageux de réduire. Une phrase qui apparaît quelques fois permet une bonne optimisation. Un mot qui apparaît plusieurs permet aussi un gain de place facile.
Si on reprend le même principe d’analyse, même sans tenir compte de la sémantique des mots, on peut s’attendre à ce que les plus grandes occurrences de mots ou de phrases représentent le ou les sujets du document. C’est ce que fontnotamment les moteurs de recherches (Google, Bing, Yahoo…) lorsqu’ils moulinent les pages web, mais avec l’analyse sémantique en plus.
L’empreinte homomorphique est constituée des 20 premières occurrences redondantes avec leur poids respectifs. L’occurrence peut être représentée par une petite empreinte (CRC) de façon à avoir une taille fixe, mettons 16 caractères hexadécimaux. Le poids peut être représenté en pourcentage sur 4 caractères hexadécimaux (entre 0000 et ffff).
Vue comme ça, l’empreinte générée n’est plus tout à fait homomorphique et n’a pas de propriétés cryptographique.On obtient une empreinte homomorphique de 400 caractères hexadécimaux.

Ainsi, plusieurs documents parlants d’un même sujet ont de fortes chances d’avoir une même empreinte parque bien que différents ils auront les mêmes occurrences redondantes.

Un certain nombre de données annexes vont figurer dans les données utilisées pour la comparaison. Par exemple on peut retrouver les en-têtes internes des documents bureautique. Il faut peut-être pré-filtrer les documents en fonction de leur type pur. Par exemple, un simple fichier texte et un fichier complexe de traitement de texte se verront expurgés de tout ce qui est en-tête et données internes, puis on en gardera que les caractères imprimables convertis en minuscule, sans ponctuation…

Conclusion

Une empreinte homomorphique peut être utilisée avantageusement en complément de l’empreinte cryptographique. Elle n’a d’intérêt que pour des objets ayant suffisamment de contenu. Il faut prévoir un seuil minimum en dessous duquel elle n’est pas calculée. Cette empreinte homomorphique est liée à l’objet par un lien de type l avec comme objet méta « nebule/objet/homomorphe ». Cet objet à usage réservé est ajouté à la documentation.

Mais dans tous les cas, en l’absence de propriétés cryptographique, une empreinte homomorphique ne doit pas être utilisée dans les liens. L’usage n’est pas le même, on fait soit de l’intégrité, soit du référencement.

Lien de type d, précisions

La documentation a été complétée pour le lien de type d :

L’objet est marqué comme à supprimer d’un ou de tous ses emplacements de stockage.

d comme delete.

Le champs HashCible peut être nuls, c’est à dire égal à 0. Si non nul, ce champs doit contenir une entité destinataire de l’ordre de suppression. C’est utilisé pour demander à une entité relaie de supprimer un objet spécifique. Cela peut être utilisé pour demander à une entité en règle générale de bien vouloir supprimer l’objet, ce qui n’est pas forcément exécuté.

Le champs HashMeta doit être nuls, c’est à dire égal à 0.

Un lien de suppression sur un objet ne veut pas forcément dire qu’il a été supprimé. Même localement, l’objet est peut-être encore présent. Si le lien de suppression vient d’une autre entité, on ne va sûrement pas par défaut en tenir compte.

Lorsque le lien de suppression est généré, le serveur sur lequel est généré le lien doit essayer par défaut de supprimer l’objet. Dans le cas d’un serveur hébergeant plusieurs entités, un objet ne sera pas supprimé si il est encore utilisé par une autre entité, c’est à dire si une entité a un lien qui le concerne et n’a pas de lien de suppression.

CF : Documentation_-_nebule_v1.2 – Action_d_-_Suppression_d’objet

Lien de type c, précisions

La documentation a été complétée pour le lien de type c :

Ce lien contient un lien chiffré. Il permet d’offusquer des liens entre objets et donc d’anonymiser certaines actions de l’entité.

Le champs HashSource fait référence à l’entité destinataire du lien, celle qui peut le déchiffrer. A part le champs de l’entité signataire, c’est le seul champs qui fait référence à un objet.

Le champs HashCible ne contient pas la référence d’un objet mais le lien chiffré et encodé en hexadécimal. Le chiffrement est de type symétrique avec la clé de session. Le lien offusqué n’a pas grand intérêt en lui même, c’est le lien déchiffré qui en a.

Le champs HashMeta ne contient pas la référence d’un objet mais la clé de chiffrement du lien, dite clé de session. Cette clé est chiffrée (asymétrique) pour l’entité destinataire et encodée en hexadécimal.

Lors du traitement des liens, si une entité est déverrouillée, les liens offusqués pour cette entité doivent être déchiffrés et utilisés en remplacement des liens offusqués originels. Les liens offusqués doivent être vérifiés avant déchiffrement. Les liens déchiffrés doivent être vérifiés avant exploitation.

CF : Documentation_-_nebule_v1.2 – Action_c_-_Chiffrement_de_lien

Lien de type f, précisions

La documentation a été complétée pour le lien de type f :

Le nouvel objet est considéré comme enfant ou parent suivant le sens du lien.

Le champs HashMeta doit être vu comme le contexte du lien. Par exemple, deux objets contenants du texte peuvent être reliés simplement sans contexte, c’est à dire reliés de façon simplement hiérarchique. Ces deux mêmes textes peuvent être plutôt (ou en plus) reliés avec un contexte comme celui d’une discussion dans un blog. Dans ce deuxième cas, la relation entre les deux textes n’a pas de sens en dehors de cette discussion sur ce blog. Il est même probable que le blog n’affichera pas les autres textes en relations si ils n’ont pas un contexte appartenant à ce blog.

CF : Documentation_-_nebule_v1.2 – Action_f_-_Dérivé_d’objet

Canaux cachés dans les liens

Il est difficile de lutter contre les canaux cachés dans les protocoles. C’est notamment le cas pour nebule avec les liens. Tous les champs du registre sont potentiellement concernés mais différentes stratégies peuvent être mises en place pour détecter à postériori le canal ou réduire fortement le débit utile à la transmission de données.

Le champs le plus facile à utiliser pour un canal caché est le champ action. Sa vérification doit être vérifiée pour que sa taille soit strictement limité à un caractère et uniquement à un des types de liens attendus.

Le champs date peut être exploité dans ses valeurs de plus faible poids comme la seconde ou ses sous multiples. Tant que l’ordre temporel des liens est respecté, il est tout à fait possible de mettre des valeurs arbitraires et donc du contenu encodé en chiffres décimaux.
De plus, comme on ne s’oriente pas vers une interprétation stricte de la norme ISO 8601, il devient possible d’utiliser une grande précision dans les sous multiples de la seconde. C’est à dire que l’on peut placer un grand nombre de chiffres en fin de date tant que ce sont des chiffres décimaux.
La vérification de la date peut inclure une taille limite pour réduire la quantité de données cachées.

Les champs des objets peuvent référencer des objets fictifs, et donc en fait ces champs peuvent contenir des données convertis en hexadécimal. Il est possible de vérifier que ces champs objets ont une taille compatible avec les algorithmes de hash. Il est possible de vérifier si ceux-ci ont tous les attribut que l’on attend d’un objet, voir qu’ils sont bien disponibles.

Le champs de l’entité signataire ne peut pas être modifié n’importe comment, mais en utilisant plusieurs entités différentes on peut faire un canal caché sous forme d’une sorte de morse. Cela peut peut-être être détecté en regardant les entités en question.

Le champs signature n’est pas facilement exploitable. Tout au plus peut-on faire du morse en jouant sur la date pour générer une signature qui commence ou termine par un chiffre précis. Il est plus probable que le champs date soit exploité à la place pour un canal caché.

La documentation va être modifiée pour réduire les problèmes avec les champs date et action.