Journal Try To Listen Me, nouveau site Open Source de communication chiffrée

17
27
fév.
2015

Bonjour Nal,

Si je viens te parler directement, pour la première fois, c'est pour te présenter un projet personnel qui me tient à cœur.

TryToListen.Me un site web de communication chiffrée de bout en bout dans le navigateur.

Ce site est sous Licence Apache 2.0 et tu trouveras les sources sur la forge propriétaire en vogue GitHub

En quoi consiste ce site web ?

Il se base sur

  • les bibliothèques Javascript OpenPGP.js et JQuery pour la partie cliente
  • pour la partie serveur sur PHP avec le framework Phalcon

Il permet de créer une paire de clés publique/privée PGP qui sont utilisées pour chiffrer les communications entre toi et tes amis.

D'accord, mais comment ça marche concrètement ?

Lors de ton inscription tu crées donc une paire de clés publique/privée et tu choisis un nom et une passphrase (c’est comme un mot de passe mais pour « ouvrir » ta clé privée).
Seule la clé publique, le nom et le fingerprint (l'empreinte de la clé) sont envoyés sur le serveur.
La clé privée, elle, est sauvegardée dans le LocalStorage de ton navigateur.

Ensuite, tes amis s'inscrivent de la même manière et vous vous échangez vos noms et fingerprint afin de pouvoir communiquer ensemble.

Lorsque tu cliques sur un ami sur la page chat, tu peux lui envoyer un message et voilà ce qu'il se passe:

  • avec le fingerprint de ton ami, la librairie javascript retrouve la clé publique de l’ami dans le LocalStorage ou la demande au serveur.
  • une fois cette clé récupérée elle est utilisée pour chiffrer ton message et l'envoyer sur le serveur.
  • le navigateur de ton ami interroge régulièrement le serveur, et récupère les messages qui lui sont adressés.
  • le navigateur ouvre la clé privée grâce à la passphrase stockée dans le sessionStorage (c'est pourquoi si tu fermes l'onglet il faudra te reconnecter avec ta passphrase)
  • une fois la clé "ouverte" il déchiffre le message grâce à openPGP.js et l'affiche dans le chat.

OK mais chiffrer en Javascript ce n'est pas très robuste non ?

Oui je suis tout à fait d'accord, dans un premier temps le but de ce site est de démocratiser les communications chiffrées, de les rendre simple et accessible au plus grand nombre.

Dans un second temps j'ai prévu de créer une API REST qui permettra d'envoyer et récupérer les messages chiffrés afin de pouvoir les créer et les lire depuis d'autres services comme:

  • un autre site web, par exemple un forum
  • un site d'entreprise sur un réseau interne
  • une application cliente native sous linux
  • une application android

Oui c'est bien tout cela mais qu'est ce qui me garantit la sécurité des clés générées ?

Et bien pour le moment… rien !
À part le fait que tu peux récupérer tes clés sur la page "Compte" et donc les tester sur ton logiciel PGP préféré.

Ensuite je compte mettre en place la possibilité d'importer les clés directement dans le navigateur et de choisir de le faire dans le LocalStorage (sauvegardé même lorsque tu fermes le navigateur) ou dans le SessionStorage (directement détruit à la fermeture de la fenêtre ou de l'onglet).
Ainsi tu peux utiliser tes propres clés pour discuter avec tes amis.

Dans un troisième temps il faudra aussi que je mette en place la possibilité de récupérer les clés publiques via les serveurs de clés et non pas dans la base de l'application.

Pourquoi sortir ce site maintenant s'il manque autant de fonctionnalités de base ?

Je voulais le faire maintenant car cela fait un moment que l'idée trotte dans ma tête et que si je ne me lançais pas alors je ne l'aurai jamais sortie…

Et puis c'est avec tes retours et ceux qui voudront bien tester ET réfléchir à ce type d'application que je saurais vers où me diriger et ce qui doit être fait en premier.

Par exemple, je ne pense pas qu'il soit dur aux services de renseignements de déchiffré un message chiffrer avec la version Javascript de OpenPGP mais c'est surtout dans le volume des conversations chiffrées que cela aura un impact.

Plus le nombre de personnes utilisant le chiffrement augmentera, plus il sera long à ceux qui veulent t’écouter de déchiffrer tes conversations (à moins de te cibler directement et donc de t’avoir déjà identifié).

Ensuite, avec les nouvelles lois (LOPSI et autres), il sera bientôt obligatoire aux hébergeurs de fournir les données aux autorités, là, seuls les chats en attente de lecture sont stockés de plus ils sont tous chiffrés avec une clé différente par utilisateur, qui n’est pas sur le serveur (et que le serveur ne connaît jamais d'ailleurs).
Ce qui obligera les autorités à justifier leurs actions pour obtenir directement les clés auprès des personnes concernées, et non auprès des hébergeurs.

Une campagne IndieGoGo ?

J'ai aussi lancé une campagne IndieGoGo, pour essayer de me dégager du temps pour travailler sur ce site et sur d’autres outils pour favoriser le développement de solutions du même type.

Dans tous les cas je voulais te faire part de ce nouveau développement open source en licence Apache 2.

Bonne journée Nal,
Mémîks.

  • # cryptocat ?

    Posté par . Évalué à 6.

    Tu as regardé cryptocat qui est censé être ce qui se fait de mieux ?

    Ton architecture me pose quelques problèmes : la communication de message devrait se faire sans passer par le serveur, c'est maintenant possible sur un navigateur (cf Firefox Hello).

    Tu ne semble pas proposer de moyen contre les attaques "man in the middle". Cryptocat utilise le principe de forward secrecy. Cela revient avec PGP à conserver les clef publique de tes correspondants, et comprendre pourquoi une clef change.

    La passphrase de protection, en local, c'est un peu "léger". Il faudrait ajouter un secret (128 bits) sauvé dans le navigateur (voir un fichier complet ?). Un mot de passe "d'humain", cela se casse trop facilement.

    "La première sécurité est la liberté"

    • [^] # Re: cryptocat ?

      Posté par (page perso) . Évalué à 3.

      Effectivement je n'en ai pas parlé mais j'ai pensé aussi à CryptoCat.
      Et j'ai également pensé au forward secrecy.

      En fait le but a terme est de TOUT chiffré concernant l'utilisateur.
      C'est à dire :
      * avoir la liste des amis connu avec le fingerprint des clés publiques.
      * avoir pour chacun la dernière clé publique utilisée.
      * la clé publique des amis connus ne devrait changée et n'être acceptée QUE si la nouvelle est chiffrée avec l'ancienne etc…
      * signer et dater les messages envoyé avec sa clé privée.

      tout cela chiffré avec sa clé privée et stocké au choix en local sur le navigateur ou à distance sur le serveur.

      Pour le "secret" stocker dans le navigateur tu veux dire que ce fichier serait demandé en plus de la passphrase lors de l'ouverture de la session et ne SERAIT PAS stocké en local dans le localstorage ? car sinon on a la clé privée ET le secret au même endroit ce qui revient à n'avoir que la passphrase à trouvée non ?

      Effectivement j'ai aussi commencé à faire un chat en WebRTC afin que le serveur ne serve "que" de relais le temps d'établir la connection ;) merci de souligner ce point j'aurai du en parler.

      Dans un second temps il faudrait directement étendre cela à tout…
      les fichiers à partager via des clés générées et partagées pour l'occasion.
      Les pages web via un proxy PGP…

      etc…

      J'ai pas mal d'idées et de choses à mettre en place, merci pour les remarques constructives ;) ça me pousse à continuer.

      • [^] # Re: cryptocat ?

        Posté par . Évalué à 3.

        Si le fichier est en local, on peut imaginer qu'une faille de sécurité du navigateur serait insuffisant pour attraper le fichier en question à distance. Le principe est toujours d'avoir des couches de sécurité qui sont suffisantes et le plus indépendante possible.

        D'ailleurs, vu que le seul moyen d'avoir une discussion en PGP sans man in the middle avec une personne connu, est de vérifier le finger print de la clef depuis un autre canal, tu devrais aussi voir pour utiliser une clef symétrique. Les 2 personnes se débrouillent pour se refiler la clef (un fichier image ?).

        * avoir pour chacun la dernière clé publique utilisée.
        * la clé publique des amis connus ne devrait changée et n'être acceptée QUE si la nouvelle est chiffrée avec l'ancienne etc…

        Attention avec ces gestions de clef complexes, c'est facile que l'utilisateur fasse n'importe quoi. Si la clef est compromise, signer avec l'ancienne clef, ne sert à rien.

        J'avais pensé, à utiliser une autre clef privé caché qui signe celle qui est effectivement utilisé. Pour gérer le vol de compte, je pense même crypter cette clef privé avec une clef découpé avec sss ( https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing ) ce morceau de clef étant filé à des amis de confiance. Ceux-ci devraient filer le code si besoin. Je l'avais appelé la fuck-you key :) Car, c'est imparable si tu as des amis prudent. Le but est de gérer une sorte de révocation des clefs publiques proprement. PGP gère des grosses listes de clef révoqué, c'est lourd comme mécanisme.

        "La première sécurité est la liberté"

        • [^] # Re: cryptocat ?

          Posté par (page perso) . Évalué à 2.

          Si le fichier est en local, on peut imaginer qu'une faille de sécurité du navigateur serait insuffisant pour attraper le fichier en question à distance. Le principe est toujours d'avoir des couches de sécurité qui sont suffisantes et le plus indépendante possible.

          Effectivement c'est une bonne idée, ajouter des couches de sécurité supplémentaire.
          pourquoi pas d'ailleurs penser à un système ou la clé privée est elle même sécurisé par un schéma, ou un code pin, ou un fichier d'entropie oui…

          J'ai aussi pensé que je pourrais permettre deux couple de clés, un pour discuter avec les amis, l'autre utiliser pour archiver les discussion sur le serveur.

          D'ailleurs, vu que le seul moyen d'avoir une discussion en PGP sans man in the middle avec une personne connu, est de vérifier le finger print de la clef depuis un autre canal, tu devrais aussi voir pour utiliser une clef symétrique. Les 2 personnes se débrouillent pour se refiler la clef (un fichier image ?).

          J'avais pensé à utiliser un couple de clés PGP échangé lors de la connexion entre les amis celui qui crée le canal de conversation, génère une clé publique/privée qui est envoyé via la clé publique de chaque utilisateur pour chiffré les échanges juste pendant cette conversation (ce qui ne retire pas le fait que si la clé est corrompu, l'envoie de la clé de discussion également) mais on peux penser à un échange de ce couple par un autre canal (mail chiffré ou autre) ce qui permet aussi de convier d'autres personnes à une "conférence" sans échanger avec celles-ci ses propres clés.

          Attention avec ces gestions de clef complexes, c'est facile que l'utilisateur fasse n'importe quoi. Si la clef est compromise, signer avec l'ancienne clef, ne sert à rien.

          Au départ je ne voulais même pas enregistrer les clés publiques des utilisateurs dans la base, je ne l'ai fait que pour "simplifier" l'utilisation de l'outil, mais il est vrai que pouvoir vérifier les clés par un autre canal serait beaucoup mieux, et devrait pouvoir être fait.

          de plus ce qui devrait pouvoir être fait, c'est de signer sa clé publique "publique" (qui est stockée dans l'application) avec une clé privée qui n'est JAMAIS publiée (utiliser une fois à chaque renouvellement de clé et stocké dans un coffre derrière un pitbull, ou chez la belle mère).
          Du coup lors du changement de clé on peut vérifier celle-ci avec la signature de la clé publique "de référence" dont la clé privée est bien cachée.

          Nos amis devant vérifier que les clés publiques sont bien signées avec les clés "de confiances" (mais l'application peut s'en charger également).

          encore des idées à mettre en place.

          • [^] # Re: cryptocat ?

            Posté par . Évalué à 3.

            J'avais pensé à utiliser un couple de clés PGP échangé lors de la connexion entre les amis celui qui crée le canal de conversation, génère une clé publique/privée qui est envoyé via la clé publique de chaque utilisateur pour chiffré les échanges juste pendant cette conversation (ce qui ne retire pas le fait que si la clé est corrompu, l'envoie de la clé de discussion également) mais on peux penser à un échange de ce couple par un autre canal (mail chiffré ou autre) ce qui permet aussi de convier d'autres personnes à une "conférence" sans échanger avec celles-ci ses propres clés.

            C'est différent. La crypto asymétrique est connu pour être moins fiable que la symétrique (genre AES en XTS). Ce que tu proposes est différent, tu propose de refaire un échange de clef asymétrique jetable. Cela doit te donner la propriété de forward secrecy une fois la clef privé jeté. C'est pas mal, je pense.

            Fait aussi très attention à tes générateurs aléatoires, toute la sécurité repose dessus. Encore une fois, tu peux faire des couches : 128 bits d'entropie minimum par couche (genre /dev/urandom et une toutouille à toi) et le mélange des couches doit aussi être cryptographique et non un simple XOR (genre sha2). Attention à ne jamais dériver les clefs, tout doit être aléatoire.

            de plus ce qui devrait pouvoir être fait, c'est de signer sa clé publique "publique" (qui est stockée dans l'application) avec une clé privée qui n'est JAMAIS publiée (utiliser une fois à chaque renouvellement de clé et stocké dans un coffre derrière un pitbull, ou chez la belle mère).
            Du coup lors du changement de clé on peut vérifier celle-ci avec la signature de la clé publique "de référence" dont la clé privée est bien cachée.

            Ici, le problème est de faire simple. J'aime bien la propriété qui consiste à dire que l'on peut garantir un réseau si >50% des nœuds du réseau sont fiables. En gros, un noeud compromis ne peut tout compromettre. Dans ton cas, cela reviendrait à partager tes informations.

            Regardes les protocoles comme celui proposé dans la dépêche qui utilise git et bittorrent. Celui-ci te garanti contre tout modification (un serveur deviendrait membre d'un réseau et ne serait pas isoler). Tu dois même pouvoir rajouter une couche d'authentification en utilisant le réseau bitcoin.

            "La première sécurité est la liberté"

  • # Titre

    Posté par . Évalué à 5.

    Le titre me semble grammaticalement incorrect.
    D'un point de vue purement grammaire, je crois qu'il faudrait que ce soit "try to listen to me".
    Sauf que du coup, je ne pense pas que "listen" soit le bon terme.

    • [^] # Re: Titre

      Posté par (page perso) . Évalué à 1.

      Effectivement, j'ai essayé de faire simple et court mais je m'y suis mal pris…
      tant pis ce sera un "coquille" du coup…

      faudra que je corrige le nom.

    • [^] # Re: Titre

      Posté par . Évalué à 4.

      Oui, mais ce sera corrigé à la sortie de la version 2.

    • [^] # Re: Titre

      Posté par . Évalué à 2.

      Sauf que du coup, je ne pense pas que "listen" soit le bon terme.

      C'est eavedrop le bon terme.

  • # Annuaire clés publiques

    Posté par . Évalué à 3.

    Bonjour,

    ton projet est une bonne initiative même si je pense que la création d'un nouveau canal de discussion (il y en a tellement) pose problème. À l'heure actuelle et à ma connaissance, seul TextSecure (https://whispersystems.org/) permet une discussion asynchrone, chffrée, avec garantie de PFS. WhatsApp a déclaré qu'ils s'en étaient inspirés, mais sérieusement, quel utilisateur de WhatsApp croit au respect de sa vie privée?

    Je ne suis pas utilisateur de messagerie instantanée, car soit les garanties en termes de sécurité sont absentes, soit (comme pour XMPP), cela demande aux deux parties d'être connectées. Et cela est un souci. Je n'utilise pas non plus TextSecure car, pour l'instant, il repose encore sur le framework GCM de Google pour le Push de messages. En attendant l'implem à base de Websockets, je n'utilise rien d'autre.

    Reste donc les bons vieux mails, que j'utilise de façon non chiffrée car de toute façon, presque aucun de mes contacts ne connait tout cela. Mais je pense qu'à terme, un chiffrement massif des mails (il faudrait convaincre les gros providers de s'y mettre, et là c'est dur) serait une bonne chose. Reste le souci de gestion des clés. Autant pour la privée, je pense qu'il est possible de faire un truc bien, facilement déployable sur plusieurs devices, autant vérifier sa clé publique avec un autre canal de communication que celui qu'on utilise me semble lourd. Trop de gens accepteront la clé qu'ils voient sans réfléchir, ouvrant la porte à un MITM massif sur ces échanges.

    D'où ma question, connaissez vous des recherches ou des papiers parlant du problème de la distribution des clés publiques via un annuaire (comme une sorte de DNS de la crypto), de façon sécurisée? De sorte que si l'annuaire tombe entre les mains du vilain, les utilisateurs le voit. Et le tout, sans contrainte de connexion des deux parties simultanément (Diffie-Hellman).

    • [^] # Re: Annuaire clés publiques

      Posté par . Évalué à 2.

      Si on inclue la clef publique dans tout échange de mail entre 2 personnes, et que si la clef est présente, l'échange continu en crypté ?

      Si on veut de la vrai sécurité rien n'empèche de vérifier le finger print après coup. De plus, la NSA devrait modifier à la volé tous les messages qui circulent, cela me parait bien lourd.

      "La première sécurité est la liberté"

      • [^] # Re: Annuaire clés publiques

        Posté par . Évalué à 1.

        Je ne parlais pas de transmettre la clé pour chaque échange, j'ai du mal m'exprimer.

        Je précisais l'échange initial de clés publiques, nécessaire avant le premier mail. Aujourd'hui tu récupères la clé à la mano de ton correspondant et tu la rentres dans ton mailer. Pour le grand public, c'est trop complexe. Si cela était automatisé (via ton navigateur par exemple), comme une requête DNS pour récupérer l'IP, ce serait bien plus simple et ce serait un premier vrai pas vers le chiffrement grand public.

        Reste la possibilité de vérifier après coup le fingerprint, comme tu le dis, mais qui te dis que ton message ne sera pas modifié en cours (principe du MITM)? Quant au concept du "C'est trop lourd pour le faire à grande échelle", j'ai ravalé cela il y a un petit moment déjà…

        • [^] # Re: Annuaire clés publiques

          Posté par (page perso) . Évalué à 2.

          Un annuaire de clés comme celui la : https://keyserver.pgp.com/vkd/GetWelcomeScreen.event

          tu publies ta clé publique sur l'annuaire et l'application va chercher cette clé sur le serveur de clé et non sur trytolisten(to).me
          tu coups un "autre" canal est utilisé pour vérifier la clé (et le fingerprint).

          de plus OpenPGP.js vérifie forcément le fingerprint de la clé lors du déchiffrement du message.

        • [^] # Re: Annuaire clés publiques

          Posté par . Évalué à 2.

          Je ne parlais pas de transmettre la clé pour chaque échange, j'ai du mal m'exprimer.

          C'est moi qui proposait cela, car cela a plein d'avantage dont la simplicité.

          Reste la possibilité de vérifier après coup le fingerprint, comme tu le dis, mais qui te dis que ton message ne sera pas modifié en cours (principe du MITM)?

          Non pas du tout. C'est ton correspondant qui doit te donner son fingerprint par un autre canaux. De ceux point de vue là, cela ne change rien avec la méthode PGP classique.

          "La première sécurité est la liberté"

    • [^] # Re: Annuaire clés publiques

      Posté par (page perso) . Évalué à 2.

      ton projet est une bonne initiative même si je pense que la création d'un nouveau canal de discussion (il y en a tellement) pose problème. À l'heure actuelle et à ma connaissance, seul TextSecure (https://whispersystems.org/) permet une discussion asynchrone, chffrée, avec garantie de PFS. WhatsApp a déclaré qu'ils s'en étaient inspirés, mais sérieusement, quel utilisateur de WhatsApp croit au respect de sa vie privée?

      Effectivement je ne crois pas au respect de la vie privée de ces applications, c'est aussi cela qui me pousse à développer une autre alternative.

      Je ne suis pas utilisateur de messagerie instantanée, car soit les garanties en termes de sécurité sont absentes, soit (comme pour XMPP), cela demande aux deux parties d'être connectées. Et cela est un souci. Je n'utilise pas non plus TextSecure car, pour l'instant, il repose encore sur le framework GCM de Google pour le Push de messages. En attendant l'implem à base de Websockets, je n'utilise rien d'autre

      En fait je dis "chat" et "discussion" mais ce n'est pas réellement de l'instantané, si tu cliques sur un amis et que tu lui envoies des chats alors qu'il n'est pas connecté, il les recevra lorsqu'il cliquera à nouveau sur toi. par contre il seront supprimés dés qu'il les aura reçus.
      Du coup pas la peine que les deux soient connectés en même temps.
      Tu peux laisser des messages à ta douce sans qu'il me soit possible de les lire.

      D'où ma question, connaissez vous des recherches ou des papiers parlant du problème de la distribution des clés publiques via un annuaire (comme une sorte de DNS de la crypto), de façon sécurisée? De sorte que si l'annuaire tombe entre les mains du vilain, les utilisateurs le voit. Et le tout, sans contrainte de connexion des deux parties simultanément (Diffie-Hellman).

      C'est une bonne question, je n'ai pas d'exemple à te donner, par contre on peux aussi ajouter un facteur humain, un message qui doit être envoyé lors de l'envoie d'un nouvelle clé, et les amis prennent la décision du message et son contenu dans un lieu en dehors de ce canal, par exemple "lorsque je change de clés je te dis : tiens il poule aujourd'hui ? et tu dois me répondre "oui effectivement mais j'aime le chocolat" etc… ?
      mais pour cela il va falloir éduquer les peuples, le but de cette application est justement de déployer des alternatives.

      ton projet est une bonne initiative même si je pense que la création d'un nouveau canal de discussion (il y en a tellement) pose problème.

      Oui je me suis aussi posé la question d'utiliser XMPP mais cela est beaucoup trop lourd à mettre en place pour tout un chacun. et pour l'adoption dans d'autres solutions.
      La au moins, avec un navigateur, et un peu de temps, tout le monde peut l'utiliser.

      Avec une API JSON/REST on peut interfacer des applications et d'autre sites web pour créer un chat chiffré sur d'autre devices.

      Oui tu as raison, je ne veux pas non plus d'une plateforme propriétaire ni trop dur à faire évoluer ni d'ailleurs refermée sur elle même.

    • [^] # Re: Annuaire clés publiques

      Posté par (page perso) . Évalué à 3.

      La distribution de clé est le point noir qui empêche gpg de se déployer. Google et Yahoo ont annoncé il y a un moment vouloir mettre du PGP dans le webmail, et passer par leur propre solution pour cette distribution. C'est un mécanisme assez touffu, j'ai pas tout compris, mais si ça te chante le wiki est ici. Il y a une analyse assez approfondie du problème.

      • [^] # Re: Annuaire clés publiques

        Posté par . Évalué à 1.

        Merci beaucoup pour ce lien. J'ai pris le temps de creuser un peu le sujet et voici un résumé de ce que j'ai compris. Si j'ai écrite une bêtise, merci de me corriger.

        Le problème de la distribution de clés revient exactement au même problème des certificats pour l'accès sécurisé à certains sites/services (SSL). C'est très logique mais sincèrement je n'avais pas fait le rapprochement. De là, on peut regarder les solutions à ce souci.

        Parmi celles-ci, on compte:
        - Convergence
        - Certificate Transparency (CT)
        - DNSChain

        Convergence, proposé par Moxie, l'auteur de TextSecure, propose en gros de remplacer les CA par un ensemble de pairs qui valident un certificat. En gros, plusieurs identités doivent répondre oui à la question "Mon certificat est-il le bon?".

        Certificate Transparency, tout comme DNSChain, prone l'emploi d'hash tree, ou Merkle tree, utilisé entre autres dans Git ou encore Bitcoin. En gros, on crée une chaîne de blocs communes pour tout le monde, dont chaque noeud est un hash de ses fils. Cela résout le problème élégamment mais pose celui de la réconciliation, c'est à dire d'obtenir le même arbre pour plusieurs opérations se déroulant sur différentes machines. Et de ce côté là, les 2 diffèrent:

        • Certificate Transparency propose de centraliser, et accessoirement que des moniteurs doivent être en place pour vérifier le contenu de l'arbre.
        • DNSChain quant à lui propose une réconciliation différente (plutôt dans l'esprit de Bitcoin) pour que la vérif puisse se faire directement depuis les valeurs de l'arbre.

        Vous l'aurez compris, la diff entre les 2 me semble encore un peu mystérieuse…
        En tout cas, une personne de DNSChain a répondu à CT pour contredire certains points: http://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/

        Moralité, tout n'est pas clair dans mon esprit mais une fois le problème sécurisé de l'accès à des sites résolus, on pourra utiliser cette solution pour la diffusion de clés publiques pour les adresses mails.

        Quant aux clés privées, un simple stockage temporaire chiffré avec de l'AES-256 et une passphrase d'au moins 25 caractères devrait permettre la synchro facile entre devices. Bon ça c'est mon idée.

        • [^] # Re: Annuaire clés publiques

          Posté par . Évalué à 1.

          Pour approfondir un peu: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md

          En gros, CT maintient le concept de CA mais leur demande de vérifier le contenu du log émis (pour voir qu'aucun nouveau certificat n'a été émis). Cela rejette donc la sécurité sur eux et permet une détection de problèmes seulement après une brèche. C'est donc moyen.

          DNSChain offre de son côté de plus solides garanties. C'est le même algo que Bitcoin qui est utilisée, sauf que la monnaie a été modifiée pour attacher des données sur chaque noeud: Namecoin. On associe donc une monnaie virtuelle à un système de gestion de noms de domaines.

          Tout comme Bitcoin, la sécurité est offerte par le fait qu'un attaquant doit disposer d'une puissance de calcul colossal pour dépasser celle de tous les autres noeuds du réseau. De plus, chacun peut créer gratuitement son identité, plus besoin d'avoir des CA ou un provider de mail qui fait ce boulot contre rémunération.

          Et apparement, Namecoin gére déjà la gestion d'identité (et c'est même implémenté dans certains outils): https://wiki.namecoin.info/?title=Identity

  • # Webapp

    Posté par . Évalué à 3.

    Le seul moyen que je vois pour fournir une garantie à l'utilisateur (qui s'y intéresse) que la crypto est bien utilisée correctement (notamment que la clé privée n'est pas communiquée au serveur) est de faire une webapp (packagée, pas hébergée). Le code reste vérifiable (s'il est bien écrit ;-)) et c'est toujours aussi facile à utiliser : sur un navigateur de bureau ou sur un téléphone (android ou firefox os).
    Ça peut aussi permettre d'ajouter des fonctionnalités si on est sur un téléphone (tout en restant compatible desktop), comme par exemple associer un contact enregistré sur trytolisten.me¹ à un contact du carnet d'adresses du téléphone (avec sa photo par exemple).

    ¹ Sérieusement, pourquoi pas trytolistenTO.me ?

    • [^] # Re: Webapp

      Posté par (page perso) . Évalué à 1.

      Oui la webapp est à faire et partager le package et le code sur le github pour ceux qui veulent la vérifier ;)

      pour le nom :/ désolé je vais changer cela… pourquoi ? un moment d'égarement je suppose.

  • # pourquoi moins robuste en JS ?

    Posté par (page perso) . Évalué à 1.

    Pourquoi tout le monde dit que chiffrer en JavaScript ce n'est pas très robuste ? Il existe plusieurs implémentations de RSA (par exemple) et je ne comprends pas pourquoi cela serait moins robuste qu'avec un autre langage.

    • [^] # Re: pourquoi moins robuste en JS ?

      Posté par . Évalué à 1.

      C'est peut-être l'expression qui est mal choisie.
      Ce n'est pas que ce n'est pas robuste, c'est que si le code javascript est donné dynamiquement à l'utilisateur, il ne contrôle pas son contenu, et ne peut donc pas être sûr qu'il chiffre bien correctement ses messages.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.