Archive for the ‘orienté objet’ Category

Modification des sources d’aléa – implémentation

Jeudi, juin 8th, 2017

Suite à l’article Modification des sources d’aléa, la fonction getPseudoRandom a été modifiée dans la bibliothèque PHP orienté objet de nebule pour ne plus consommer du tout de ressource d’aléa mais en gardant une entropie forte.

La génération se fait depuis une graine qui est la concaténation de la date, de l’heure en micro-secondes, du nom de la bibliothèque, de la version de la bibliothèque et enfin de l’identifiant de l’instance locale du serveur. La graine dépendant donc surtout de l’heure avec une grande précision et est spécifique à chaque serveur.

La graine sert à générer via une fonction de hash l’état du compteur interne. Comme la taille du hash est fixe, une boucle permet d’alimenter la sortie en dérivant successivement l’état du compteur interne. À chaque tour de la boucle, l’état du compteur interne est dérivé en calculant le hash de lui-même. À chaque tour de la boucle, on concatène à la sortie le hash de l’état du compteur interne concaténé à une valeur fixe. L’état du compteur interne n’est jamais directement sorti et il est effacé en fin de génération de fonction.

Le bootstrap utilise aussi une génération pseudo aléatoire pour la création notamment d’identifiants temporaires. La bibliothèque PHP procédurale intégrée au bootstrap a aussi été modifiée. Elle fonctionne sur le même principe décrit ci-dessus. Une nouvelle fonction __pr est créée et les fonctions ne nécessitant par un aléa fiable ont été modifiées.

La fonction de hash actuellement utilisée pour la dérivation du compteur interne et la fonction sha256. Comme on attend pas de propriété cryptographique forte dans cette fonction, n’importe quelle fonction de hash peut faire l’affaire.

Ce sera disponible dans la prochaine version diffusée de la bibliothèque de nebule.

Modification des sources d’aléa

Samedi, juin 3rd, 2017

La bibliothèque nebule en PHP orienté objet présente deux fonctions de génération d’aléa dans la classe dédiée à la cryptographie.

Les fonctions :

  • public function getPseudoRandom($size=32)
  • public function getStrongRandom($size=32)

La première fonction getPseudoRandom permet de générer un aléa correct mais pas fiable, c’est à dire de qualité mais pas pour un usage cryptographique sûr. Il va servir principalement pour générer des identifiants d’objets de références.

La seconde fonction getStrongRandom permet de générer un aléa beaucoup plus fiable, c’est à dire réellement non prédictible, pour un usage cryptographique sûr. Cependant cet aléa est précieux parce que sa génération prendre du temps et peut consommer des ressources, ce qui limite la quantité de bon aléa que l’on peut demander à un instant donné. Il doit donc être réservé strictement à des usages requérant un aléa fiable.

Or, la fonction getPseudoRandom fait appel à la même fonction interne openssl_random_pseudo_bytes que getStrongRandom, ce qui veut dire qu’elle consomme de l’aléa précieux alors que ce n’est pas nécessaire.

Cette fonction getPseudoRandom va être modifiée pour générer un aléa correct mais non fiable à partir de la date/heure et une préparation via une ou plusieurs fonctions de hachage. Elle ne devra en aucun cas être utilisée comme source pour générer des mots de passes de session ou de protection des objets, etc… nécessitant un aléa de qualité cryptographique.

Renforcement de la lecture des objets – taille limite

Lundi, novembre 21st, 2016

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

Samedi, novembre 19th, 2016

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

Vendredi, novembre 18th, 2016

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

Jeudi, novembre 17th, 2016

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…

bootstrap – pré-chargement des applications

Mardi, octobre 11th, 2016

Suite à la Reprise du bootstrap en programmation procédurale, le code à été en très grande partie revu.

La version en programmation procédurale est maintenant utilisée par défaut. La version en programmation orientée objet est laissée en l’état, elle n’est plus fonctionnelle.

Le nouveau bootstrap est pleinement fonctionnel à l’exception de la partie de premier chargement lorsque l’on installe une nouvelle instance de serveur.

Contrairement à avant, les applications et la librairie sont pré-chargés lors du premier lancement de l’application. Cela se passe dans une page dédiée qui une fois l’application en mémoire fait un rechargement de la page. Au rechargement, on est dans l’application. La page de pré-chargement peut être un peu longue comme dans la capture d’écran plus bas mais sur des machines récentes elle passera en moins d’une seconde.
Surtout, cette fonctionnalité qui paraît un peu cosmétique au premier abord va permettre de mieux gérer la sérialisation/désérialisation des différentes instances d’une application. C’est à dire qu’une fois le pré-chargement réalisé avec tous les calculs et parcours de liens effectués, le chargements suivants seront beaucoup plus rapides.

Le travail sur le pré-chargement a contraint la remise à plat des fonctions liées à l’instanciation et à la sérialisation/désérialisation des différentes classes des applications. Cela a été l’occasion de faire le ménage aussi; De fait, les applications ne sont plus compatibles avec les anciennes version du bootstrap.

Voici donc à quoi ressemble le bootstrap lorsqu’il est interrompu par l’utilisateur ou si il y a une erreur :

020161011 - bootstrap_-_2016-10-11_22.11.40
Page du bootstrap interrompu sur initiative de l’utilisateur.

Et enfin, voici à quoi ressemble la page de pré-chargement des applications :

020161011 - bootstrap_-_2016-10-11_22.10.53
Page de pré-chargement de l’application sylabe.

Reprise du bootstrap en programmation procédurale

Samedi, octobre 8th, 2016

Depuis une semaine, le code du bootstrap en PHP procédural est en cours de refonte complète. La base utilisée était assez ancienne, elle datait d’avant le passage à la programmation orientée objet.

Ce travail correspond presque à une ré-écriture de zéro du bootstrap. L’inconvénient de cette version c’est qu’il sera pls difficile d’utiliser la librairie nebule sur autre chose qu’un système de fichier, par exemple une base de données. Mais le gros avantage c’est que la maintenance de la librairie est fortement simplifiée par rapport à sa version orientée objet. En effet le bootstrap nécessite quelques ajustements et notamment la désactivation de certaines fonctionnalitées. Ce serait trop compliqué de garder deux librairies orientées objets en parrallèle.

Cette nouvelle version introduit cependant quelques nouveautées :

  • Le changement de puppetmaster est complètement fonctionnel.
  • La version de librairie utilisée avec une application est mémorisée pour cette application (le temps de la session PHP) jusqu’à demande d’activation des mises à jours ou fermeture de la session par l’utilisateur.
  • En plus de l’instance de l’applicaiton proprement dite, on mémorise aussi dans la session PHP les instances des classes d’affichage Display, d’action Action et de traduction Translate pour gagner en performance.

La page du bootstrap est en cours de mise à jour pour suivre cette évolution.

C’est cette version qui sera désormés utilisé pour les nouvelles versions des applications.

Ajout d’émotions sur des objets – suite 5

Dimanche, septembre 18th, 2016

Suite des articles sur l’Ajout d’émotions sur des objets et suites 1 2 3 4, et Liens d’émotions.

Les émotions sont une façon de marque un objet avec les sentiments qu’il inspire à un être humain. Les émotions sont plutôt subjectives là où les avis sont beaucoup plus objectifs. L’intensité que l’on peut donner à une émotion est toujours strictement positive, le sens positif ou négatif est déjà porté par l’émotion elle-même.

Les émotions étaient fonctionnelles sur les objets dans la version 2014 de sylabe. Mais le code ayant été entièrement repris en php orienté objet elles n’avaient pas encore été ré-implémentées. Le nécessaire est en cours de remise en place directement dans la librairie afin que les émotions sur les objets soient utilisables dans toutes les applications.

Les avis ne sont pas maintenus.

En parallèle, la réflexion à long terme continue sur la pondération des objets en vue de leur suppression automatique au bout d’une certain temps. C’est la fonction d’oublie. Il faut que cette pondération soit aisée à utiliser, et surtout qu’elle ait du sens pour que l’utilisateur prenne le temps de le faire. Il est clair qu’un champs de quantification de l’importance d’un objet est difficile à appréhender et ne sera pas utilisé. La gestion des émotions devient en fait la solution évidente de pondération. De plus, la pondération d’un objet, qui représente en fait son importance, peut influencer et être influencée par l’importance des objets qui lui sont liés.
Sans pondération, la gestion de l’oublie sera chaotique et peu fiable, donc pas utilisée.

La facilité d’usage et la pertinence de la solution de gestion des émotions et leurs pondérations sont donc déterminantes pour leur adoption et leur utilisation mais aussi plus tard pour la gestion de l’oublie.

Il y a plusieurs façons d’aborder la pondération avec les émotions. (suite…)

Version 020160830

Mercredi, août 31st, 2016

Une nouvelle version 020160830 est publiée. Les changements étant assez profonds par rapport à la précédente version publiée, elle va subir une phase de test. Il n’est pas possible de mettre à jour une instance de serveur existante sans remplacer le bootstrap, c’est à dire le fichier index.php. Les sites web des applications sylabe et klicty seront mis à niveau progressivement plus tard.

La nouvelle version est diffusée pour l’instant sous forme d’une nouvelle installation d’instance de serveur.
Elle est disponible ici : 6b48a8ced09ef7ede2da001d8bf10a6fe5ad9d586ca1f1856eeec9fbc8ad4688

La procédure d’installation va être créée pour avoir quelque chose de complètement fonctionnel. Jusque là la procédure d’installation ne concernait que sylabe.

Les nouvelles applications option, upload et defolt sont disponibles à partir de cette version.

Les options sont maintenant en grande partie nébulisées dans la librairie, c’est à dire gérées par des liens. Le fichier nebule.env reste mais va permettre de figer les options que l’on ne voudra pas voir modifiée par les liens.

Bootstrap procédural

Samedi, juillet 9th, 2016

Les instances du bootstrap ont été détachées des applications actuelles. Elles ne servaient que pour l’affichage optionnel de la métrologie.

L’idée est à terme de revenir sur un bootstrap en programmation procédurale et non orientée objet. Les besoins du bootstrap sont beaucoup plus restreints que ceux des applications et il est difficile aujourd’hui de faire un export réduit de la librairie nebule juste pour le bootstrap. La maintenance sera facilité.

Le portage devrait reprendre le code originel du bootstrap en procédural.

Nouvelles applications

Samedi, juillet 9th, 2016

La librairie nebule s’étoffe un peu plus au point de devenir un « framework » qui facilite grandement le déploiement de nouvelles applications. Les applications (classe Application) ont une classe abstraite parente avec tout un tas de fonctions disponibles. Idem pour les classes Display, Action et Translate des applications. Ces fonctions peuvent être directement utilisées ou surchargées si besoin.

Le développement de l’application messae est en attente de stabilisation de la librairie pour pouvoir être lancée.

Une base d’application a été ajouté à la page Applications.

Intégration des groupes dans la librairie php

Lundi, février 1st, 2016

Suite à la définition des groupes, l’intégration a commencé dans la librairie php orienté objet.

L’intégration est profonde puisque les groupes sont gérés comme des objets spécifiques comme c’était déjà le cas pour les entités. Une classe dédiée ainsi que tout un tas de fonctions leurs sont dédiés et personnalisés.

Les applications sylabe et klicty vont intégrer progressivement les groupes, notamment dans un module adapté.

Dans le même temps, un groupe fermé étant uniquement constitué de liens d’une seule entité (et cela doit être vérifié), le filtre social est en cours de mise en place. Ainsi, il est possible de restreindre la prise en compte des liens suivant ces filtres sociaux :

  • self : liens de l’entité ;
  • strict : liens de l’entité et des entités autorités locales ;
  • all : toutes les entités, mais avec un classement par pondération des entités.

L’activation du filtre social et donc de la possibilité de le choisir dans le code à nécessité un revue de tout le code de la librairie et des applications. Il reste à vérifier les modules de sylabe.

Historique des liens générés

Dimanche, novembre 8th, 2015

Il y avait dans la librairie nebule en php procédural une option permettant de copier au moment de leur écriture les nouveaux liens générés. C’est une forme d’historique qui vient en complément de la possibilité d’écriture des nouveaux liens signés dans les liens de l’entité signataire. Par défaut tout arrivait dans le fichier l/f qu’il fallait bien sûr penser à vider de temps en temps.

Mais cela n’avait pas été ré-implémenté. C’est maintenant fait dans la librairie en php orienté objet. L’option permitHistoryLinksSign permet d’activer cette fonctionnalité et est par défaut à false, soit désactivé.

C’est utile pour le développement puisqu’il suffit de récupérer les derniers liens des programmes en cours de développement pour les faire signer par une autorité de code (bachue). C’est plus facile que d’aller faire la pêche aux liens sur les différents objets concernés.

Dissimulation de liens, multi-entités et anonymat

Samedi, juin 27th, 2015

La dissimulation de lien tel que prévu dans nebule n’est que la première partie permettant l’anonymisation des échanges entre entités.

Voir les articles précédents :
Liaison secrète et suite ;
Nouvelle version v1.2, Anonymisation de lien et correction du registre ;
Lien de type c, précisions ;
Entités multiples, gestion, relations et anonymat et Entité multiples ;
Nébuleuse sociétale et confiance – Chiffrement par défaut

Cette dissimulation d’un lien se fait avec un lien de type c. On a bien sûr dans le registre du lien visible l’entité qui génère ce lien, l’entité signataire. Et on a l’entité destinataire qui peut déchiffrer ce lien dissimulé et en extraire le vrai lien. Et comme dans la version publique de ce lien on a à la fois l’entité source et l’entité destinataire qui sont visibles, il n’y a pas d’anonymat. Ce type de lien permet juste de dissimuler l’usage d’un objet.

2015.06.27 lien c

Un lien dissimulé ne peut pas contenir un autre lien dissimulé. On interdit donc les multi-niveaux de liens dissimulés qui seraient un véritable calvaire à traiter.

Un lien peut être dissimulé pour soi-même. C’est à dire que l’entité signataire est aussi l’entité destinataire.

Si un lien doit être dissimulé pour plusieurs destinataires, il faut générer un lien pour chaque destinataire. La seule façon de réduire le nombre de liens pour un grand nombre de destinataires est d’utiliser la notion de groupe disposant de son propre bi-clé. Ce type de groupe est pour l’instant purement théorique.

Ce maintien comme public des entités sources et destinataires est une nécessité au niveau du lien, c’est une des bases de la confiance dans les liens. Pour que le lien puisse être validé et accepté par une entité ou retransmit par un relais, l’identification des entités est incontournable. Et donc avec l’identification nous avons aussi l’imputabilité et la non répudiation.

Si on veut assurer de l’anonymat pour les entités, puisque l’on ne peut pas travailler au niveau du lien, il faut travailler au niveau de l’entitié. On va dans ce cas travailler sur la notion de déception, c’est à dire faire apparaître des entités pour ce qu’elles ne sont pas ou tromper sur la nature des entités.
L’idée retenu consiste, pour chaque entité qui souhaite anonymiser ses échanges avec une autre entité, à générer une entité esclave avec laquelle elle n’a aucun lien. Ou plutôt, le lien d’entité maîtresse à entité esclave est un lien dissimulé pour l’entité maîtresse uniquement. Ici, personne à par l’entité maîtresse ne peut affirmer juste sur les liens que l’entité esclave lui est reliée.
Lorsque l’on veut échanger de façon anonyme, on transmet à l’entité destinataire l’identifiant de l’entité esclave, et vice versa. Cette transmission doit bien sûr être faîte par un autre moyen de communication ou au pire par un seul lien dissimulé.

L’anonymisation complète est donc la combinaison des liens de dissimulation de liens et d’une capacité multi-entités des programmes.

La dissimulation est en cours d’implémentation dans sylabe en programmation php orienté objet. Mais le plus gros du travail sera à faire dans la librairie nebule puisque c’est elle qui manipulera les liens et présentera ceux-ci à l’application, c’est à dire sylabe, dans une forme exploitable. L’application n’a pas à se soucier de savoir si le lien est dissimulé, elle peut le lire ou elle ne peut pas. Tout au plus peut-elle afficher qu’un lien est dissimulé pour information de l’utilisateur.
La capacité multi-entités de sylabe est maintenant beaucoup plus facile à gérer en programmation php orienté objet. Mais il reste à implémenter la génération des entités esclaves avec dissimulation de leur entité maîtresse.

Une autre dimension n’est pas prise en compte ici, c’est le trafic entre les serveurs pour les échanges d’informations. Il faudra faire attention à la remontée possible aux entités maîtresses par leurs échanges.

Enfin, pour terminer, aujourd’hui c’est la course au chiffrement par défaut de tous les échanges pour tout un tas de programmes et services sur Internet. Ce chiffrement par défaut est bon pour l’utilisateur en général. Et il masque dans la masse les échanges pour qui la confidentialité est critique. Ainsi il ne suffit plus d’écouter le trafic chiffré pour retrouver ses ennemis.
Mais cette logique est perverse. Le chiffrement par défaut est une aberration, un remède de cheval posé en urgence faut de mieux. Nous avons besoin d’échanger aussi des choses publiquement, comme sur un forum ou dans la presse. Nous ne devrions pas avoir des outils de communication tout chiffré et d’autres tout public, chaque outil devrait permettre les deux et clairement indiqué ce qui est protégé de ce qui ne l’est pas…

Authentification et mot de passe

Samedi, février 14th, 2015

Dans la version précédente, procédurale, de la librairie nebule en php, l’authentification était gérée via des variables de la session. On retrouvait l’ID de l’entité en cours ainsi que l’ID de la clé privée associée et le mot de passe (si déverrouillé) de cette clé privée.

Les anciennes variables :
$_SESSION['nebule_publ_entite']
$_SESSION['nebule_priv_entite']
$_SESSION['nebule_pass_entite']

Dans la nouvelle version de la librairie, en programmation orientée objet, la première variable qui référence l’entité en cours d’utilisation est toujours nécessaire.
Par contre, la variable qui référence la clé privée est encore utilisé mais n’est déjà plus vraiment indispensable puisque l’instance (l’objet au sens programmation) de l’entité contient la référence à l’ID de sa clé privée. Cet ID de clé privée est pré-calculée lors de l’initialisation de l’instance et est accessible par une fonction publique. Il est même possible que cette variable de session pour la clé privée disparaisse à terme faute d’usage.
Enfin, la variable contenant le mot de passe de la clé privée, elle, disparaît définitivement. Elle n’était renseignées que lorsque l’entité était déverrouillées. Désormès, le mot de passe, lorsque fourni, est stocké dans l’instance de l’entité en cours. Cette instance référence ainsi la clé privée et le mot de passe associé. Ce mot de passe est bien sûr vérifié lors de son enregistrement puisque c’est la seule et unique condition pour considérer l’entité comme déverrouillée, que le mot de passe soit valide sur la clé privée.

En terme de sécurité du code, c’est plus propre. Le mot de passe ne peut être consulté directement par un module malveillant comme avec une variable de session par essence globale et donc accessible partout. Cependant, le mécanisme n’est pas parfait puisqu’une lecture brute de l’instance permet d’en extraire le contenu… et donc le mot de passe. Il faudra trouver un mécanisme pour renforcer ça…
L’usage d’un sel pour le mot de passe est en cours de réflexion sachant qu’il faudra dans ce cas créer un lien pour le rendre publique. C’est un renforcement de la sécurité du mot de passe mais potentiellement une source de panne.

En terme de gestion des entités, c’est plus facile si on change vers une entité que l’on maîtrise puisque les mots de passe des entités esclaves sont accessibles et peuvent être pré-injectés dans les entités correspondantes. Et puis en cas de bascule vers une de ces entités esclaves, le retour à l’entité maîtresse est plus facile aussi puisque le mot de passe pourra rester dans celle-ci.

En terme d’évolution, il est déjà prévisible qu’une forme avancée d’un usage multi-entité verra le jour. CF Entités multiples. La pré-initialisation des mots de passes de toutes les entités sous contrôle (entités esclaves) rendra cet usage beaucoup plus facile. Pour rappel, cet usage multi-entité permettra au choix soit d’utiliser une et une seule entité à un instant donné mais de pouvoir immédiatement et facilement changer d’entité, soit d’utiliser simultanément tout ou partie des entités sous contrôle. Dans ce dernier cas, les actions seront par contre faites avec une seule entité pré-definie pour cela.

Voici la structure de la classe Entity :

class Entity extends Object
{
	const ENTITY_MAX_SIZE = 16000;
	const ENTITY_PASSWORD_SALT_SIZE = 128;
	const ENTITY_TYPE = 'application/x-pem-file';

	private $_publicKey = '';
	private $_privateKeyID;
	private $_privateKey = '';
	private $_privateKeyPassword;
	private $_privateKeyPasswordSalt;
	private $_issetPrivateKeyPassword = false;
	private $_faceCache = array();

	public function __construct(nebule $nebuleInstance, $id);
	public function __destruct();
	public function __toString();
	private function _loadEntity($id);
	private function _createNewEntity();
	private function _verifyEntity($entity);
	public function getType();
	public function getKeyType();
	public function getPublicKeyID();
	public function getPublicKey();
	private function _findPublicKey();
	public function getPrivateKeyID();
	private function _findPrivateKeyID();
	private function _findPrivateKey();
	public function setPrivateKeyPassword($passwd);
	public function unsetPrivateKeyPassword();
	public function checkPrivateKeyPassword();
	public function changePrivateKeyPassword($newpasswd);
	public function getFullName();
	public function getLocalisations();
	public function getLocalisation();
	public function getFaceID($size=400);
}

Avancement

Dimanche, novembre 16th, 2014

Maintenant, la librairie et le programme par défaut sont chargés par le bootstrap depuis des objets. On revient à la situation d’origine avant le passage à la programmation orienté objet.

Avancement

Dimanche, novembre 16th, 2014

La remise en place des fonctions de la librairie nebule en php orienté objet ainsi que la ré-écriture du bootstrap pour en profiter reprend pleinement.

La résolution du graphe des mises à jours des objets, c’est à dire le suivi des liens de mises à jours, est fonctionnelle. On peut donc maintenant rechercher la dernière version de la librairie ainsi que la dernière version du programme à charger par défaut.
La librairie ayant le minimum fonctionnel pour le bootstrap, elle y a été intégralement copiée. Plus tard, elle sera allégée des fonctions non utilisées. La librairie étant plus modulable, les modules non nécessaires au bootstrap ne seront simplement pas intégrés.

La cible : faire charger la librairie par le bootstrap et le programme par défaut.

Le programme sylabe est fonctionnel sur la librairie actuelle moyennant la conservation des fonctions procédurales. Ces anciennes fonctions seront progressivement transformées pour utiliser les nouvelles fonctions en programmation orienté objet… et/ou supprimées dès que sylabe aura été mis lui aussi à jour. En attendant, il intègre en bas de page les nouveaux compteurs du nouveau bootstrap.

nebule_bootstrap_-_Experimental_-_2014-11-16_10.21.26

Avancement

Vendredi, octobre 10th, 2014

La ré-implémentation de la librairie en php orienté objet avance.

Un gros point de blocage vient de sauter. Il s’agissait d’implémenter la résolution d’un graphe de liens de mises à jours. L’implémentation précédente fonctionnait bien mais nécessitait une sous fonction qui s’appelait elle-même au fur et à mesure du parcours des liens u. Ici, il fallait forcément implémenter une fonction de recherche des mises à jours sur un niveau pour un objet. Mais en contre-partie, et moyennant un fonctionnement plus complexe, il a été possible de ne plus utiliser la sous-fonction auto-appelée…
Bref, c’est plus complexe à comprendre mais c’est aussi plus propre :-)

Voici le genre de chemin suivi pour la résolution du graphe de mise à jour d’un objet. Ici le cheminement est linéaire entre les objets intermédiaires, il devra être éprouvé sur un cheminement non linéaire (avec des objets manquants).
On part de l’objet 47c1b111409c3a9ccb193b19c481b38715f9fc96da706d98c070ef9019890cb9 et on arrive à 672bad4d2c4bd4a5def227671a0eb22844dbb116d59d4cb948ecbaa4f6b0b549 (sur une base de liens plus réduite):

2013-12-06_u_47c1b111409c3a9ccb193b19c481b38715f9fc96da706d98c070ef9019890cb9_5376cfdb8b8d3e1c9c4832bb9d8cab0ba076bbf2d28ae53c8680088641d2aa85
2013-12-07_u_5376cfdb8b8d3e1c9c4832bb9d8cab0ba076bbf2d28ae53c8680088641d2aa85_e2e0fec866c726f3b284575435a81080f279e4afb46a7ba07edc39105f061a7f
2013-12-10_u_e2e0fec866c726f3b284575435a81080f279e4afb46a7ba07edc39105f061a7f_9864740a3679164edfc130ba64658926470227e6a94056ce200a1157f729a940
2013-12-11_u_9864740a3679164edfc130ba64658926470227e6a94056ce200a1157f729a940_aafc618df11870db1c833a6f0e31e8c4246645001b515040ee7d84cde135e617
2013-12-12_u_aafc618df11870db1c833a6f0e31e8c4246645001b515040ee7d84cde135e617_1e45b26a70a8f19e3515d981100fc7a135b6b6e480bb170d41d2033120a02fec
2013-12-13_u_1e45b26a70a8f19e3515d981100fc7a135b6b6e480bb170d41d2033120a02fec_0a2d68d69eca2bd3b83ea0306bc868c4ee684e8eb1665e9215263ea05a54c426
2013-12-24_u_0a2d68d69eca2bd3b83ea0306bc868c4ee684e8eb1665e9215263ea05a54c426_284ea4d9be9b206d73297bda696c77ef3389c47330e5b1d4c13dcf3ab3c5d20d
2013-12-26_u_284ea4d9be9b206d73297bda696c77ef3389c47330e5b1d4c13dcf3ab3c5d20d_182b6e830ba6b21411695e9f99fddfddd12c0bee61fce41368c98e0c1254dab5
2014-01-02_u_182b6e830ba6b21411695e9f99fddfddd12c0bee61fce41368c98e0c1254dab5_e304bf8534de8b6fba8a88bcbbcd520439527a8719579c1db2d3465465e463a9
2014-01-10_u_e304bf8534de8b6fba8a88bcbbcd520439527a8719579c1db2d3465465e463a9_ab46a8ed5c21a2d8ff9103088a8cdc07ea167eb577b3cc4ac0ec29b4388c4b0c
2014-01-13_u_ab46a8ed5c21a2d8ff9103088a8cdc07ea167eb577b3cc4ac0ec29b4388c4b0c_79ddbdd834c136e4616b71372de11d786b4730ea040bd732b1d91e17b10398b0
2014-01-16_u_79ddbdd834c136e4616b71372de11d786b4730ea040bd732b1d91e17b10398b0_d6d226f89a247ef361ae1c0b0eb1c5383ea2ee7c1ee607255f84727b7da2c962
2014-01-17_u_d6d226f89a247ef361ae1c0b0eb1c5383ea2ee7c1ee607255f84727b7da2c962_59b802549352603e2cc9d386788bbfe0336045cc841b96bdb707f87f4d9d0bbd
2014-01-18_u_59b802549352603e2cc9d386788bbfe0336045cc841b96bdb707f87f4d9d0bbd_0131a0b7b758d24be4ecc6701fc942c8c73044f3fa85aa2e82fe42b5cfcf05d9
2014-01-22_u_0131a0b7b758d24be4ecc6701fc942c8c73044f3fa85aa2e82fe42b5cfcf05d9_dd27f522db318f7fcf54852af861e656b184bd178c9718c7186efcedda49dba2
2014-01-23_u_dd27f522db318f7fcf54852af861e656b184bd178c9718c7186efcedda49dba2_72ebbabbf4687106a70b5bba7f9c10ab096febd649f306660411f2cc6215981e
2014-01-24_u_72ebbabbf4687106a70b5bba7f9c10ab096febd649f306660411f2cc6215981e_b364e1bf7181fa508032d5d26562350be6aadbb14949137e8d442bdc1912493b
2014-01-29_u_b364e1bf7181fa508032d5d26562350be6aadbb14949137e8d442bdc1912493b_cc1ec77ea4d137b7785c2de9dab0d818420f520f3502788aec56e1ca3cb081ac
2014-01-30_u_cc1ec77ea4d137b7785c2de9dab0d818420f520f3502788aec56e1ca3cb081ac_c971f678bbfeba808c0f0b4f23f6d3f3bed21c098437ecfe54e0c46891696462
2014-01-31_u_c971f678bbfeba808c0f0b4f23f6d3f3bed21c098437ecfe54e0c46891696462_27ec39235f7f49f1a862ac303e54125cc2941455b832000957583130e08896eb
2014-02-02_u_27ec39235f7f49f1a862ac303e54125cc2941455b832000957583130e08896eb_c92173177ed98cfbb651a76670b3e508834bbb217ac91b285c8ab20994f5b249
2014-02-03_u_c92173177ed98cfbb651a76670b3e508834bbb217ac91b285c8ab20994f5b249_02ef13f3824b6412cbd38b9c33266a601b18a8812b84aff3fffb7647723b1883
2014-02-05_u_02ef13f3824b6412cbd38b9c33266a601b18a8812b84aff3fffb7647723b1883_60de6086e63a85db4a39ca06f1bccb966eaa3cb6d805889210a6cc63c5c59757
2014-02-06_u_60de6086e63a85db4a39ca06f1bccb966eaa3cb6d805889210a6cc63c5c59757_8334ed17bfe94db33690049ecae724b58e420478d62a902503bb95ab17e013ba
2014-02-07_u_8334ed17bfe94db33690049ecae724b58e420478d62a902503bb95ab17e013ba_a6e76573b865ca90fb92b247c724474456db38023b6b9716b45ef41c6742e164
2014-02-08_u_a6e76573b865ca90fb92b247c724474456db38023b6b9716b45ef41c6742e164_b8fb4e2a4fa515cc8ce6d130ab7cfcfa7138150d3117357514bfb5d868a726c4
2014-02-09_u_b8fb4e2a4fa515cc8ce6d130ab7cfcfa7138150d3117357514bfb5d868a726c4_b338bd787b97e6cd85ce9965b00d17a86d51255b87c8686d0444b6a87ea7f034
2014-02-10_u_b338bd787b97e6cd85ce9965b00d17a86d51255b87c8686d0444b6a87ea7f034_d4115805c826483a0a5f6988be4fcc4bac8b04d300cbb3c8f0244194777931f9
2014-02-12_u_d4115805c826483a0a5f6988be4fcc4bac8b04d300cbb3c8f0244194777931f9_221ec95e1046265b03dc8800a7efed44df5e49b6db3b9f51048370009022698d
2014-02-13_u_221ec95e1046265b03dc8800a7efed44df5e49b6db3b9f51048370009022698d_b80e64fc316768932fab063b35d47e3651eed66be7ca8756d2cb0bc82afbd683
2014-02-16_u_b80e64fc316768932fab063b35d47e3651eed66be7ca8756d2cb0bc82afbd683_76e3f1f5d64a221bf1a28964ae74f9752af3b26763b46523ea3b5e6a2a20511a
2014-02-17_u_76e3f1f5d64a221bf1a28964ae74f9752af3b26763b46523ea3b5e6a2a20511a_d1fd4dba3ec0ec7fda4898a16eac6593d10e80cb575511fd9cbe85ec214e487f
2014-02-18_u_d1fd4dba3ec0ec7fda4898a16eac6593d10e80cb575511fd9cbe85ec214e487f_fbf7bcc5c27981b8953e2a8630f572774f6c16684ac8459bb240aeaca8bd8ff7
2014-02-20_u_fbf7bcc5c27981b8953e2a8630f572774f6c16684ac8459bb240aeaca8bd8ff7_8badc8ba4a855acbbe58de48e5ac3fa4aeb3c3c69858401778adf771ed19be15
2014-02-21_u_8badc8ba4a855acbbe58de48e5ac3fa4aeb3c3c69858401778adf771ed19be15_f05b4ac2d53b7287af3f15c3ab2e7da13fc3a80b37272cbbcfb400d287568f63
2014-02-22_u_f05b4ac2d53b7287af3f15c3ab2e7da13fc3a80b37272cbbcfb400d287568f63_761625eb463d1e3930b80cf88d43157d778d10a23f3d0cba463c552322492b72
2014-02-24_u_761625eb463d1e3930b80cf88d43157d778d10a23f3d0cba463c552322492b72_941752dc44b4a272bd7828724f7f3bd554fa1f3acca4dcb298f0ecf5428ecfbf
2014-02-25_u_941752dc44b4a272bd7828724f7f3bd554fa1f3acca4dcb298f0ecf5428ecfbf_a3d7fcf4f1c88ce5350f065e16ce770cc6d6de6334e7fb6dd8403398c86ea1e5
2014-02-26_u_a3d7fcf4f1c88ce5350f065e16ce770cc6d6de6334e7fb6dd8403398c86ea1e5_1f3e1cec5ab724a701d7665f13003dc50765c3a066227d322d64804651de0ade
2014-02-27_u_1f3e1cec5ab724a701d7665f13003dc50765c3a066227d322d64804651de0ade_5154aa3a5ea8956db2279dbaa2d3944b5a87218202e838c2a4cfc27da172ed6e
2014-03-04_u_5154aa3a5ea8956db2279dbaa2d3944b5a87218202e838c2a4cfc27da172ed6e_0a65036105b001b926d1d0336aa4de5fde1d8a476f325f9832e524d914e7e465
2014-03-26_u_0a65036105b001b926d1d0336aa4de5fde1d8a476f325f9832e524d914e7e465_5ac97a3a3c7c310b5afe24c210874c1b2ae69a80274755117cb7b8bb3b9299be
2014-03-28_u_5ac97a3a3c7c310b5afe24c210874c1b2ae69a80274755117cb7b8bb3b9299be_17bf49d31d9a2ab2d0d051ed1bb4c6a0acdfcad6da199fc86ebf47d8be284f40
2014-03-29_u_17bf49d31d9a2ab2d0d051ed1bb4c6a0acdfcad6da199fc86ebf47d8be284f40_9559ba4972cd3a4ada0d055101efdca7d6c0f942279c6bd05f23b2d0b118c111
2014-04-01_u_9559ba4972cd3a4ada0d055101efdca7d6c0f942279c6bd05f23b2d0b118c111_a6968f3bb36ea04264f6e2314c661af3f4acda829a4515b73b701aea244b1582
2014-04-02_u_a6968f3bb36ea04264f6e2314c661af3f4acda829a4515b73b701aea244b1582_f74debe6a24400c6dbbb4388eefac050d204b5073f643a3302c24fc15e7544c6
2014-04-03_u_f74debe6a24400c6dbbb4388eefac050d204b5073f643a3302c24fc15e7544c6_f6d07dd9f4e946bab71f1084d027f6b9cc16d7161e62cc4562e0bd94cce502d7
2014-04-04_u_f6d07dd9f4e946bab71f1084d027f6b9cc16d7161e62cc4562e0bd94cce502d7_c8dbec0f85e19c313317f552e7acfaa2a23097150e592da400643d4c18884b94
2014-04-08_u_c8dbec0f85e19c313317f552e7acfaa2a23097150e592da400643d4c18884b94_28ae03264ae8505767aa5e3a3cbaf7d0a8a96c92236de5a10c14d694c498438a
2014-04-09_u_28ae03264ae8505767aa5e3a3cbaf7d0a8a96c92236de5a10c14d694c498438a_33ae1c2aa592fb7ac7f95f03abfd5a6b46d4da48579a3153258890298336a01a
2014-04-10_u_33ae1c2aa592fb7ac7f95f03abfd5a6b46d4da48579a3153258890298336a01a_648f35156e67da0bdd9477020129c42e9ed07ac4f67e784f0f0cd931b1b4419c
2014-04-11_u_648f35156e67da0bdd9477020129c42e9ed07ac4f67e784f0f0cd931b1b4419c_907e5d86dec334e80a5e81d4e0b842bbeb0b491c7bba38699da25aa880ac49b8
2014-04-12_u_907e5d86dec334e80a5e81d4e0b842bbeb0b491c7bba38699da25aa880ac49b8_672bad4d2c4bd4a5def227671a0eb22844dbb116d59d4cb948ecbaa4f6b0b549

Gestion des modules – IO et gros objets

Dimanche, août 31st, 2014

Suite de l’article Gestion des modules.

L’exportation du traitement des IO dans des modules entraîne un autre problème avec les gros objets.

Les gros objets peuvent être visualisés dans le navigateur quoi qu’il arrive puisque la lecture du contenu d’un objet est faite par le navigateur et ce contenu est transmis sans traitement par le serveur web. Ce quelque soit la taille de l’objet.
Par contre, si un objet nécessite un traitement, comme le déchiffrement, alors cela ne marche plus de la même façon.

Le traitement d’un objet nécessite qu’il soit placé en mémoire de l’instance PHP en cours, avec toutes les restrictions et limites que l’on va rencontrer. Il n’est pas possible de travailler facilement comme on le ferait sur bash avec une série de ‘pipes’.

Ce problème va aussi se poser lors de la synchronisation d’un objet sur une serveur web externe, via le module IO HTTP. Avant de pouvoir l’écrire localement, via le module IO FileSystem par exemple, il devra tenir en mémoire.
Il est peut-être possible, dans le das d’échanges entre IO, de mettre en place des copies progressives d’objets pour soulager la mémoire. A voir…

Pour le déchiffrement et l’affichage, il est possible de créer une fonction spécifique. Pour le chiffrement, il va falloir travailler par blocs.