Archive for the ‘empreinte’ Category

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…

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

Mardi, octobre 21st, 2014

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

Vendredi, juillet 11th, 2014

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

Vendredi, janvier 17th, 2014

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

Jeudi, octobre 4th, 2012

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

Samedi, septembre 29th, 2012

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?

Mercredi, septembre 26th, 2012

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.

(suite…)

OpenSSL plutôt que GPG!

Mercredi, septembre 12th, 2012

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.

(suite…)

GPG ou OpenSSL?

Mercredi, septembre 12th, 2012

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… (suite…)

Collisions d’empreintes multi-algorithmique

Vendredi, septembre 7th, 2012

On peut utiliser de multiples algorithmes pour calculer l’empreinte des objets. Certains algorithmes sont plus résistants, plus fiables ou plus sûrs que d’autres. Cette résistance est représenté par l’impossibilité (relative) d’inverser la fonction algorithmique, c’est à dire de retrouver l’objet source à partir de l’empreinte. Il en découle l’impossibilité (relative aussi) de calculer une collision dans les empreintes entre deux objets, c’est à dire de calculer un objet qui a une empreinte précise, par exemple la même empreinte qu’un autre objet pré-existant. Ces impossibilités sont relatives parce qu’il sera toujours possible dans le pire des cas (pour l’attaquant) de tester toutes les combinaisons possible afin de trouver une collision, mais cela lui prendra un temps tel que c’est jugé équivalent à impossible dans l’état actuel de nos connaissances mathématiques et de nos moyens informatiques.

Première conclusion, inutile de s’attarder sur des algorithmes de prise d’empreinte triviales comme CRC qui n’ont pour vocation que de permettre une vérification extrêmement rapide de données transmises (par exemple sur la couche TCP sur IP). Ces algorithmes ne sont pas prévus pour résister aux collisions volontaires.

Seconde conclusion, rappel de principes de base en sécurité informatique, on ne doit pas utiliser des algorithmes qui sont reconnus non fiables ou pour lesquels on est sur le point de réussir des collisions. Exit donc MD5, SHA0 et SHA1 par exemple.

Jusque là, on reste en territoire connu. SHA256 est encore aujourd’hui reconnu comme sûr et ne semble pas présenter de faiblesse à moyen terme. Il peut servir sans risque intrinsèque aux premières expériences nécessitant un bon niveau de sécurité. D’autres algorithmes connus sont susceptibles d’être utilisés dans un futur proche.

Mais que ce passe-t-il si on mélange plusieurs algorithmes différents pour le calcul d’empreinte ?
Ne risque-t-on pas d’affaiblir non pas les algorithmes mais le système dans son ensemble ?

En présentant un objets sous différentes empreintes générées par des algorithmes différents, ne risque-t-on pas d’affaiblir un ou plusieurs algorithmes ?

De façon plus générale, si une faille importante est découverte dans un algorithme et que celui-ci n’est plus jugé sûr, quelles conséquences pour l’ensemble du système ?

Empreinte d’objets et URI

Samedi, mars 31st, 2012

L’Uniform Resource Identifier (URI) est une chaîne de caractères permettant l’identification d’un objet de façon univoque et permanente.

URI(Wikipedia – Licence CC BY-SA v3.0)

L’empreinte d’un objet réalisée au moyen d’une fonction de hash cryptographique est un URI.

(suite…)

Durée de vie des HASHoires

Mercredi, juin 22nd, 2011

Un lien synthétise les fin de vie de différentes fonctions de Hash :
http://valerieaurora.org/hash.html

(suite…)

Réflexion – Et l’anti-virus alors?

Jeudi, décembre 9th, 2010

Si on part du principe que les objets sont référencés par leurs empreintes (MD5 par exemple) et les entités par leurs bi-clés, comment évolue un virus dans un tel environnement? Comment s’en protéger? (suite…)

Partager !…

Dimanche, novembre 7th, 2010

Démonstration d’une petite fuite d’information, jolie à voir quand même ;-)

Imaginez quelques photographies d’un studio prestigieux disponibles sur internet en haute définition. De quoi en faire des agrandissements de qualités. Le tout retrouvé sur le moteur de recherche Google avec juste un mot : Harcourt

(suite…)