Turb(l)o(g)
Bitmessage, le bitcoin de l’email
| Tweet |  |
A la faveur d’un article de l’ami Korben, Bitmessage a débarqué sur le devant de la scène people en France la semaine dernière.
De quoi s’agit-il exactement ? D’un réseau peer to peer de messagerie chiffré. Les principes de base sont les mêmes que le bitcoin (voir ma série sur le sujet) :
- Aucune autorité centrale d’aucune sorte (pas même l’infrastructure DNS)
- Chiffrement de bout en bout
- Diffusion par inondation totale de l’ensemble du réseau (ou presque)
Les mécanismes mis en jeu sont toutefois plus simple que le bitcoin, l’historique n’ayant pas besoin d’être conservé à long terme pour assurer la traçabilité d’une monnaie.
Lorsque vous lancez le client bitmessage pour la première fois, vous allez créer une adresse, par exemple BM-2DACG68CuqSrLHxyXdWug3nZZxhBn6cQTt. Celle-ci contient un hash (si vous avez décroché, allez lire la série sur le bitcoin) de votre clé publique. Lorsque vous allez envoyer un message, à une autre adresse de la même forme, donc, votre client bitmessage va générer une demande pour obtenir la clé publique correspondant au hash de l’adresse de votre destinataire pour pouvoir chiffrer le message.
Cette demande va parcourir l’ensemble du réseau jusqu’à tomber sur le destinataire en question qui va répondre avec sa clé publique. Puisque vous disposez du hash de cette clé, le logiciel pourra vérifier rapidement que la clé qu’on vous a fournie est la bonne, puis chiffrer votre message avec, le signer avec votre propre clé, et renvoyer le tout sur le réseau. Pour être valable, ce paquet doit, comme dans le cas du bitcoin, faire l’objet d’un travail sur son hash en SHA256 pour tomber sur un certain nombre de zéros dans le hash. Le protocole est prévu pour qu’un ordinateur lambda mette 4 minutes à accomplir ce travail.
Une fois envoyé, chaque membre du réseau tente de déchiffrer chaque message. S’ils n’ont pas la bonne clé privée, c’est peine perdue, sinon, le message est déchiffré, et la signature vérifiée à partir de votre clé publique contenue dans le message, elle même vérifiable par le hash qui est inclus dans votre adresse bitmessage.
C’est, comme bitcoin, brillant de simplicité et d’efficacité. Car non content de permettre le chiffrement de bout en bout sans recourir à aucun artifice de type échange et vérification préalable de clé ou autorité centrale, bitmessage permet efficacement de lutter contre le spam, puisqu’il faut, quoi qu’il arrive, 4 minutes pour fabriquer un seul et unique message, rendant le spam trop cher pour être efficace. Il est même possible pour chacun de définir un facteur de difficulté plus élevé pour obliger les correspondants à travailler plus pour vous envoyer un message.
Les performances du système, en cas d’utilisation massive, ont même été pensées : le réseau pourra se hiérarchiser de lui même pour éviter que chaque participant doive tester l’ensemble des messages transmis. Ce petit artifice est réalisé par la constitution d’un arbre de flux de messages. Pour faire simple, on peut comparer ce fonctionnement à celui du courrier classique : lorsque vous envoyez une lettre dont la destination est dans la même ville que vous, elle ne va pas sortir de la ville. Par contre, quand vous écrivez à quelqu’un à l’autre bout du monde, votre courrier va parcourir un certain nombre de points de collecte.
Même si la version actuelle de bitmessage est un peu rébarbative, je vous invite à jouer avec et à suivre ses évolutions ! Vous pouvez me causer à la maison sur BM-2D7AjVjnrV2fFbZ9SYHfxfkjfbPntpEEJQ et au bureau sur BM-2DACG68CuqSrLHxyXdWug3nZZxhBn6cQTt :)
(Et puis si vous ne faites rien jeudi vers 14h, je parlerai bitcoin & bitmessage avec qui voudra venir dans le cadre de Pas Sage en Seine. Rendez-vous aussi vendredi à 17h au même endroit pour une conf sur @maisonquitweet !)
Moi je note surtout que, puisqu’il n’y a pas de système de vérification de correspondance clef ↔ identité, que cette vérification doit être faite extérieurement, autrement rien n’empêche un attaquant de se faire passer pour quelqu’un et de recevoir, en toute sécurité, les messages qui lui sont destinés, et éventuellement les retransmettre.
Pour ceux qui penseraient que voilà enfin un système de chiffrement sûr et simple, c’est faux : c’est sûr /ou/ simple, mais pas les deux. Si vous voulez envoyer un message chiffré à quelqu’un, il doit vous donner son adresse en personne. Si vous voulez envoyer un message à quelqu’un que vous n’avez jamais vu en personne, ne considérez pas que cette transmission est sûre, parce qu’elle ne l’est pas.
Tout à fait, j’ai mal tourné ma phrase. L’idée est que transmettre une adresse et un lien avec un soft simple à downloader et utiliser est autrement plus accessible que GPG ou autre système de communication sécurisée.
Pas sur d’avoir saisi l’intérêt de la partie hachage avec les zéros comme pour les bitcoinsdans ce cas précis. C’est juste pour ralentir l’expéditeur pour éviter le spam ? L’intention est louable mais 4 minutes pour envoyer un message ça empêche l’utilisation en mode ‘conversation’ non?
En partie pour le spam, oui, mais surtout, imho, parceque les nodes du réseau conservent la totalité des messages pendant 48h pour pouvoir les livrer aux membres temporairement absents. Du coup, trop de messages risqueraient d’autodétruire le système.
Du coup, en effet, système pas adapté à un mode live.
Ce système n’implique-t-il pas que les clients émetteur et destinataire doivent être connecté en même temps au réseau pour pouvoir récupérer la clef public du destinataire? Ça me semble un terrible frein! De même, on est dans une position parfaitement bijective comme ton exemple le montre: on s’adresse à ton bureau ou à ta maison, et tu ne peux (directement via ce système en tout cas) voir les messages de ton bureau quand tu es à ta maison. J’imagine tout de fois qu’un client BM bien bati permettra de « grouper » ses adresses personnelles et avec quelques règles, permettra une synchronisation entre adresses perso.
L’idée est séduisante, et certainement plus accessible que GPG pour ma grand-mère. Mais pour l’instant j’ai l’impression qu’il faut écouter pour recevoir un message.
En effet, le message ne partira pas si tu n’a pas déjà connaissance de la clé ou que le destinataire n’est pas en ligne.
Pour les adresses, j’ai pas fouillé, mais on doit pouvoir importer des adresses préexistantes dans n’importe quel client et, du coup, récupérer les messages partout.
Facile il suffit de partager les datas de bitmessage entre les deux postes, un petit coup de dropbox / drive et hop
*
Plus sérieusement j’ai vu lors du lancement la connexion bootstrap à des serveur maîtres (src/defaultKnownNodes.py):
stream1[‘85.171.174.131’] = (8444,int(time.time()))
stream1[‘23.28.68.159’] = (8444,int(time.time()))
stream1[‘66.108.210.240’] = (8080,int(time.time()))
stream1[‘204.236.246.212’] = (8444,int(time.time()))
stream1[‘78.81.56.239’] = (8444,int(time.time()))
stream1[‘122.60.235.157’] = (8444,int(time.time()))
stream1[‘204.236.246.212’] = (8444,int(time.time()))
stream1[‘24.98.219.109’] = (8444,int(time.time()))
Il faut un port d’ouvert ce qui dans certain endroit me semble compliqué. Bref l’idée est pas mal même si je doute que mme michu l’adopte et on risque de se retrouver avec la même chose GPG over SMTP, non?
Yann
* le troll ne possède pas de balise ouvrante
Depuis quelques jour, une grosse mise à jour est disponible, la version 0.4.0 . Pour GNU/Linux, Windows et même les PC* Macintosh!
Malheureusement, les adresses précédentes ne semblent pas « compatibles »… ? ?
*PC = Personal Computer, donc aussi les macs :D /troll
Leave your response!
Dossiers
Derniers articles
Licence
Les contenus de ce blog sont, hors citations et images, sous licence Creative Common BY
Identité Ğ1
Catégories
Archives
Tags
Les autres
Mon bordel à moi
Recherches
Commentaires
Articles les plus commentés