Mois : septembre 2012

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?

Premier lien entre deux entités

Pour les besoins de l’expérience 4, les deux entités suivantes ont été liées :
– 975571a8a470a6d975662e284f5ef1bd0396c06b31a2207b81bef2e24c5bf0c5
– bca2c25e6564af173a65bf88b8bb1f91cb9c4f5e9ddaf96b8775206543be56c8

La première entité est gérée par un humain, la seconde par un robot. Ce robot à besoin de savoir à quel endroit il peut télécharger les objets et liens de l’autre entité.

Continuer la lecture de Premier lien entre deux entités

NÅ“uds

Le nœud est la rencontre de plusieurs chemins convergents/divergents. Cette rencontre est matérialisé par une liaison forte entre ces différents chemins.

La nébuleuse des objets a besoin d’une architecture locale avec des points de convergence forts. Ce sont des nÅ“uds. Ils permettent d’architecturer, d’organiser les liens entres objets, et donc de canaliser les partages d’informations.

Implémentation de liens sécurisés

Une première implémentation en shell bash a été réalisée pour la lecture et l’écriture de lien sécurisés.

Ces liens sont dits sécurisés parce qu’ils sont signés par une entité, et donc leur intégrité et leur provenance peuvent être vérifiés. Si la signature est invalide, ils sont simplement ignorés.

Voir l’implémentation de référence en bash.

Exemple de résultats (empreintes tronquées à 16 caractères) :
sha256:03e7785a6-975571a8a470a6d9-20120914182239-L-975571a8a470a6d9-970bdb5df1e79592-93d4a5f3ef1fc5c8
sha256:2ec7df2b9-975571a8a470a6d9-20120914182239-L-975571a8a470a6d9-7c512aaa1c5e3837-a6b4edb371e864e4
sha256:86d8d0f2f-975571a8a470a6d9-20120914182240-F-6a4b7f1100b87044-975571a8a470a6d9
sha256:2c7911d50-975571a8a470a6d9-20120914182240-L-975571a8a470a6d9-37d22e047bd0173f-703c4a9a2573f76a
sha256:90952b31d-975571a8a470a6d9-20120914182241-L-975571a8a470a6d9-69eb5187e4469dfd-93d4a5f3ef1fc5c8
sha256:3ed5b8f4c-975571a8a470a6d9-20120914182242-L-975571a8a470a6d9-6bf6ae23819cd0d1-0e87632cd46bd490
sha256:0626480c2-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-4b9a7f50c0bb198c-911f9ec89c20f340
sha256:51b955e0b-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-3514acf61732f662-5ef523ac47dae4aa
sha256:01bcc6d09-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-8527a891e2241369-b5977b836b445eaf
sha256:58a62c5ab-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-4ec9599fc203d176-dc80905e9df6dac2
sha256:bf51f9067-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-785f3ec7eb32f30b-28cdd20eaf134a05
sha256:553af0cc7-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-aea92132c4cbeb26-9d64d711a2a1123e
sha256:162bfc0c5-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-caa1aedb2a6ce96b-c0f059214d078968

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?

Tracé de graphes objets/liens, mise en pratique 4

Les couleurs sont cette fois-ci directement dépendantes des objets qu’elles représentes. Les 6 premiers chiffres hexadécimales sont directement utilisés comme code couleur RVB.

Manque toujours le réarrangement des objets.

Exemple pour l’objet d8f74db1ba545040eb60a52b477cdd55958cc518ed788d05db92a89b16efde07 (une entité) :


(Lien)

Continuer la lecture de Tracé de graphes objets/liens, mise en pratique 4

Collisions d’empreintes multi-algorithmique

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 ?

Localisation web

Chaque entité dispose par nature d’un identifiant unique, invariant et non cessible. C’est une clé cryptographique publique.

Cependant cet identifiant ne précise pas la place de l’entité, ou plutôt la place où on peut la joindre.
Les entités, pour pouvoir échanger, doivent avoir une place publique, c’est la localisation.

Cette place est-elle unique d’ailleurs?
En fait non, l’entité peut être présente en de multiples places, soit par le biais de relais, soit parce que la clé privé aura été volé et exploité.

Ce qui différencie fortement l’entité d’une ressource web classique, c’est que l’entité est unique quelque soit sa localisation, et n’existe pas uniquement du fait de l’existence du serveur web qui l’héberge. Cette entité survira à la disparition d’un serveur web, sa résilience est grandement amélioré et ne dépend que faiblement de sont environnement.

Continuer la lecture de Localisation web

Début de l’expérience 4

L’expérience 4 est lancée sans attendre la fin de l’expérience 3.

Introduction

Une des possibilités que permet le relai est de partager l’information via d’autres machines, un peu à la manière du P2P.

Mais c’est aussi un bon moyen de créer une sauvegarde d’objets, et de gérer ceux-ci.

Cette expérience vise à créer une base de relai automatisé.