Empreintes des références et lien d’équivalence

Les algorithmes cryptographiques utilisés aujourd’hui sont voués un jour ou l’autre, à longue échéance on préfère, a expirer et être remplacés.

C’est notamment le cas des algorithmes de prise d’empreinte, dites fonctions de hash. Aujourd’hui on utilise généralement sha256 ou sha512, c’est à dire des dérivés de sha2. Mais sha3 arrive et va inexorablement pousser sha2 vers la sortie.

L’évolution de ces algorithmes répond à un problème de sécurité. Mais il est des cas où ils ne sont pas utilisés pour leur sécurité. Par exemple le hash d’un objet définissant une référence se soucie peu de la sécurité de son hash. Ce qui est utilisé c’est la valeur du hash et non du texte à l’origine du hash. Et le hash d’une référence est toujours utilisé dans un lien, donc protégé par une signature.
Dans le cas des références nous allons donc utiliser un algorithme fixe, arbitrairement ce sera sha256, soit une fonction sha2 produisant 256 bits de hash.

Cela n’est pas anodin, ce n’est pas juste une simplification du code. C’est aussi une accélération potentielle pour l’avenir puisqu’il ne sera pas nécessaire de rechercher des objets par référence en se basant sur de multiples empreintes de la référence. Et cela veut dire qu’il faut éviter aussi de d’utiliser le lien d’équivalence pour gérer des équivalences de références.

Nettoyage des liens – suite

Ceci est la suite du post précédent sur le nettoyage des liens.

En cas de suppression d’un objet, quels liens doit-on garder ?

Il faut déjà évidemment garder le lien de type d, celui qui marque la suppression de l’objet. Sans ce lien, la propagation de la suppression ne sera pas assurée, et donc l’objet ne sera pas supprimé sur tous les emplacements. Si il est encore présent sur un emplacement connu, il risque d’être téléchargé de cet emplacement et donc en quelque sorte restauré. Ce lien doit être gardé « Ã  vie ».

Il faut garder les liens de type u, c’est à dire voir quel(s) objet(s) est mise à jour l’objet supprimé. Il est préférable dans une chaîne de mises à jours de créer un nouveau lien qui court-circuite l’objet supprimé au milieu de la chaîne.

Il faut garder les liens de type e, les définitions d’équivalences.

Il faut supprimer tous les liens dont on est pas le signataire. Il n’y a pas de raison de garder les liens des autres entités. Les autres entités s’occuperont de leurs liens.

Il faut garder les liens de type k, correspondant au chiffrement. Lors du chiffrement d’un objet, on définit explicitement la suppression de l’objet originel pour ne garder que son dérivé chiffré.

Il faut supprimer les liens de type s, ce qui défini les subdivisions de l’objet. Cet objet n’est plus utilisable pour la récupération de morceaux. Et si il est recréé, les liens de type s le seront aussi naturellement, si besoin.

Jusque là, ça paraît suffisant. Mais que se passera-t-il le jour où, pour quelque raison que ce soit, l’objet venait à être réutilisé (volontairement) ?
Faut-il garder tous les liens de type l et f? Faut-il n’en garder qu’une partie?

Il faut aussi nettoyer les liens qui ont fait l’objet d’une suppression avec un lien de type x. Et il faut garder chaque derniers liens de type x. Ainsi, en cas de restauration de l’objet, les liens supprimés ne pourront être restaurés aussi.

Si c’est une suppression liée à un chiffrement, on doit garder tous les liens de type l et f. Ces liens sont nécessaires puisque l’objet à de bonnes chances d’être déchiffré un jour par le destinataire.

Dans les autres cs, c’est ambigu. Par défaut il vaut mieux garder tous les liens l et f.

Dans le cas d’un serveur que l’on ne maîtrise pas ou qui est mutualisé, la suppression d’un objet doit être marqué par toutes les entités. On ne peut pas supprimer un objet tant qu’une entité l’utilise encore. On entre là dans une forme de gestion en groupe.