Catégorie : empreinte

Premiers liens signés en v2.0

Les deux premiers liens dans la nouvelle forme en v2.0 viennent d’être signés :

nebule:link/2:0_0:020210714/l>88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>5d5b09f6dcb2d53a5fffc60c4ac0d55fabdf556069d6631545f42aa6e3500f2e.sha2.256>8e2adbda190535721fc8fceead980361e33523e97a9748aba95642f8310eb5ec.sha2.256_88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>79bf4029cf6ee77b0f9db987fcb59c53434a8f2e36773d7a427ec869de04698ddb044bfe08d963732dec237ef56b03f003f4bcc491e293c0b6a7396a351b10e319aa80984bd5d7c0c812cd6a91a296d55ace2e6e6d266dd06c83f21814e272793e75e23cb8f70911ba845885f9e41636466b74e6a7f7e1c174e612776981e645273ac59410ab39606feb20102cf28834aa054008bb35191573189bb0266875dd82cbf12dc64d0eb77acf59e18c8336583faac32755450c00d559398fbd078871fcd9097ac476f67010a9d728a00860f1e34f66bd32b64093b834fcce2bf028193335ebedd1ae27e29df3b8184360bee9dbc707135c54ef48d3efc096b32ba33681925afb8d4e7d4f91598f4d250eb9d27b96762727610a87317892033e84e6e7198837a10ef5e8582ecb98d6aef00e7b4ef2d536cb2063b476d21a8abaf6678462e329bf08bb9159ec4a7358b1e6b15252bd1acf471eb43895edc4caaee58e9d1fcd36cd21b7fc45fb43443c3408de80c1aa3d8c45c71071bfebbfa0c82f747e97f0668d628a3bb5f18cf105b5c16ac14fa61730fdf97342add718ee6c55cf576b060027ce5dfd3651349ff3163011f58cdc2140ea3ef9d2bfefe1d105498722b6ff3c0993aaffa0f0625e5bd2503cf289ec3e694b43616134d1a938dfe1d050b4106f466b23c2dc446e7f1d96a942aaa73c694a8434bdf549fde985ff939142.sha2.512
nebule:link/2:0_0:020210714/l>88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>970bdb5df1e795929c71503d578b1b6bed601bb65ed7b8e4ae77dd85125d7864.sha2.256>5312dedbae053266a3556f44aba2292f24cdf1c3213aa5b4934005dd582aefa0.sha2.256_88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>58ca04cc43fc46c7a5176f2ff8f93754da9cfaabff2f12a3c9e6453d3dd3eeedd0208477f9e62c085a6f32583a127467696d7af980fe18a85a7951a6deea6372ca9f0c965d0a08fa159f241a680d5dba69449acb03043fc8021b93a2e34a1c3fb93385250f5ebf7a457fd38f2c6b1e500614f19b37bd37416342ddd94385ec2f5185fddde6d803fc1f89dabe6aebcd55490688cdbe5c779ae2b81d7a4b65c57fd6b35b6ad0fb20881f12c04e34a1730e254530a9c69fdaa9c1ef76fa6248a6e22417e25758837c7378f97af5c3d2cfe88fe9711ba705e2d017fe7ff4c97cbb44600e0d7b32e1c2f97467d8e79d48fc5d6dbd3d581bb831582be7f1a918609cd4a64e4d621bababaddde6da3621f24220ed7dc2ae585fe9b7f9cd71fe18a1a75778c54bdf1e7ad066e10c36e7fb2a4577f9d1bc7be1f80363d1a3e58e34ee4971ccd0a8a8b45665b1234909104558cb210ea402cb7822e3f4c5e1095c4f6a8a86b432b7c77028c76d38dd171a009dd7b251f74ea112739b91cfd8a6c665546bb984dc2fd1f59212a59f84154556bcdfade82c1b049e91a1befa45f2511f02123aa3f7718b0c64aeca984eb70cb9841e933603221765899384e1d3467cb31071ae3071e741f9689735a7e0c8cf7e202b926260067112fec8b24f991a6b35868fbb3653f2be774574d87e1a0fe9222774f6ede5b38c8393d72ff866faa40c5b706f.sha2.512

Ces deux liens concernent l’entité puppetmaster et sont ceux posés par défaut lors du premier lancement du bootstrap, lorsqu’il n’y a encore rien d’autre.

Ils sont la particularité d’avoir une signature faite sur un hash à 512bits.

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.

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.

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.

Protection des objets – les origines

Le problème de protection des objets de faible taille, tel que décrit dans l’article Protection et faible entropie, n’a pas de solution simple ou élégante. Peut-être qu’il est temps de se questionner sur la pertinence de la façon dont est assurée la protection des objets, de revoir les réflexions à l’origine de la protection des objets.

D’ailleurs, dans le même ordre d’idée, il faudra peut-être aussi se poser des questions par rapport à la dissimulation des liens qui crée un problème différent mais sans solution simple, performante et élégante.

A l’origine, l’usage de la protection des objets n’avait pas été vu avec autant de cas d’usages. L’idée était de pouvoir dissimuler le contenu d’une objet tout en continuant de le tracer, c’est à dire de l’identifier par son empreinte. Il semblait peu utile de dissimuler des choses aussi simple que « oui » ou « non ».
La capacité de pouvoir tracer devait aussi permettre de pouvoir bannir un objet en se basant sur son empreinte en claire. Une fois protégé un objet a une infinité d’empreintes possibles, donc il devient non traçable en pratique.
L’idée était aussi de pouvoir vérifier que le contenu protégé que l’on recevait d’une autre entité correspondait bien au contenu en clair attendu. Ceci avait pour but de ne pas ce retrouver avec un code offensif une fois déprotégé en lieu et place d’un objet anodin. Dans ce cas un contenu offensif peut être écarté rapidement par un simple lien de mise en liste d’exclusion.

Le problème vient du fait que le lien de protection de type k, en particulier le lien de chiffrement symétrique, fait l’association entre la valeur claire et la valeur chiffrée de l’information. En disposant de l’empreinte de l’information en claire on peut, si la valeur totale de son entropie est faible (ou si, déduit des parties prévisibles, la valeur totale résiduelle de l’entropie de l’information est faible), on peut dans ce cas recalculer l’information.
Il est théoriquement possible que le recalcule de l’information en claire donne une autre information ayant la même empreinte. Mais l’espace des valeurs calculables étant inférieur à la taille de l’empreinte des objets, càd la valeur totale de l’entropie de l’information recalculée en rapport avec la valeur totale de l’entropie d’une empreinte, et en considérant l’algorithme de prise d’empreinte cryptographique suffisamment robuste, il est très peu probable (de l’ordre de l’inverse de la taille des empreintes) de trouver une autre information de même empreinte. Ce serait même très inquiétant pour l’algorithme de prise d’empreinte cryptographique.

En parcourant le code et les cas d’usages actuels, il apparaît que l’on fait déjà indistinctement référence à un objet en clair ou protégé en utilisant son empreinte pour son contenu en clair ou protégé. Le code se charge de remettre dans le bon sens les deux identifiants.
Ne faire référence que à la partie protégée ne pose pas plus de problème que ça dans les usages actuels puisque l’on a juste besoin d’un identifiant.
Il est alors possible de recalculer l’empreinte, donc l’identifiant, du contenu en clair, et donc de pouvoir potentiellement le confronter à lien de mise en liste d’exclusion.

Le temps est encore à la réflexion mais la solution est peut-être là…

Protection des objets – faible entropie

Les messages que l’on protège peuvent être courts ou peuvent être dans certains cas facilement recalculés lorsque la seule partie variable du contenu a une faible entropie. C’est un problème général qui prend tout son sens dans la messagerie.
Le lien de chiffrement relie le hash de l’objet en clair avec le hash de l’objet chiffré. c’est indispensable si on veut pouvoir retrouver le contenu d’un objet en clair sans avoir à parcourir l’intégralité des hashs des objets protégés. C’est pour éviter le problème que l’on a avec l’implémentation des liens dissimulés.

Nous sommes dans le cas d’un modèle MAC-then-encrypt-then-MAC. Il faut trouver un moyen de renforcer l’entropie des objets protégés. Jouer sur le salage ou l’IV du chiffrement ne résout pas le problème puisque le problème vient du MAC avant chiffrement.
Et ce problème ne concerne pas des objets dont le contenu a une entropie supérieure à 128 bits et qui ne sont pas prédictibles. Il n’est pas utile, voire contre productif, de systématiser une solution de renforcement de l’entropie des objets protégés.

Il y a peut-être deux solutions. La première serait d’ajouter au contenu un aléa que l’on serait capable de retirer lors de l’exploitation de l’objet, comme du bourrage (padding). La seconde serait d’opérer sur l’objet une valeur d’un autre objet et de ne pas lié l’objet initial mais uniquement l’objet opéré. Cependant cette seconde méthode parait assez fragile en l’état.

La suite au prochain épisode…

Non vérification crypto et lecture seule

Dans la réflexion de créer une application dédiée à la manipulation de photos et de vidéos se pose invariablement la question des vidéos HD, FHD et UHD. La taille de ce genre de vidéo, pour conserver une qualité de restitution optimale, est assez conséquente.

Le problème ici dans nebule c’est la vérification systématique de la validité du contenu d’un objet manipulé, c’est à dire le re-calcul de son empreinte cryptographique. Si la librairie nebule mémorise le temps d’une session un objet vérifié, dans un cache, ce qui peut déjà présenter un problème de sécurité, il faut cependant toujours faire cette prise d’empreinte au moins une fois.
Par exemple l’empreinte SHA256 d’un fichier de 1,6Go va nécessiter environ 30s sur un disque dur à plateaux normal. La consommation de temps vient principalement de la lecture du support et non du calcul cryptographique. Et la prise d’empreinte cryptographique est un calcul relativement simple…

Il peut en être de même avec les liens qui nécessitent une vérification de signature de type RSA ou équivalent. Ce calcul en cryptographie asymétrique est beaucoup plus long rapporté à la quantité de données. Si un lien ne faire que quelques kilo-octets tout au plus, le nombre de liens à vérifier pour un seul objet peut être potentiellement gigantesque. Au cours du développement des applications de nebule il n’est pas rare de devoir nettoyer à la main les liens de la bibliothèque parce qu’il y en a plus de 80.000 … soit systématiquement 80.000 lien à lire et à vérifier. Là aussi un cache des liens déjà validés dans la session est en place pour accélérer le travail mais ce n’est pas toujours suffisant.

Une possible résolution de ce problème peut être de changer de disque et de passer sur SSD, ou de nettoyer sévèrement les liens utilisés. Mais ces deux cas sont extrêmes et pas toujours réalisables.

Une autre solution peut être envisageable dans le cas de machines de relais ou de partage d’informations en particulier. Comme on l’a vu dans l’article Frontal et relai d’information verrouillé en écriture, il est possible d’avoir des serveurs en lecture seule en activant l’option de lecture seule ou en figeant le système de fichiers. Cela pose des contraintes particulières sur la synchronisation des objets et des liens et sur le fait qu’ils doivent être vérifiés à un moment ou à un autre. Dans ce cas on peut coupler une option de non vérification des objets et des liens avec une option de lecture seule.
Avec cet exemple une entité peut toujours d’authentifier afin d’accéder à du contenu protégé mais ne pourra réaliser aucune action.

On peut imaginer aussi que l’application de mise à jour (upload) peut être autorisée à mettre à jours des liens et des objets en les vérifiant et ainsi avoir un serveur partiellement en lecture seule.

Donc il serait possible d’avoir un serveur de relai d’information en lecture seule uniquement mais avec un fonctionnement accéléré.
Ceci n’est pas implémenté actuellement.

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.

Renforcement de la lecture des objets – taille limite

Suite de l’article sur le Renforcement de la lecture des objets, type hash invalide et affichage.

Le renforcement de la lecture des objets et notamment la suppression sur empreinte invalide ou invérifiable entraîne un autre effet. Tout objet plus grand que la taille limite de lecture des contenus des objets, définit par l’option ioReadMaxData, est automatiquement supprimé lorsqu’on essaie de l’utiliser. Ce qui veut dire qu’il y a une valeur minimum à l’option ioReadMaxData pour ne pas empêcher le bon fonctionnement des applications.

Renforcement de la lecture des objets – affichage

Suite de l’article sur le Renforcement de la lecture des objets, et type hash invalide.

L’argument $permitTruncate ayant disparu, c’est aussi l’option displayUnverifiedObjects qui n’a plus de raison d’être. Les fonctions d’affichage qui auraient pu devoir afficher un objet trop gros pour le vérifier n’en verront plus dans tous les cas.

En échange, une nouvelle option permitCheckObjectHash est mise en place dans la bibliothèque nebule en PHP orienté objet.
Elle est utilisée dans la fonction _getUnprotectedContent(). Elle va activer la vérification de l’empreinte des objets lus, ou plutôt forcer la lecture de l’objet même si son empreinte est invalide ou non vérifiable. C’est le pendant de l’option permitCheckSignOnVerify ayant la même signification pour la vérification des liens. Elle a true comme valeur par défaut. Elle n’est pas modifiable par lien, pour changer sa valeur par défaut il faut modifier le fichier des options.
Cette option est critique, elle doit toujours rester par défaut à true !

Renforcement de la lecture des objets – type hash invalide

Dans l’article sur le Renforcement de la lecture des objets, il était question notamment de la possibilité de supprimer ou pas un objet dont on ne peut pas vérifier l’empreinte parce que le type de hash est soit inconnu soit non reconnu.

Lors de l’échec de la récupération du type de hash de l’objet, on essaye tout de suite, si l’option permitSynchronizeLinks est à true, de synchroniser rapidement les liens de l’objet. Puis on essaie de relire le type de hash de l’objet.

Une nouvelle option permitDeleteObjectOnUnknowHash vient d’être ajoutée. Elle a true comme valeur par défaut. Elle n’est pas modifiable par lien, pour changer sa valeur par défaut il faut modifier le fichier des options.
Cette option est critique, elle doit toujours rester par défaut à true !

La nouvelle option est utilisée par la bibliothèque nebule en PHP en programmation orienté objet (library POO) par les fonctions checkConsistency() et _getUnprotectedContent() de la classe Object. La fonction _getProtectedContent() ne prend pas en compte cette option, elle se base uniquement sur _getUnprotectedContent() pour la lecture de l’objet protégé et de la clé de déchiffrement associée.

L’implémentation de l’option est un tout petit peu différent ce que l’on peut attendre. Lorsque l’on recherche le lien du type d’empreinte d’un objet (avec la pondération sociale), si aucun lien n’est trouvé ou si le nom de l’algorithme de prise d’empreinte n’est pas reconnu, alors il y a deux possibilités.
L’option permitDeleteObjectOnUnknowHash est à :

  1. false. Dans ce cas les deux fonctions retournent tout de suite un résultat booléen négatif ou un contenu vide.
  2. true. Comme aucun algorithme n’est trouvé, on utilise l’algorithme définit par défaut et on continue le processus de vérification dans les deux fonctions. Si l’empreinte ne correspond pas avec cet algorithme, l’objet est supprimé. C’est une façon de donner une chance à un objet pour lequel les liens auraient été partiellement synchronisés.

Dans la bibliothèque nebule en PHP en programmation procédurale (library PP), la lecture des objets se fait via les fonctions _o_ls1 et _o_lsx. La deuxième repose en fait sur la première. Et en début de fonction _o_ls1, un appel à la fonction _o_vr permet de vérifier le contenu de l’objet.
La fonction _o_vr ne prend en compte que les objets avec un hash fait avec l’algorithme par défaut, aujourd’hui sha256. L’option permitDeleteObjectOnUnknowHash n’est pas utilisée.

Dans les deux bibliothèques, si c’est l’objet avec d’identifiant 0, alors il est systématiquement supprimé.

Enfin, dans tous les cas, il ne faut surtout pas tenter de vérifier l’empreinte avec tous les algorithmes disponibles, cela reviendrait à permettre une attaque sur le plus faible de ceux-ci…

Renforcement de la lecture des objets

Dans la bibliothèque nebule en PHP orienté objet et dans certaines applications, un certain nombre de fonctions lisent le contenu des objets soit directement soit via la fonction getContent() de l’instance Object des objets. Toutes les lectures de contenus d’objets et de liens se font via la classe io de la bibliothèque et non directement par des fonctions de PHP de lecture de flux, de lecture directe. Les fonctions de la classe io ne font pas d’opérations cryptographiques, donc aucune vérification n’est possible à ce niveau.

Dans la bibliothèque se trouve aussi la fonction checkConsistency() pour vérifier le contenu d’un objet. Deux différences existent entre les deux fonction :

  1. La fonction getContent() lit des données et vérifie si l’empreinte est bonne sauf si l’objet est trop grand. Si l’objet est trop grand, un argument $permitTruncate permet de ne pas rejeter le contenu de l’objet si il est trop grand. Pour les petits objets la vérification se fait dans tous les cas. La limite d’un objet petit ou grand est définie par l’option ioReadMaxData. Si l’empreinte ne correspond pas, le contenu n’est pas conservé et un contenu vide est renvoyé à la fonction appelante. La fonction checkConsistency() ne renvoie pas de données mais vérifie juste l’empreinte, le résultat booléen renvoyé et négatif ou positif.
  2. La fonction getContent() ne supprime pas un objet si l’empreinte n’est pas bonne. La fonction checkConsistency() vérifie l’empreinte et, si l’empreinte n’est pas bonne, supprime l’objet via une fonction de la classe io.

Il est difficile de prendre une décision de suppression d’un objet parce que peut-être que l’algorithme de prise d’empreinte n’est pas reconnu par la machine sur laquelle tourne l’instance serveur. En cas d’absence de possibilité de vérification comme un type d’empreinte inconnu ou un objet trop grand, il faut renvoyer un contenu vide ou résultat négatif mais il ne faut pas supprimer l’objet. Quoique dans un mode paranoïaque, il faut peut-être prévoir de supprimer tout objet non vérifiable, à voir.

Pour commencer l’argument $permitTruncate n’a pas de raison d’être, il est contre productif parce qu’il affaibli l’ensemble du système. Il va être supprimé et les applications qui affichaient un objet avec un message comme quoi l’objet est trop gros vont afficher un message d’erreur sans le contenu.

Ensuite, la fonction getContent() fait appel à une fonction privée _getProtectedContent() pour lire le contenu d’un objet protégé. Elle va maintenant sous-traiter aussi la lecture des objets non protégés à une fonction privée _getUnprotectedContent(). Cette nouvelle fonction sera très similaire à la fonction checkConsistency() mais renverra un contenu complet ou vide au lieu d’un résultat booléen. Et bien sûr l’objet sera supprimé en cas d’empreinte invalide. Et la fonction _getProtectedContent() utilisera la fonction _getUnprotectedContent() pour la lecture de tous les objets accessibles non protégés.

La suppression de l’argument $permitTruncate va poser un gros problème pour l’affichage des gros objets. Ceux-ci via le navigateur peuvent être affiché dans certains cas parce que le navigateur les télécharge sur le serveur web pour les afficher au fur et à mesure. C’est le cas des vidéos non protégées. Une des options pour résoudre ce problème est peut-être d’utiliser le lien de type s jusque là inexploité par la bibliothèque…

Mémorisation de liens et accélération des traitements

Par défaut, à chaque chargement d’un objet pour traitement ou pour son affichage, chaque liens sont lus et vérifiés, puis relus et revérifiés. Parce que cette vérification implique des algorithmes cryptographiques de prise d’empreinte et des algorithmes cryptographiques asymétrique (à clés privées), le traitement cumulé de chaque vérifications devient vite une quantité non négligeable. Bref, le temps de calcul se ressent dans le traitement.

Il est possible d’accélérer ce fonctionnement avec la mémorisation des vérifications déjà faites.

Pour commencer, on peut considérer en première approximation que la plus grande partie du temps de traitement est imputable à la cryptographie asymétrique. On considère donc par défaut que les autres traitements sont, temporellement, quantités négligeables. cette approximation est vérifiée en pratique dans sylabe lorsque l’on désactive la vérification des signatures.

Pour des raisons de sécurité, les liens qui ont été vérifiés, et que l’on souhaite mémoriser, doivent être mémorisés en intégralité. Il ne faut pas garder uniquement la signature du lien. Il est préférable de conserver l’intégralité du lien. Tout au plus peut-on supprimer le champs signature. Ces liens pré-vérifiés doivent être conservés en lieu sûr, non modifiable par une autre entité ou un autre processus.
Dans ce cas, la vérification d’un lien va commencer par le parcours des liens déjà vérifiés, puis en dernier recours à vérifier le lien. Au delà d’un certain nombre de liens mémorisés, il est possible que le bénéfice de la mémorisation soit négatif vis-à-vis de la vérification direct des signatures des liens. Il faudra montrer expérimentalement l’ordre de grandeur de la table des liens mémorisés. Qui dit table de mémorisation limité dit aussi gestion de la quantité de liens mémorisés et donc du remplacement de certains liens par d’autres. Ce remplacement peut se faire en boucle, sans calcul, ou au contraire en tenant compte du temps de dernier usage des liens mémorisés. Bref, il y a du travail d’optimisation en perspective.

Comme on l’a vu avec une table de mémorisation limitée, le temps de mémorisation des liens peut être variable. De même, une autre période de rétention peut exister. La table de mémorisation peut n’être valable que pour le temps de chargement d’une page (web). Ou au contraire la table de mémorisation peut être valable le temps de la session, c’est à dire tout le temps ou l’entité est déverrouillée. Dans le cas de navigations sur sylabe, et en étant non-déverrouillée, la mémorisation peut être liée à la session php, et donc expirer avec celle-ci.

Imaginons maintenant un peu le futur. Imaginons que chaque entité, chaque humain dispose de sa clé privée en permanence dans un périphérique, ou plutôt une prothèse. Empactée dans du matériel, la clé privée serait beaucoup mieux protégée. De fait, corrompre la table de mémorisation des liens vérifiés deviendra un moyen plus facile pour modifier le comportement d’une entité. Il doit donc être maintenu la possibilité de fonctionner en mode paranoïaque en vérifiant à chaque utilisation les liens.

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.

Détournement de liens de mise à jour

La mise en place dans sylabe du code nécessaire à la résolution du graphe des mises à jours d’un objet montre que l’on peut créer une sorte de raccourci d’objet.

Ce détournement ne pose à priori pas de problème puisqu’il sera impossible de créer un objet avec cette empreinte réduite et que toute tentative se traduira par un rejet de l’objet lors de la vérification d’intégrité.

Nommage des objets avec tag de hashage

Suite à l’article sur le Marquage du hashage qui faisait déjà référence à l’article sur les Collisions d’empreintes multi-algorithmique, la conclusion est qu’il faut marquer les empreintes des objets avec la fonction de hashage.

Cependant, cela ne va pas dans le bon sens. On ajoute de l’information là où elle n’est pas directement utile.

Pour la signature d’un lien (le premier champ du lien), il est préférable de pouvoir immédiatement disposer de la référence à l’algorithme de hashage. Celui-ci est utilisé en même temps que le lien, et surtout pour le vérifier.

Pour un objet, sa signature a de très très très faibles chances d’être commune à celle d’un autre objet avec la même fonction de hashage. On peut considérer la collision comme impossible en pratique. Il en est de même vis à vis d’une autre fonction de hashage, sauf si cette dernière est cryptographiquement faible. Exit les fonctions de hashage faibles tel MD5 et compagnie. D’un point de vue sécurité, il n’y a donc pas lieu de marquer l’objet avec la fonction de hashage.

Mais le besoin pour les gros fichiers reste entier. Ce marquage de l’objet peut être tout simplement un lien vers le nom de la fonction de hashage. Ce lien sera utilisé au besoin lors de la vérification de l’objet source.

L’objet meta correspondant au lien est « hash function« . Ce lien doit être présent.

Marquage du hashage

Se posait la question des collisions d’empreintes multi-algorithmique. Cette question a deux réponses.

La première, c’est que le calcul nécessaire à la recherche d’empreintes nécessite d’être refait pour chaque algorithme. On ne retire pas de la complexité puisque le calcul fait par un algorithme n’est pas réutilisable pour un autre. C’est, si je ne me trompe pas, la notion (mathématique) de groupe des algorithmes qui le garantie. La robustesse de l’ensemble est donc équivalente à celle de l’algorithme le plus fragile.

La deuxième réponse concerne le calcul et re-calcul des empreintes pour les très gros objets. Aujourd’hui, un objet correspond souvent à un fichier tel qu’on l’utilise sur différents supports ou via différents moyens de diffusions. A l’avenir, il est fortement probable qu’un fichier soit représenté par plusieurs objets dont chacun aura un rôle précis et très épuré, et donc plus petit. Ainsi un objet peut être très volumineux et donc nécessité un gros effort de calcul de son empreinte. Le faire une fois, la première fois, déjà c’est long. Le refaire régulièrement pour vérifier qu’il n’est pas endommagé va encore augmenter l’effort. Si en plus on ajoute qu’il faut refaire ce calcul pour plusieurs algorithmes différents, et donc relire plusieurs fois l’objet volumineux…

Donc, il faut ajouter l’algorithme de hashage utilisé devant chaque empreintes. Et il faut mettre à jour tous les programmes pour qu’ils en tiennent compte.

SHA256?

Quelle est la solidité de l’algorithme de hash SHA256?

Le site www.ecrypt.eu.org (ECRYPT II) diffuse un document D.SPA.17.pdf (sans licence apparente) récapitulant les propriétés d’algorithmes cryptographiques et de pratiques. Ce document récapitule les travaux sur ces algorithmes et méthodes, et évalue la solidité de ceux-ci.

Le site www.keylength.com référence les recommandations de différents organismes gouvernementaux et notamment celles de l’ANSSI. Les recommandations de l’ANSSI sont disponibles dans le document RGS_B_1.pdf.

Conclusion, SHA256 est adapté à l’utilisation que l’on en fait aujourd’hui dans nebule.

Continuer la lecture de SHA256?

OpenSSL plutôt que GPG!

Suite aux problèmes pour exploiter gpg2, et après quelques essais avec openssl, décision est prise de basculer vers ce dernier.

Ci-dessous, quelques opérations de base nécessaires au bon fonctionnement de nebule, et notamment pour l’expérience 3.

Continuer la lecture de OpenSSL plutôt que GPG!

GPG ou OpenSSL?

Mes machines Linux disposent de différents algorithmes de hashage, de chiffrements symétriques et asymétriques. Mais l’utilisation de ces algorithmes n’est pas directement possible facilement (pour moi).

J’ai essayé pendant un certain temps de générer des entités avec des clés PGP (via gpg2). Mais je me heurte souvent à son manque de souplesse. C’est prévu pour chiffrer des fichiers et pas autre chose. On peut chiffre à la volé depuis la ligne de commande et via un pipe, mais la signature fait plusieurs lignes de texte en base-64, il est très difficile dans ce cas d’extraire la signature proprement dite en hexadécimal… et inversement de la ré-assembler pour la vérifier…

Bref, je me tourne aujourd’hui plutôt vers openssl qui permet à priori des manipulations cryptographiques de façon plus souple. Le format de stockage de clés qui me plaît le plus est le PEM.

On va voir jusqu’où on peut aller… Continuer la lecture de GPG ou OpenSSL?