C’est tout le problème de l’open-source. Le bonne sécurité du logiciel est sensé être garanti par le fait que tout le monde puisse le lire.
Ce n’est que la première étape…
Comme toute première étape, elle ne suffit pas, mais son absence élimine toutes les suivantes.
Mais déjà peu de monde sait lire du code facilement (on peut savoir programmer, mais être incapable de lire le code d’un autre)
D’où l’importance de maintenir des pages de spécification du protocole claires et détaillées. Ca permet aux gens familiers avec le sujet de “relire” les principes d’une application sans forcément épelucher le code source éparpillé dans 30 fichiers, et probablement dans un langage qu’ils maitrisent mal.
…si la spécification représente fidèlement ce que le code fait ;)
mais en plus dans certains domaines on rajoute une surcouche avec les concepts mathématiques sous-jacent qui demandent de bonnes bases pour être compris.
C’est sur que les experts sont rares dans tous les domaines, et leur temps précieux.
D’où l’idée de leur rendre la tâche aussi facile et assistée que possible !
P.S: dans mon boulot je m’amuse à insérer volontairement des erreurs énormes dans mes drafts pour voir qui relit vraiment ou pas, pour l’instant aucune n’a été remontée, depuis 2 ans " /> Par contre les remarques sur la taille des marges et la police, ça j’en ai à la pelle.
La version web de Cryptocat, bien qu’utilisée via HTTPS, est toujours sensible à une modification du code côté serveur en cas de compromission du serveur. Cela est toutefois limité en cas d’utilisation de l’application Chrome, qui fait tourner le code localement de façon analogue à OTR. Cryptocat peut également hériter de vulnérabilités qui affectent son navigateur web.
Hahaha, ce passage est complètement périmé depuis la refonte de cryptocat 2 !
Comme quoi, on ne peut pas toujours compter sur la communauté de wikipedia pour tenir les pages à jour ;)
Mort de Michael Jackson > Cryptocat corrige ses faiblesses
Pour ceux qui utilisent Pidgin-OTR, utilisez-vous une clé par ressource (par exemple une pour la maison et une pour le boulot) ou une clé pour toutes les ressources du même compte?
Lorsqu’on utilise des clés différentes, c’est assez chaotique (au moins une des deux ressources ne pourront plus le déchiffrer).
D’un autre côté, à part copier manuellement ~/.purple/otr.private_keys, rien n’est fait pour utiliser la même clé à plusieurs endroits… est-ce une bonne pratique pour OTR?
Garde une clé privée par station/appareil, et n’oublie pas de faire la vérification mutuelle de fingerprint pour chacune ;)
Comme ça si une machine est compromise, tu peux changer de machine et continuer tes conversations !
fwak a écrit :
Je ne parle pas de Cryptocat dont je ne connais pas le fonctionnement, je pensais à PGP.
Le code mis à dispo ne garantit pas que les experts en mesure d’analyse le code l’ont fait, et ont remonté/corrigé les failles. Ca, c’est un truc, ça m’a toujours amusé comme argument.
C’est un très très gros problème, plus que les gens ne le réalisent.
Il y a trop peu de gens qui relisent réellement le code et la spécification des protocoles des outils de sécurisation récents.
PGP, AES, Tor ont été scrutés de font en comble et sont aussi solides que les fondements mathématiques sur lesquels ils reposent (modulo la probabilité de LA faille qui aurait échappé à tout le monde, qu’on tente de faire tendre vers 0)
OTR est dans une catégorie intermédiaire. Assez scruté mais encore jeune, en comparison.
Cryptocat est encore en train de poser ses fondements et de concevoir/améliorer/corriger son protocole, c’est un nouveau né.
Il a besoin de murir et de BEAUCOUP PLUS de relectures pour être mis sur le même pied de fiabilité que PGP et Tor.
Il y a quelques projets intéressants destinés à améliorer, rendre plus facile et automatisé la relecture des projets récents/en mouvement par une communauté compétente, mais ces projets n’ont pas encore abouti :(
John Shaft a écrit :
C’est ballot, j’ai un membre de ma famille spécialisé dans un domaine proche de la cryptographie (factorisation des grands entiers) mais il n’aide personne " />
Montre-lui le projet, si ça le passionne il relira peut-être ça comme du p0rn et verra l’erreur que tout le monde a raté ?
C’est comme ça que je suis tombé dedans, moi :p
Le
11/06/2013 à
15h
47
Crysalide a écrit :
Sinon, une page et surtout un schéma sympa de l’anonymat offert par HTTPS+Tor selon que l’on se place du côté de l’utilisateur, du FAI, de l’admin du site, du hacker, de la police ou de la NSA. " />
On se rapproche rapidement d’un scénario de surveillance globale passive (GPA), qui échappe à ce contre quoi Tor peut défendre.
On n’y est pas, mais c’est une nouvelle preuve du fait qu’on ne peut pas éternellement ignorer ce que le monde politique et les agences gouvernementales font dans notre dos. Les outils de cryptographie et anonymat sont une rustine destinée à nous rendre un peu de vie privée et de sécurité dans un monde imparfait.
La solution n’est pas d’accepter d’être surveillé en chiffrant tout (jusqu’au jour où nos outils sont mis en échec), la solution est de mettre fin à ces politiques illégales et malsaines.
(et continuer de chiffrer, au cas où.)
John Shaft a écrit :
Ensuite, il peut toujours y avoir une vilaine faille cachée dans le code de Cryptocat. Enfin je suppose que c’est un point particulièrement suivi par ceux qui participent aux dév du truc " />
On fait de notre mieux, mais j’en profite pour rappeller qu’on est peu à participer au projet, qu’il n’y a (malheureusement) pas foule d’experts et de cryptocat pour relire chaque version publiée, et que le transfert de fichier est encore dans une phase de “beta”.
Mon conseil reste de demeurer prudent dans son utilisation de Cryptocat. Sa sécurité n’est ni nulle ni réputée inviolable.
C’est un outil pour améliorer votre vie privée par rapport à un Facebook Chat où chaque message est enregistré. Cryptocat n’a pas été créé pour être la solution qui mettra en échec une NSA en pleine puissance.
Khalev a écrit :
Comment se passe l’échange de clé?
C’est toujours le point critique.
Je t’invite à aller voir la documentation du protocole : GitHub(j’ai pas encore fini de re-travailler cette page mais elle devrait être suffisamment conforme pour répondre à tes questions :) )
Cryptocat relies on an Elliptic Curve 25519 key agreement scheme.
Du Diffie-Hellman sur base de courbes élliptiques, donc ;)
fwak a écrit :
Et moi, les clefs publiques/privées fournies par un tiers “de confiance”, ben, je ne leur fais plus confiance non plus, depuis PRISM " />
Le principe des systèmes à cryptographie publique (clés privées/publiques) est justement prévu pour ne pas avoir à faire confiance à un “tiers” ;)
Dans tous les cas, peu importe la cryptographie ou la sécurisation, tu dois au minimum avoir confiance en toi et en ton interlocuteur.
Ce qu’on sécurise, c’est tout ce qu’il y a entre les deux.
D’ailleurs petit rappel: dès qu’on parle de cryptographie publique, que ça soit Cryptocat, OTR, PGP etc, si vous ne vérifiez pas la “fingerprint” affichée consciencieusement et systématiquement, vous n’êtes même pas sur de parler au bon interlocuteur :p (ce qui brise le schéma de confiance !)
D’où est-ce que tu sors cette règle ? Ne serait-ce pas une mauvaise interprétation de la seconde loi de Kerckhoffs, qui elle ne dit qu’il ne faut pas baser le fonctionnement d’un système de chiffrement sur quelque chose de secret. En gros, l’algorithme doit être public. C’est différent de demander d’avoir une relecture de l’implémentation.
Pas une mauvaise interprétation, plutot une implication, en quelques sortes. C’est même une exigeance absolue pour toute standardisation d’un algorithme ou protocole cryptographique : des années de tentatives de les casser, ouvert à tous les académiques du monde, en espérant que s’il y a quelque chose d’évident à casser, quelqu’un le trouvera pendant ces quelques années.
Quelque chose à quoi les 5-6 concepteurs et autres examinateurs n’auront peut-être pas envisagé.
D’où l’établissement, dans l’inconscient collectif, de cette règle selon laquelle un système n’ayant pas été ouvert au public et résisté à bon nombre d’analyses, d’études et de tentatives de compromisation, n’est pas digne de confiance.
Ricard a écrit :
Encore une utilisation à tester unr un Raspberry Pi.
J’adore mon raspberry pi, mais je ne l’utiliserais probablement pas pour ce genre d’applications cryptographiques.
En l’état, je ne suis réellement pas sur que ce petit appareil effectuant souvent les mêmes exactes opérations continuellement soit capable de générer assez d’entropie pour quoi que ce soit qui nécessite la création de certificats.
Dans le cas de cryptocat, le chiffrement est fait par les clients, donc c’est déjà ça, mais le serveur doit malgré tout gérer les sessions SSL, et ça serait pas mal de pouvoir gérer des sessions SSL éphémères (à chaque nouvelle connexion, une nouvelle clé)
Je ne suis pas sur qu’un raspberry pi sache supporter une telle charge processorale, ou avoir suffisamment d’entropie pour générer un grand nombre de certificats assez différents.
Zimt a écrit :
Bonjour koolfy, merci de te soucier de tout ça mais vraiment à ce sujet et ce niveau d’implémentation assez simple, ne t’inquiète pas pour moi ;)
Juste un point, quand tu dis “NE JAMAIS CRÉER SON PROPRE SYSTÈME OBSCUR DANS SON COIN”, quelle valeur ça a ?
C’est un non sens.
Tu voulais peut être dire “Miser sa politique de sécurité sur de l’obscurantisme (par ex. noyer la donnée) ou l’offuscation, n’est pas un choix réellement viable”.
Pour le reste, tes conseils sont cependant avisé pour quelqu’un qui débuterais dans cette discipline.
Si je puis me permettre, d’une manière générale je recommande ces 3 ouvrages :
Si c’est un non-sens, il me semble que je fais alors l’erreur de répéter le non-sens écrit par Bruce Schneier dans “Cryptography engineering” :)
Ce n’est pas de ne pas miser sur de l’obfuscation qui fait qu’on a confiance en l’AES ou OTR, c’est le fait qu’ils ont été publiquement disponible à la cryptoanalyse et aux attaques depuis quelques années, et que personne ne les a mis à mal.
Tant que personne n’a essayé de casser ton système, tu n’as pas la moindre preuve que ça n’est pas facilement possible.
Mais soit, je pense qu’on a fait le tour de la question :)
Le
24/01/2013 à
00h
33
sylware a écrit :
Ce qui est vachement bien, comme l’API http+json de mega, le navigateur n’est qu’un client comme un autre.
Donc en fait, c’est une web app xmpp. Est-ce que son serveur fait parti de la fédération mondiale des serveurs xmpp?
A terme, le “multiparty protocol” de cryptocat deviendra peut-être (du moins en partie) la spécification pour le vrai protocole mpOTR qui est en élaboration, et donc le tout ne sera qu’une librairie que toutes les applications de chat pourront utiliser comme plugin, à l’instar d’OTR actuellement.
En gros, le but est de pouvoir, un jour, utiliser mpOTR sur xmpp, irc, et tout autre protocole de group chat, de façon transparente :)
Zimt a écrit :
Bien vu " />
C’est en fait un clone que j’ai écris en cpp (désolé, l’implémentation PyQT est trop frustrante), avec des implémentations plutôt spéciales.
Même l’ouverture du code montrerai que ce programme est parfaitement fiable, très loin d’être un coup d’essais.
Merci Koolfy pour tes conseils qui sont cependant tout à fait viables.
Pour le reste, notamment avec les algos je sorts complètement des limites gouvernementales.
Ambiance 1024b rounds 72, 448 et autres Hadamard quand tu nous tiens… mais bon c’est plus pour le fun. Je sais très bien qu’à ce niveau ça n’est jamais analysé. Il faudrait plusieurs siècles même en prenant en compte les évolutions technologiques et que dans ce scénario, c’est le poste utilisateur qui est directement attaqué. Le choix est beaucoup plus vaste à ce niveau là.
Erk.
Torchat n’est pas réellement une solution que je conseillerais, à vrai dire :)
En théorie, se baser sur le réseau Tor devrait être un bon point de départ pour établir une communication sécurisée, mais il y a 1001 façons de tout casser par mégarde :)
De plus, Torchat a récemment été complètement recodé par son développeur en… Pascal.
En plus de la stupi… hum, l’originalité d’une telle décision, la lisibilité du langage implique que la relecture par les pairs est… inexistante.
Ca brise le dogme de sécurité informatique dont j’ai parlé, donc sauf preuve du contraire (et donc relecture !), c’est complètement insécure :)
En ce qui concerne le… balabla “technique” que tu lances ensuite :
“ambiance 1024b” -> 1024 bits de quoi ? la longueur de la clé ? Je ne connais aucun algorithme de chiffrement symmétrique acceptant des clés de 1024 bits. Le vénéré AES s’arrête à 256. Le seul cas de figure où on parle communément de 1024bits est le RSA (chiffrement asymmétrique). Mais si tu as des notions de cryptographie, tu sauras que le chiffrement asymmétrique a un tel impact sur les performances qu’il n’est jamais, en pratique utilisé que pour échanger une clé de chiffrement symmétrique qui sera, elle, utilisée pour chiffrer la donnée.
…et le RSA-1024bits a été rattrappé par la puissance de calcul actuelle. Il est réaliste pour un attaquant avec assez de moyens de casser une clé RSA en quelques mois, et lire tes données en clair avant la fin de l’année :) Donc même ça, c’est une grosse erreur.
“rounds 72” -> 72 rounds de quoi, encore ? C’est quel algorithme de chiffrement qui est itéré 72 fois ? Ceci ne veut à nouveau rien dire :p
l’AES fait 9 rounds pour la variante 128b, 11 rounds pour 192b et 13 rounds pour la variante 256bits, et c’est plus qu’assez.
Le seul algorithme qui, à ma connaissance, permette 72 rounds, c’est SKEIN Wikipedia(hash_function)
…Mais SKEIN n’est pas un algorithme de chiffrement, mais de hash. Ce sont deux applications complémentaires, mais non substituables. Si tu utilises du SKEIN pour chiffrer… tu vas vite avoir un gros problème :) (un hash ne peut pas être inversé, et donc ton message ne peut pas être déchiffré.)
De plus, pour les hash, sha256 est communément accepté pour toutes les applications. sha512 à la rigueur, ou un sha3. Ne cherche pas à sortir des sentiers testés et approuvés, même le sha3 est encore considéré comme trop jeune… après 5-6 ans de tests permanents :)
“448” ? Ce nombre seul ne veut rien dire. C’est parfois la taille de clés de chiffrement pour blowfish, mais si tu utilises réellement blowfish, je ne comprend pas pourquoi ne pas utiliser twofish qui est plus récent et de la même génération que l’AES ?
Quand à Hadamard, c’est juste le nom d’une opération utilisée dans le blowfish, voir ma remarque sur blowfish. Pas besoin d’utiliser du jargon pour impressionner, hein, tu peux aussi appeller les choses par leur nom ! Je vais au boulot en “vélo” pas en “objet doté d’un dérailleur” ;)
Et je garde le plus alarmant pour la fin :
“Même l’ouverture du code montrerai que ce programme est parfaitement fiable, très loin d’être un coup d’essais. ”
La cryptographie est une science: elle demande des preuves et des faits pour étayer des affirmations.
Ton affirmation est assez hasardeuse, si je puis dire :)
Tant que je n’ai pas de code devant les yeux, ce n’est pas digne de ma confiance :)
J’ai la très forte impression que tout ceci tiens plus d’un discours de CSI que de l’expérience d’une réelle implémentation, et je te renvoie donc à la première règle, absolue en cryptographie :
“NE JAMAIS CRÉER SON PROPRE SYSTÈME OBSCUR DANS SON COIN”
Toujours se baser sur ce qui existe déjà, ne jamais improviser, ne pas chercher à révolutionner. On avance à très petits pas, et chaque pas met 5, 10, 15 années de tests avant d’être considéré judicieux.
Chiffrer une donnée, c’est accomplir une sorte de miracle mathématique. Ce n’est ni facile, ni naturel. Il y a 500 000 façons de donner une apparence “chiffrée” à une donnée, mais souvent une seule de la chiffrer correctement. Ce n’est pas parce que tu ne sais pas la lire à l’oeil nu qu’elle ne peut être “cryptanalysée” (non, ce mot n’existe pas :p)
Si tu dois vraiment créer un nouvel outil (comme cryptocat), fais le publiquement et assure toi qu’il a été relu et vérifié par une communnauté d’experts avant de l’utiliser, même entre potes.
Mon conseil est donc de ne pas utiliser ta solution d’apprenti sorcier, et de soit te conformer à OTR, soit utiliser cryptocat, soit publier ton code et attendre que toutes tes erreurs d’inatentions aient été corrigées :)
Tous les experts en ont fait.
Désolé pour le ton un peu condescendant, mais c’est réellement une règle d’or dite, répétée, et qui mérite qu’on enfonce le clou. On me la répétée maintes fois, donc je la transmet.
J’espère que ça ne sera pas mal pris :)
Le
23/01/2013 à
22h
34
Zimt a écrit :
Merci pour Tails, je ne connaissais pas ;)
Bon pour le reste, j’ai en fait, développé mon propre programme de chat qui se base aussi sur le réseau Tor. Je l’utilise avec une poignée d’amis qui ont le même niveau de paranoïa que moi… Sans trop vouloir en dire, l’un d’eux m’a dit “Les dieux vont te punir pour avoir sortie quelque chose d’aussi inhumain.” " />
En fait je n’ai absolument rien à cacher, c’est juste par principe.
En tous cas Cryptocat reste une bonne solution pour le grand publique.
Il y a un dogme en sécurité informatique, qui est communément accepté de nos jours :
Si ton système de sécurité n’est pas public, relu par tes pairs, et que personne n’a essayé de le casser, considère le comme complètement insécurisé.
Si tu as créé ton propre logiciel, je te conseille de ne jamais l’utiliser pour autre chose que des tests, avant de l’avoir publié et d’avoir été relu. (ne serais-ce que par les développeurs de Tor, pour qu’ils te disent ce qu’ils pensent de ton concept ?)
Il se peut que tu fasses quelque chose d’incorrect quelque part, et si tu ne l’as pas vu à ta première re-lecture, tu ne le verras pas à la 53eme, mais d’autres gens à travers la planète la verront peut-être à la première lecture ;)
De plus, si tu ne te bases pas sur les Hidden Services, et ne chiffres pas les messages par dessus, ton traffic peut être lu par le 3eme noeud de ton “circuit Tor”, enfin c’est un autre débat, mais il vaudrait vraiment mieux que tu publies les sources.
J’aimerais bien les lire en diagonale, d’ailleurs :)
Pour ce qui est d’avoir quelque chose à cacher, ce n’est pas la question.
Il n’y a pas besoin d’avoir quelque chose à cacher pour tenir à sa vie privée.
On a tous des rideaux à nos fenêtres, pas vrai ? Et on referme la porte des toilettes quand on les utilise… c’est pareil :)
Le
23/01/2013 à
22h
03
sylware a écrit :
C’est du xmpp avec le support de la jep de l’OTR via openpgp, non?
C’est du XMPP, en effet.
Pas d’openPGP par contre, les conversations privées sont chiffrées par du bon vieil OTR, et les chatrooms sont chiffrées par le “multiparty protocol”, qui en gros, est une sorte de mpOTR informel (multipartyOTR).
Notez que contrairement à l’OTR dont il s’inspire, le “multiparty protocol” des chatrooms de cryptocat n’offre pas -encore?- de “plausible deniability”.
Je ne sais d’ailleurs pas trop d’où viens la mention d’OpenPGP.js de l’article, je ne me rappelle pas l’avoir vu dans le code :)
Le
23/01/2013 à
21h
58
Zimt a écrit :
C’est clair qu’avec l’addon Chrome, “on” sait tout de qui vers qui aller en cas d’enquête sur la vie privée.
“Vous avez quelque chose à cacher Monsieur pour avoir téléchargé cet addon avec votre compte Google?” ;)
Bref, c’est une solution sympathique et suffisante pour le grand publique, ça s’arrête là.
Sinon, tu peux télécharger l’extension manuellement depuis le github : GitHubDe cette façon, si tu n’as pas lié ton navigateur à ton compte google, ils ne devraient pas voir que tu l’as installé.
Ceci dit, toutes les personnes entre toi et cryptocat voient que tu utilises cryptocat (ton FAI, etc…)
Il n’est pas illégal d’utiliser cryptocat, et ce n’est pas assez suspect pour considérer une preuve contre toi, donc cacher ton utilisation de cryptocat n’est pas réellement un enjeux capital. Par contre, cacher le CONTENU de tes échanges, ça, ça l’est :)
(et si tu veux vraiment ne pas être soupçonné par qui que ce soit, tu peux utiliser TAILS sur une clé usb :https://tails.boum.org/ et te connecter au réseau Tor via un Bridge privé, et utiliser cryptocat par dessus, comme ça aucun intermédiaire ne sait ce que tu fais, et même cryptocat ne sait pas d’où viens la connexion. Mais je doute que ça soit réellement nécessaire…)
Le
23/01/2013 à
21h
52
salak a écrit :
Ce qui est bizarre c’est que quand on tape le nom de la conversation, celui qui tape la même convers rentre dans notre chat. Exemple : test
c’est super connu comme mot et du coup n’importe qui peut joindre sans entrer de mot de passe. Ou alors j’ai pas compris le concept du projet.
Tu as bien compris.
Pour le moment, c’est une limitation connue, et référencée dans le threat model : GitHub(un threat model c’est un peu la liste de ce contre quoi un projet protège, et ne protège pas.)
Tu remarqueras qu’ici ce problème est considéré comme un DoS (Denial of Sercvice) dans le sens où si un intrus joins le chat, il n’est plus possible de continuer la conversation privée. (il rend la poursuite de la conversation privée impossible, parce que tout le monde est obligé de se taire.)
J’ai cependant bon espoir qu’on résolve cette problématique avec cette solution : GitHubEn gros : quand quelqu’un rejoins la conversation, tant que tu n’as pas vérifié sa Fingerprint, et cliqué sur “j’identifie ce contact comme de confiance”, tous les messages que tu envoies ne seront pas déchiffrables par lui (mais bien par tous ceux que tu as identifié)
En clair, tu peux avoir 50 agents de la CIA sur le chat, et 3 amis, seuls tes 3 amis pourront lire les messages, les autres verront des chaines de texte d’apparence aléatoires :)
Mais bon, il faut réfléchir aux implications d’une telle méthode, l’implémenter, la tester, la tester à nouveau, réfléchir encore plus aux implications, et encore la tester…
donc en attendant, restez attentifs avant d’appuyer sur enter ;)
Le
23/01/2013 à
21h
45
skydevil a écrit :
Pas faux, mais ça force les paranos a utiliser des logiciels (navigateurs) qu’ils penseront backdoorés à fond " />
Les paranos ont un navigateur propre ou n’en ont pas du tout :)
Le
23/01/2013 à
21h
43
hacksi a écrit :
Très bon add-on et en plus open source et libre. Où peut-on faire un don ?
Je te renvoie au tweet du compte officiel de Cryptocat : TwitterEn gros: Paypal.
Le
23/01/2013 à
21h
40
prisu a écrit :
Je trouve ça marrant d’aller utiliser une extension de chiffrement des conversations alors qu’on utilise Google Chrome " />. Les utilisateurs soucieux de leur vie privée doivent quand même aller de base vers Firefox et cie non ?
L’extension fonctionne aussi avec Chromium. Si tu as plus confiance en Chromium (parce que tu as évidemment lu tout le code pour t’assurer de sa sécurité ! Non je plaisante :p), fais-toi plaisir ;)
Je serais plus inquiet de Safari, personnellement, que de Chrome, mais j’utilise Firefox donc le problème ne se pose pas :)
Le
23/01/2013 à
21h
38
tAran a écrit :
Excellent le sous titre " />" />
(bon, j’ai rien compris..)
Une très brève analyse cryptographique révèle que… ce sont juste des appuis frénétiques sur le même groupe de touches sur la droite du clavier :)
Circulez, y’a rien à déchiffrer " />
Le
23/01/2013 à
21h
37
skydevil a écrit :
Dommage que l’on ait besoin d’une extension…
Comme l’indique David_L, c’est un choix volontaire.
Avant que l’approche du plugin soit adoptée, le code exécuté pour chiffrer un message était chargé depuis la page web de Cryptocat.
Ca veut dire que si ce code était modifié à la volée par un intermédiaire sur le réseau, celui-ci pourrait changer la fonction “chiffrer” et la remplacer par “m’envoyer le message en clair par mail”
(je caricature, mais en gros, c’est ça.)
Et même si aucun intermédiaire ne pouvait faire ça, grace au SSL (assurant que les messages entre toi et le serveur cryptocat ne peuvent être modifiés sans que tu t’en rendes compte), comme tu reçois ton code de chiffrement du site de cryptocat, si un jour le serveur est compromis et il t’envoie un code bidon à la place de celui du chiffrement, tu ne t’en rendras pas compte, tu l’enverras en clair sans le savoir. (Note : MEGA fait cette exacte erreur actuellement. :) )
Donc il a été décidé qu’il était plus raisonnable d’installer UNE FOIS un plugin, s’assurer qu’il était “propre”, et ne plus jamais dépendre d’une source extérieure pour effectuer le chiffrage/déchiffrage.
15 commentaires
Cryptocat chiffre vos transferts, l’EFF recommande ses outils alternatifs
11/06/2013
Le 11/06/2013 à 16h 31
Le 11/06/2013 à 16h 20
https://fr.wikipedia.org/wiki/Cryptocat#Faiblesses
La version web de Cryptocat, bien qu’utilisée via HTTPS, est toujours sensible à une modification du code côté serveur en cas de compromission du serveur. Cela est toutefois limité en cas d’utilisation de l’application Chrome, qui fait tourner le code localement de façon analogue à OTR. Cryptocat peut également hériter de vulnérabilités qui affectent son navigateur web.
Hahaha, ce passage est complètement périmé depuis la refonte de cryptocat 2 !
Comme quoi, on ne peut pas toujours compter sur la communauté de wikipedia pour tenir les pages à jour ;)
Mort de Michael Jackson > Cryptocat corrige ses faiblesses
Le 11/06/2013 à 16h 13
Le 11/06/2013 à 15h 47
[MàJ] L’outil de conversation chiffrée Crypto.cat et son site changent de look
23/01/2013
Le 26/01/2013 à 12h 40
Le 24/01/2013 à 00h 33
Le 23/01/2013 à 22h 34
Le 23/01/2013 à 22h 03
Le 23/01/2013 à 21h 58
Le 23/01/2013 à 21h 52
Le 23/01/2013 à 21h 45
Le 23/01/2013 à 21h 43
Le 23/01/2013 à 21h 40
Le 23/01/2013 à 21h 38
Le 23/01/2013 à 21h 37