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.



TRUST ONLY YOURSELF!

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 :)

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 ;)

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 :)

jrbleboss a écrit :



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 :



http://www.amazon.fr/exec/obidos/ASIN/2841770184/technoscience-21

http://livre.fnac.com/a5250708/Jacques-Velu-Methodes-mathematiques-pour-l-inform…

http://www.amazon.fr/Cryptographie-appliqu%C3%A9e-Bruce-Schneier/dp/2711786765







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 :)

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?







Pas actuellement, mais tu peux très facilement déployer ton propre serveur compatible cryptocat (voir commentaire de David_L :http://www.pcinpact.com/news/76973-le-site-crypto-cat-change-look-nouvelle-versi… )



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 :)