Chiffrement et vecteur initial

Dans l’Introduction à la cryptographie, le vecteur initial (IV) était définie comme était égale à la clé de session. Bien sür, de fait, le vecteur initial n’était plus publiable comme on le fait habituellement.

Après consultation du fonctionnement du mode CTR (CounTeR), je me rends compte qu’il n’est peut-être pas opportun d’avoir l’IV identique à la clé de chiffrement. La première étape du chiffrement consiste en un ou exclusif (XOR) entre l’IV et la clé de chiffrement. Cela donne une clé pour ce tour égale à 0.
CF Wikipedia.org – Mode_d’opération (cryptographie).

Donc, un IV est ajouté. Il est lié à l’objet chiffré pour pouvoir déchiffrer celui-ci. Par défaut, sa valeur est aléatoire. Du fait du fonctionnement du mode CTR, l’IV s’incrémente à chaque bloc chiffré.

Si pas précisé, il est égale à 0.

Chiffrement et compression

Il est préférable d’associer de la compression avec le chiffrement.

La compression des données déjà chiffrées est impossible, non que l’on ne puisse le faire, mais le gain de compression sera nul. L’entropie détermine la limite théorique maximum vers laquelle un algorithme de compression sans pertes peut espérer compresser des données. Quelque soit l’entropie des données d’origine, une fois chiffrées leur entropie est maximal. Si un algorithme de compression arrive à compresser des données chiffrées, il faut sérieusement remettre en question la fiabilité de l’algorithme de chiffrement. CF Wikipedia – Entropie de Shannon.

A cause de l’entropie après chiffrement, si on veut compresser les données il est donc nécessaire de le faire avant le chiffrement.

Ensuite, il faut choisir l’algorithme de compression. On pourrait forcer par défaut cet algorithme, pour tout le monde. C’est notamment ce qui se passe pour le HTML5 avec le WebM ou le H.264… et c’est précisément ce qui pose problème. En dehors des problèmes de droits d’utilisation à s’acquitter, c’est une facilité pour l’implémentation de cette compression par défaut dans les programmes. Cela évite de devoir négocier préalablement l’algorithme de compression. Mais si il est difficile de présenter des vidéos en plusieurs formats à pré-négocier, ce n’est pas le cas de la plupart des données. On perd la capacité d’évolution que l’on a en acceptant de nouveaux algorithmes de compression. Et plus encore, on perd la capacité du choix de l’algorithme le plus adapté aux données à compresser.
Il faut donc permettre l’utilisation de différents algorithmes de compression.

Cependant, si l’objet à chiffrer est déjà compressé en interne, comme le PNG ou OGG par exemple, la compression avant chiffrement est inutile. Ce serait une sur compression qui bien souvent n’apporte rien. Le chiffrement n’implique donc pas automatiquement une compression.

Lors du chiffrement, l’objet résultant chiffré est lié à l’objet source non chiffré par un lien k. Il est aussi marqué comme étant un objet de type-mime correspondant à l’algorithme de chiffrement, via un lien l. CF Introduction à la cryptographie.
Pour marquer la compression avant chiffrement, un autre lien l est ajouté comme type-mime vers l’algorithme de compression utilisé. Ce lien n’est ajouté que dans le cas d’une compression réalisée en même temps que le chiffrement.

La seule contrainte, c’est l’obligation d’utiliser un algorithme de compression sans perte. L’objet, une fois décompressé doit être vérifiable par sa signature. Il doit donc être strictement identique, aucune modification ou perte n’est tolérée.

Le maître des poupées et le gardien de l’enfer

1/Le maître des poupées

Le maître des poupées, alias puppetmaster, vient de révoquer son ancienne incarnation :

63864e42204080051f524d5be0171920e0117a0e83d2131ac506ce3cbff7f1f4

Contrairement à ce qui avait été annoncé, c’est un lien de type d qui à été utilisé, et non un lien de type u. Ceci pour un problème de sécurité. Ainsi son ancienne incarnation ne peut pas révoquer ce type de lien… et ressusciter.
Le détail ici : puppetmaster.nebule.org/l/63864e42204080051f524d5be0171920e0117a0e83d2131ac506ce3cbff7f1f4

D’autres anciennes incarnations ont elles aussi été révoquées, à la fois pour la clé publique et la clé privée :
– 70668497b6a0ad481aa7e0c08131bc0d0be40cd7dde30a7de8613290d7c35543 puppetmaster (priv)
– 9e85d7d25af97760f8611b85c2765912606c7eec8307dc58c7782e34cc373c18 cerberus (pub)
– 905296b7070b8e7d601d9509893683d072bb22083006a9e545ceaf0228787c8c cerberus (priv)
– d756efe28847a3723639aed49a40f08c22a576ff3f002750a18ad6a192717621 kronos (pub)
– 5f951d41db3b18001fbc8baf895d84cb4d460a6143b273b4f5b2d0e9b0d5c67b kronos (priv)

Dans le même temps, puppetmaster a reconnu plusieurs nouvelles entités :
– 01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4 cerberus cerberus.nebule.org
– abdbaa31e404463ecc644f1eecdeb9b5f94428eb140fa5c66a7687ee96ed47aa kronos kronos.nebule.org
– 975571a8a470a6d975662e284f5ef1bd0396c06b31a2207b81bef2e24c5bf0c5 stéphane stephane.nebule.fr
Voir le détail ici : puppetmaster.nebule.org/l/88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

2/Le gardien de l’enfer

Le gardien de l’enfer, alias cerberus, vient d’être régénéré en tant que :

01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4
cerberus.nebule.org

Il est reconnu par puppetmaster. cf Cerberus et la mise en quarantaine d’objets.

Pour son rôle spécifique, il dispose de deux objets spécifiques :
– nebule/danger
– nebule/warning

Actuellement, les enfers n’ayant pas encore officiellement ouverts, cette entité est au chômage.
Seul le temps nous dira pour combien de temps…

Autorité temporaire : le maître des poupées

Une entité avait été généré en novembre 2012. Elle avait pour rôle de simuler une autorité de haut niveau. Voir l’article Autorité temporaire.

Le bi-clé de cette entité n’ayant pas été généré et manipulé dans des conditions spartiates de sécurité, il était difficile d’avoir pleinement confiance en cette entité.
Il fallait donc régénérer une nouvelle entité de façon plus propre.

Une machine a été installée de façon renforcée, et est prévue pour être manipulée hors réseau.
Tous les systèmes ont leurs faiblesses, et ont donc un besoin récurrent de mise à jour. Le système le moins vulnérable face à l’absence prolongée de mises à jours, c’est OpenBSD. C’est aussi actuellement le système le moins vulnérable par défaut. La non utilisation du réseau réduit très fortement les problèmes potentiels. Il est cependant possible, en cas de nécessité, de réaliser une mise à jour manuelle.
Le disque dur est partiellement chiffré.

Cette machine a donc permit de générer une nouvelle entité racine.
Ce rôle est toujours temporaire. Il ne se justifie que pour coller à un modèle de sécurité actuel, basé sur des autorités racines de confiance. On ne peut faire confiance à une entité que si elle est validée par l’entité racine. Cependant, ce modèle de sécurité n’a pas vocation à subsister en l’état. Soit il y aura d’autres autorités racines, soit elles disparaîtront toutes.

Puppetmaster, le nouveau maître des poupées est identifié comme :

88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

Et il reprend l’emplacement de l’ancien puppetmaster :

http://puppetmaster.nebule.org/

Pour l’instant, puppetmaster ne reconnaît aucune autre entité. Ce sera fait bientôt. Et le nouveau puppetmaster réformera (lien u) aussi officiellement l’ancien puppetmaster.
Le maître des poupées est mort, vive le maître des poupées!

OpenBSD echo off

Sous OpenBSD, c’est ksh par défaut et non bash.

Or la fonction read de ksh n’a pas d’option pour demander une saisie au clavier sans afficher ce que l’on tape, le retour clavier. C’est gênant pour la saisie d’un mot de passe par exemple. De son côté, la fonction read de bash l’accepte sous cette forme :

read -s -p "password" variable

Sous ksh, nous pouvons cependant préalablement désactiver le retour clavier, demander le mot de passe, et enfin réactiver le retour clavier. Comme ceci :

stty -echo
read variable
stty echo

Ca évite d’installer bash pour si peu…

Clé USB bootable chiffrée sous OpenBSD

Comment installer OpenBSD 5.2 sur une clé USB? Le rendre bootable? Et chiffrer le disque?

Je me suis basé sur ces deux tutoriels :

Il faut commencer par télécharger un CDROM d’installation (ici). Booter une machine sur le CD.

 La particularité, c’est d’utiliser sd0 comme disque d’amorçage et de chiffrer une partie de celui-ci. La partie chiffrée apparaît comme un second disque sd1 qu’il faut aussi partitionner. Comme sous Linux, une petite partie du système doit être présente non chiffrée pour pouvoir démarrer et demander le mot de passe qui ouvrira le disque chiffré. Cette partie non chiffrée, c’est la racine.

Il faut évidement derrière une machine capable de démarrer sur une clé USB.

La fin termine un peu abruptement. Continuer la lecture de Clé USB bootable chiffrée sous OpenBSD

Grandes migrations

Toutes les entités étaient accessibles via des liens en nebule.org .

Depuis une semaine, certaines entités ont changé de domaine. Les nouvelles localisations des entités concernées :

Les entités à usage publique restent dans le domaine nebule.org, c’est le cas de :

Ces localisations sont des domaines DNS, et de fait des serveurs http derrière. Cependant, la localisation est certes obligatoire pour retrouver une entité, mais elle n’est pas par nature strictement liée aux noms de domaines. Ni liée au réseau d’ailleurs. Certaines machines ne répondent pas à leur localisation (alpha.nebule.fr), et le type de localisation évoluera plus tard vers d’autres formes (ftp, smtp, xmpp, etc…).

Power and the Internet

Voici un essai intéressant publié par Mr Schneier sur son blog. Il y est question de l’évolution de l’Internet ainsi que des bouleversements qu’il introduit dans les rapports de forces entre les états (et pas que) et les administrés, c’est à dire le peuple. Toute évolution technologique introduit ce genre de bouleversement et c’est l’occasion de rendre le monde plus humain. Mais saurons-nous en profiter cette fois-ci ?

Je m’arrêterais sur la dernière remarque :
Either we fight for a seat at the table, or the future of the Internet becomes something that is done to us.
(Soit nous nous battons pour une place à la table, ou l’avenir de l’Internet deviendra quelque chose qui est fait pour nous à notre place.)

Liens :
– http://www.schneier.com/blog/archives/2013/01/power_and_the_i.html
– http://www.schneier.com

Ajout du 23/03/2013 :
– http://www.internetactu.net/2013/03/21/pouvoir-et-internet/
– http://www.framablog.org/index.php/post/2013/03/18/internet-etat-policier-surveillance
– http://www.technologyreview.com/view/512386/danger-lurks-in-growing-new-internet-nationalism/

Introduction à la cryptographie

Une avancée importante reste encore à faire. Elle est en théorie tout à fait réalisable et indispensable. Mais la mise en pratique doit se faire avec soin. Cette avancée, c’est le chiffrement des objets.

Ce chiffrement est optionnel. Il doit être résistant, c’est à dire correspondre à l’état de l’art en cryptographie appliquée. On doit être en mesure de parfaitement distinguer l’objet en clair de l’objet chiffré, même si le second est dérivé du premier.

Ceci est une proposition de travail.

Deux étapes de chiffrement

Les entités sont des objets contenant le matériel cryptographique nécessaire au chiffrement asymétrique. Cependant, le chiffrement asymétrique est très consommateur en ressources CPU (calcul). On peut l’utiliser directement pour chiffrer les objets avec la clé publique d’un correspondant, mais cela devient rapidement catastrophique en terme de performances et donc en expérience utilisateur. D’un autre côté, le chiffrement symétrique est beaucoup plus performant, mais sa gestion des clés de chiffrement est délicate. Pour améliorer l’ensemble, on mixe les deux. On essaie de profiter des avantages de chacun tout en réduisant les défauts.

Ainsi, on va aborder le chiffrement en deux étapes distinctes. Voici le schéma de l’ensemble que l’on va décomposer.

Pour la compréhension, ne pas oublier que les propriétés des objets sont elles-mêmes des objets…

Continuer la lecture de Introduction à la cryptographie

Cerberus et la mise en quarantaine d’objets

Une nouvelle entité est mise en ligne.

Cette entité à pour mission de lister les objets à bannir. Ce peut être par exemple du code malveillant.
Il faut bien sür faire confiance à cette nouvelle entité… et supprimer automatiquement les objets référencés via cet objet particulier :

126520cc2d5453c68d070e80a38bea3c501cb2ef6284ec1edddc34b717739b8d
‘cerberus/danger‘.

L’entité est en ligne ici : http://cerberus.nebule.org/

Les scripts actuels de nebule ne le gère pas encore, mais ça viendra…

Problèmes en cours

Deux problèmes apparaissent avec le chronographe :

1/ La gestion du suivi des événements dans le temps via l’objet "nebule/objet/entite/suivi" et dérivés n’est as optimale. La période de temps exponentielle donne satisfaction même si elle pourrait être remplacée par une fonction beaucoup plus linéaire que le calque sur le découpage humain du temps (seconde, minute, heure, jour, mois, année). Le problème vient surtout que les caractéristiques des objets "nebule/objet/entite/suivi" et dérivés sont elles-même déplacées d’un objet à l’autre et ne sont plus directement disponibles pour l’objet d’origine.

2/ Je songe à remplacer l’objet "mime-type" par "nebule/objet/type", et l’objet "hash function" par "nebule/objet/hash". Cela implique de corriger une grande partie des scripts déjà en places. A voir…

Le lien et la subdivision d’objet

Un lien particulier avec pour action ‘s‘ permet de faire de la subdivision d’objet. A quoi cela sert-il ?

Il y a deux usages possibles de cette action.

Le premier usage est de permettre de scinder un objet volumineux en une multitude de morceaux, une multitude d’objet plus petits. Ces objets dérivés peuvent avoir des tailles identiques ou non. Ils doivent impérativement être non recouvrants et parcourir l’intégralité de l’objet parent.
En scindant un objet volumineux, il peut être transféré par morceaux vers différents emplacement (d’autres entités). Et donc une autre entité peut simultanément télécharger les multiples morceaux à des emplacements différents. Une fois tous les morceaux rassemblés, l’objet parent, l’original, peut être reconstitué.
C’est une des techniques nécessaires au fonctionnement du P2P par exemple.

Le deuxième usage, c’est de ne faire qu’un seul objet dérivé d’un objet parent plus grand. Cet objet dérivé fonctionne alors comme un extrait de l’objet parent. On ne peut pas reconstituer l’intégralité de l’objet parent à partir de l’objet dérivé.
Bien sür, plusieurs extraits d’un objet peuvent être faits. Et un extrait plus petit encore peut être retiré d’un autre extrait. Rien ne limite le nombre d’objets dérivés. Rien ne garanti leur non-recouvrement ni qu’ils parcourent l’intégralité de l’objet parent.
L’usage peut par exemple être l’extrait d’une citation dans un livre, un extrait d’une musique, etc…

Actuellement, une subdivision est référencée par un objet contenant une et une seule ligne de type x-y. Mais peut-être serait-il intéressant de permettre plusieurs lignes de type x-y, cela créant un extrait contenant directement la concaténation des différents extraits d’un objet. Quel usage ?

Chronographe : 20 jours après

Le chronographe expérimental est lancé depuis maintenant 20 jours et quelques heures (CF Chronographe).
Il tourne toujours.

L’accès via le web est impossible. La page de bootstrap avait déjà été modifiée pour supporter un grand nombre de liens. La visualisation de l’entité est impossible via la page gnav.php . Il faut modifier le robot pour qu’il ne lie pas les traces de temps avec sa propre entité mais avec l’objet contenant "nebule/objet/entite/suivi".

En regardant de plus près, il faut une vingtaine de secondes pour lister tous les fichiers contenants des liens. Il y en a plus de 29000…
C’est encore exploitable, mais peut-être faudrait-il dans ce cas répartir les objets dans des sous-répertoires et alléger le système de fichiers qui n’est pas vraiment prévu pour ça. Le robot ne semble pas ralentir dans son fonctionnement malgré tout, c’est que les fichiers restent accessibles dans un temps raisonnable.

Le robot est recréé ce soir avec quelques correctifs.
kronos.nebule.org

Yubikey et la double authentification

Une des bêtes noires de la sécurité des utilisateurs et de leurs informations sur l’Internet est le mot de passe. Ou plutôt devait-on dire la multitude de mots de passes et de comptes utilisateurs qui vont avec.

Chaque service web nécessite un compte utilisateur pour être utilisé, normal. Ce qui est moins normal, c’est que cette identification reste assez strictement localisée au service en question. A part quelques tentatives qui n’ont remportée qu’un succès d’estime, chaque service gère jalousement ses utilisateurs. Il en résulte un multitude de comptes utilisateurs différents avec potentiellement autant de mots de passes.
La gestion de l’identité sur l’Internet est un vrai problème. La gestion des mots de passes associés encore plus. Même si l’on met le même mots de passe partout, il faut régulièrement le retaper. Et bien sür, avec un mot de passe unique, on devient vulnérable au premier service qui ne sécuriserait pas correctement ceux-ci.

Yubico propose une solution basé sur le mot de passe à usage unique (OTP – One Time Password). L’ensemble fonctionne sur le principe de ‘ce que je connais‘ et ‘ce que j’ai‘. La double authentification repose donc sur deux moyens combinés de prouver son identité. On doit fournir les deux ou prouver que l’on détient les deux.

  1. ‘Ce que je connais‘, c’est typiquement un nom d’utilisateur et un mot de passe.
  2. ‘Ce que j’ai‘, c’est un objet dont je dispose. Cet objet doit être capable de prouver sa présence de façon numérique. C’est ici la YubiKey.
  3. ‘Ce que je suis‘, c’est le plus dur à obtenir… puisque c’est généralement ce que l’on cherche.

La clé YubiKey branchée en USB émule un clavier et envoie un mot de passe OTP lorsque l’on appuie sur un bouton de la clé. Ce mot de passe unique est dérivé de l’identifiant de la clé, d’un numéro de séquence, d’une empreinte CRC et de divers autres champs. Le tout est converti en caractères imprimables et envoyé comme si il était tapé sur un clavier.
Ce OTP est transmis au serveur en même temps que le nom d’utilisateur et éventuellement un autre mot de passe (double authentification). Le serveur le transmet au YubiCloud pour vérification et attend une réponse positive ou négative sur la validité de l’OTP pour donner l’accès au service à l’utilisateur… ou pas.
L’OTP change à chaque fois et ne peut être rejoué. Il peut donc être divulgué une fois utilisé.
La YubiKey peut être volée, sans le compte à utiliser (ou le deuxième mot de passe) elle est inutilisable.
Si double authentification, le mot de passe peut être volé (keylogger), il n’est pas utilisable sans la YubiKey à côté.

Une des propriétés intéressante de cet implémentation, c’est que l’on peut voir l’ensemble comme la transmission de messages chiffrés (symétrique) entre la YubiKey et la YubiHSM. Toutes les clés connaissent l’unique (ou pas loin) mot de passe secret de chiffrement. On fait confiance au matériel (les clés USB) pour savoir garder le secret.

Le système est de loin préférable à la simple authentification par mot de passe. Mais il n’en présente pas moins des problèmes :

  1. Une petite polémique est apparue sur la robustesse réelle du système. Un CRC16 permet de vérifier la validé du paquet. Ce CRC est inclus dans les données chiffrées et couvre donc 128-16=112bits. En jouant des paquets au hasard, il y a 1/(2*2^16) chances que la signature du CRC16 soit cohérente avec le reste. Si l’on compte qu’il faut statistiquement parcourir la moitié des valeurs pour en trouver une bonne, cela donne une probabilité de 1/(2^16). Cependant, dans les données chiffrées, il y a aussi le champ private identity de 6 bytes=48bits. Ce champs étant vérifié comme nul ou valide par les serveurs, la probabilité remonte à 2*1/(2^(16+48)) soit 1/(2^63). Ce qui sauve les meubles c’est que l’attaque doit passer par le réseau, la solidité réelle de l’ensemble est de 2^63 et non de 2^128…
  2. Il faut la coopération active des services qui authentifient les utilisateurs. La méthode d’authentification doit être modifiée pour supporter la vérification de l’OTP en liaison avec le YubiCloud, l’infrastructure qui valide réellement l’authentification. Pour les personnes qui gèrent elles-même leurs blogs ou autres services, c’est un réel gain. Mais pour un gros acteur de l’Internet c’est plutôt une ingérence sur un sujet sensible que sont les utilisateurs et tout ce qu’ils rapportent. Cela à donc autant de chance d’être adopté que d’autres solutions par le passé comme OpenID, faible.
  3. La solution nécessite une connectivité vers l’Internet et le YubiCloud pour valider l’authentification. Impossible donc de travailler hors-ligne. Il y a 5 serveurs dans le monde, c’est déjà pas mal mais c’est aussi encore trop peu pour résister à un DDOS ciblé. Et en cas d’absence de connexion prolongée aux serveur, tous les services associés sont eux-aussi paralysés. On a un point de défaut unique.
  4. Comment va se comporter l’ensemble lorsque le compteur anti-rejeu va boucler ? La clé ne marchera plus. La taille du compteur est de 15bits=32768 utilisations (avec branchement de la clé).
  5. Volontairement, la YubiKey ne peut être mise à jour. La clé est accessible en lecture seule, ce qui empêche la diffusion de virus et réduit la surface d’attaque de celle-ci. Mais que se passera-t-il quand, inévitablement, une faille sera trouvée sur cette clé ? Poubelle.

D’autres questions restent en suspend. L’analyse rapide de la documentation sur le site web de Yubico ne permet pas d’y répondre.

  1. Clé unique de chiffrement AES entre toutes les clés YubiHSM ? Ou une clé AES par YubiHSM ? Ce système de clés secrètes interdit notamment toute concurrence avec les mêmes clés. Utiliser la cryptographie asymétrique plutôt que symétrique aurait permit bien plus de choses et relevé la sécurité à plus long terme.
  2. Et si un serveur d’authentification du YubiCloud répond toujours OK même si les OTP sont invalides ? Quelle est la robustesse de l’infrastructure du YubiCloud ? La liaison entre les API côté clients et les serveurs API Validation Servers est chiffrée avec une clé partagée. Les serveurs KSM avec leurs YubiHSM sont indépendants des API Validation Servers. Mais si la clé AES semble bien protégée dans les YubiHSM, je n’ai pas vu de mécanisme de signature de la réponse.
  3. Yubico ne semble pas aimer la cryptographie symétrique, elle n’est employée nulle part. Dans un contexte entièrement centralisé autour de quelques serveurs, la cryptographie symétrique appliquée à tous les échanges reste cependant acceptable. Mais on en revient à une critique précédente, cela renforce l’unicité du point de défaillance de ces serveurs.

Qu’en penser ?
Toute la sécurité repose sur la/les clés AES des YubiHSM, la robustesse de la clé YubiKey et sur l’implémentation du chiffrement de l’OTP. La solution semble viable à court terme. Trop de défauts la condamne malheureusement à long terme.
Bref, c’est mieux que de se reposer uniquement sur le user/password, mais il faudra l’abandonner sans regrets au premier signe de faiblesse.

Liens :
– http://www.yubico.com/
– http://www.wired.com/wiredenterprise/2013/01/google-password/all/
– http://www.yubico.com/products/yubikey-hardware/
- http://static.yubico.com/var/uploads/pdfs/YubiKey_manual-2.0.pdf
– http://www.yubico.com/wp-content/uploads/2012/10/YubiCloud-OTP-Validation-Service-v1.1.pdf
– http://www.schneier.com/blog/archives/2013/01/googles_authent.html
– http://gonzague.me/yubico-yubikey#axzz2IzWaf5Dr
– https://bitcointalk.org/index.php?topic=85648.msg943612#msg943612
– http://openid.net/

Protocoles (a)symétriques

Un article sur le sentiment de stagnation de l’innovation (InternetActu.net) amène un commentaire (le premier) sur la symétrie de l’Internet et de ses protocoles.

Le commentaire relève l’asymétrie des acteurs, soit les fournisseurs de services et les clients/consommateurs. Il en découle logiquement des conflits d’intérêts. Le premier se trouve entre le client piégé et le fournisseur de service résolument fermé aux autres fournisseurs de services. Le deuxième conflit est révélé par l’actualité entre Free et Google, entre le transporteur de paquets et le nÅ“ud de services.
Cette asymétrie se retrouve dans les protocoles utilisés sur le réseau des réseaux.

La solution proposée serait de déployer des protocoles symétriques. Ceux-ci existent depuis des décennies mais sont peu employés. Ils permettraient de relier directement les gens entre eux sans les intermédiaires bien encombrants que sont les nÅ“uds de services. Et accessoirement, cela assurerait la neutralité du réseau et relancerait l’innovation pris en otage par les grosses sociétés.

Mon avis, c’est que le problème est bien réel mais cette solution me semble un peu superficielle. La façon de la mettre en avant fait un peu… commercial d’ailleurs, même si aucun produit n’est proposé derrière. Bref, comme souvent, c’est une mauvaise solution à un problème mal posé.
Oui le système des brevets est utile, mais complètement détourné de son but originel. A revoir si l’on veut relancer rapidement l’innovation par les petites sociétés. Il devait assurer la diffusion du savoir et des innovations contre des garanties. Il est aujourd’hui la base d’une guérilla juridique pour protéger coüte que coüte des positions commerciales au détriment… de l’innovation.
Oui l’Internet est asymétrique, et on n’y changera pas grand chose tant que la connexion de l’utilisateur restera… asymétrique. J’ai vu que ce problème a été abordé quelque part dans un commentaire comme étant une cause de problème. L’ADSL qui connecte une grande partie des utilisateurs est volontairement asymétrique, mais cela correspond à une optimisation liée aux usages des internautes depuis 15 ans. Ce n’est pas une cause de dissymétrie mais une conséquence. Et donc aucun changement n’est à attendre de ce côté là tant que les usages de l’Internet ne changeront pas.
Non les protocoles asymétriques ne résoudront pas le problème d’asymétrie de l’Internet. Que le protocole soit symétrique ou pas n’a pas d’importance. Bien qu’utilisant des protocoles symétriques, nous savons déjà aujourd’hui parfaitement faire dialoguer deux utilisateurs directement entre eux, le fameux Pair à Pair (P2P). Ce qui à de l’importance c’est l’usage, encore et toujours. Tant que l’on ne proposera pas à Facebook et consorts des alternatives utilisant les propriétés du P2P et potentiellement complètement acentrés, ça ne changera pas.

La translation d’adresse IP (NAT) sera, si elle ne l’est déjà, un plus grand frein à la symétrie des usages de l’Internet. Tant que plusieurs utilisateurs seront cachés derrière une seule adresse IP, ils sera difficile de leur donner un rôle autre que celui de consommateur. Le NAT sert aussi à faire de la sécurité pour les postes cachés, ou plutôt devrait-on dire que ça y contribue un peu (pas plus). Rien que pour ça, IPv6 (sans NAT) devrait être une des plus grosses priorités.

Retour au projet nebule. Celui-ci permet de répondre à l’asymétrie des usages non pas en faisant tomber les nÅ“uds de services ou en rendant le réseau complètement symétrique, mais en redonnant au réseau sa vraie place de transporteur. La symétrie est assurée (ou pas) par les liens entres objets, indépendamment du moyen de transport.

Liens :
– http://www.internetactu.net/2013/01/09/vers-une-stagnation-de-linnovation/
– http://www.internetactu.net/

Chronographe

Une nouvelle entité vient d’être mise en ligne : kronos

C’est un chronographe, il mesure le temps.
Et il le signe !

Toutes les minutes, l’objet 09531c684ca8804f671250db6d20403745f3e9c156eb1fad80945b9a4030105a est mis à jour avec en dernier la trace du temps.
Cet objet s’appelle ‘nebule/objet/entite/suivi/m00‘, la minute 0 du temps passé.
Le temps a dans nebule un écoulement linéaire et exponentiel. Il est linéaire pour des périodes de temps du même ordre de grandeur. Il est exponentiel lorsque l’on change d’ordre de grandeur.

Il y a encore quelques erreurs résiduelles dans les objets générés parce que le moteur de nebule et en cours de ré-écriture complète… et que c’est actuellement un peu buggé…
Mais l’idée est là et surtout : ça marche :-)

A quoi cela sert-il ? – Rédigé !

Un premier texte explicatif sur l’utilité de nebule est rédigé dans une page.

Cette page est disponible sur le blog en haut à gauche.

C’est une résolution de cette nouvelle année, rendre le projet plus lisible.
L’étape d’après sera de le rendre plus visible…
Bonne année 2013 :-)


811ba947111090b4708da62494a84e5cfc13ea60e16dac94a678f395aa42da07