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.