Journal Les solutions cryptographiques aujourd'hui : le simple et le compliqué

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
12
12
juin
2015

Bonjour Nal,

C'est vendredi, alors c'est un bon jour !

La cryptographie, c'est compliqué, et sa mise en œuvre est un champs de mines. C'est bien beau tout ça, mais on est en droit d'en attendre quoi aujourd'hui ?

Je vous propose de voir ce qui est simple et ce qui ne l'est pas, d'un point de vu centré sur l'utilisateur.

Chat entre deux personnes (anonyme)

C'est un terrain connu, et l'idée même est déjà utilisée par les réseaux informatiques. OTR est un protocole bien connu pour cet usage qui garantit votre anonymat, et la sécurité des échanges textuels (et de transferts de fichiers).
Il existe également ZRTP pour les appels audios/vidéos.

Quelques exemples de logiciels utilisant OTR :

  • Pidgin ;
  • Kopete ;
  • Chatsecure ;
  • Signal ;
  • TextSecure ;
  • Cryptocat.

Il est à noter qu'OTR permet de vérifier que votre correspondant est bien la personne à qui vous souhaitez parler (depuis la version 3).

Quelques logiciels utilisant ZRTP :

  • Signal ;
  • Linphone ;
  • Jitsi.

C'est quelque chose de simple, et que les utilisateurs sont en droit d'attendre aujourd'hui.

Chat entre plusieurs personnes (anonyme)

OTR ne permet pas de discuter entre plus de 2 personnes simultanément. Ce protocole n'ayant pas encore évolué pour cela, on retrouve de multiples endroits où ce manque est comblé : mpOTR et OTR ratchet par exemple.

Cryptocat est le principale utilisateur de mpOTR (et aussi celui qui le propose), alors qu'OTR ratchet est l'œuvre d'Open Whisper System, à l'origine de Signal/Textsecure.

Si on arrive à le standardiser, le chat groupé ne devrait plus être quelque chose à ré-inventer par tout un chacun.

Aujourd'hui, ceci pourrait être plus simple que ça ne l'est.

Chat décentralisé (anonyme)

Se passer de serveurs relais pour discuter pourrait devenir une réalité accessible un jour, grâce à une vision P2P des choses.

Néanmoins, ce n'en est qu'à ses début, et ce n'est pas fiable. Ce n'est pas standardisé.

Quelques exemples : bleep, Tox, otr.to, etc.

Communications authentifiés (non interactives)

La gestion des identités est un point difficile, ce qui rend la communication par courriels difficile entre deux personnes. On retrouve ici GPG et la gestion à la main de clés privées et publiques.

C'est quelque chose de difficile, et on n'a pas encore trouvé comment rendre ça simple dans l'état actuel des choses.

Peut-être que la prochaine avancée serait la mise en place d'un nouveau protocole pour la gestion des courriels (autre que smtp(s)ou imap)

Petite aide quant aux choix d'applications

Je voudrais finir en rappelant ce que la cryptographie implique quant à une solution :

  • la solution doit être connue de tous (utilisation de standards, et solution ouverte) ;
  • la sécurité de la solution doit être prouvée (utilisation de standards, et revues de sécurités fréquentes).

Quelques exemples qui sont donc contraires à cela :

  • Notre solution est la meilleure, ouverte, mais on cherche du monde pour vérifier notre code ;
  • Notre solution utilise une librairie ouverte X, mais comment on l'utilise, ça on ne peut pas vous le dire, sinon on ne ferait pas de bénéfices. Mais on vous promet (variante : une certaine dose de confiance est nécessaire, de toutes façons) ;
  • On ne fait pas de revues extérieures, car c'est trop cher, mais promis, on fait vraiment attention à ce que l'on fournit.
  • C'est pas ouvert, mais vous ne savez pas vraiment comment vérifier que ce que vous exécutez est le code que vous liriez de toutes façons ;
  • etc.

Fin

Bref :

  • discuter à deux ne devrait plus être un problème de manière anonyme ou pas (à la « je vérifie ton identité en scannant ton QRCode » par exemple), et ceci avec transferts de fichiers.
  • discuter à plusieurs est en passe de devenir aussi simple, mais c'est pas tout à fait le cas ;
  • envoyer des courriels signés et chiffrés, c'est pas simple du tout.

Bon vendredi !

  • # gpg as chat

    Posté par  (site web personnel) . Évalué à 2.

    Ce n'est pas possible de commencer un échange de message chiffré par gpg, tout comme on commence un échange de chat crypté ? En utilisant le même genre de protocole, mais appliqué sur le mail ?

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

    • [^] # Re: gpg as chat

      Posté par  (site web personnel) . Évalué à 2.

      Le truc qui rend les choses difficiles, c'est que la communication par courriel n'est pas interactive : tu envoies, l'autre lis plus tard et te réponds encore plus tard.

      Les protocoles de messagerie instantanées utilisent le fait que les personnes sont là en même temps pour faire un échange au début, et se mettre d'accord sur une clé commune à l'échange.

      C'est d'ailleurs pour ça que l'on a créé le chiffrement y clés publiques : tu te mets d'accord tout seul sur une clé, et l'autre va la reconstruire après. Mais cela nécessite de connaître la clé publique de l'autre à l'avance, d'où le problème de gestions des clés…

      • [^] # Re: gpg as chat

        Posté par  . Évalué à 3.

        Les protocoles de messagerie instantanées utilisent le fait que les personnes sont là en même temps pour faire un échange au début, et se mettre d'accord sur une clé commune à l'échange.

        Je vais parler d'XMPP. Alice et Bob discutent avec XMPP
        Et comment Alice sait qu'elle parle bien à Bob ? Elle fait confiance au serveur de Bob.
        Comment sait elle qu'elle parle bien avec le serveur de Bob ? En faisant confiance à son serveur pour le vérifier avec de la crypto symétrique, qui se fait grâce à un certificat signé, on fait aussi confiance à la boite qui a signé le serveur de Bob.

        C'est plus simple, mais il y a besoin de faire confiance à plus d'acteur (3 acteurs), donc c'est moins sur.

        Dans le cas des mails avec GPG, on ne fait confiance qu'explicitement aux personnes, c'est plus sûr, et donc et plus compliqué.

        Il n'y a pas de solution miracle.

        Please do not feed the trolls

  • # confus

    Posté par  (site web personnel, Mastodon) . Évalué à 9.

    L'intention de citer les solutions actuellement pour le chiffrement de bout en bout est louable, mais ce journal me semble un peu confus, et surtout erroné !

    OTR ne permet pas l'anonymat ! Tu confonds peut-être avec le « perfect forward secrecy » qui permet de ne pas compromettre les conversation antérieur si une clef est interceptée.

    Il faut coupler à quelque chose comme TOR pour avoir un semblant d'anonymat.

    Il est à noter qu'OTR permet de vérifier que votre correspondant est bien la personne à qui vous souhaitez parler (depuis la version 3).

    ça aussi c'est faux, il est bien possible de vérifier l'identité de la personne avec OTR v2 par exemple, c'est juste qu'il faut utiliser des « fingerprint » (une séquence de caractères à vérifier), alors qu'avec la version 3 on peut utiliser une question sans passer par un canal extérieur.

    Chat décentralisé (anonyme)

    Les messageries (libres) classiques sont souvent décentralisées, tu parles de P2P là (d'ailleurs tu le précises). Là aussi l'anonymat est une chose séparée, même si certains cherchent à l'inclure nativement dans leur projet.

    Bon ceci dit, c'est toujours bien de parler de tout ça, donc merci pour le journal :)

    • [^] # Re: confus

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 12 juin 2015 à 13:35.

      OTR ne permet pas l'anonymat ! Tu confonds peut-être avec le « perfect forward secrecy » qui permet de ne pas compromettre les conversation antérieur si une clef est interceptée.
      Il faut coupler à quelque chose comme TOR pour avoir un semblant d'anonymat.

      J'ai mal utilisé le mot anonymat finalement. Tant que tu ne t'es pas authentifié, t'es « anonyme ».
      Bon, mais en fait, c'est pas vraiment correct.

      L'anonymat, c'est le fait de ne pas pouvoir être identifié, alors que là c'est le fait que ça puisse être n'importe qui au bout du fil (de la conversation OTR).

      Désolé pour l'erreur !

  • # Erreur

    Posté par  (site web personnel) . Évalué à 5.

    OTR, le protocole de forward secrecy, n'est pas utilisé par TextSecure, comme tu le dis toi-même; ils utilisent leur propre protocole (Axolotl) qui permet d'être réellement asynchrone (ie envoyer des messages même quand l'autre n'est pas connecté), ce qui permet d'ailleurs d'avoir un support pour la discussion de groupe simple contrairement à mpOTR qui galère comme pas possible.

    Seul problème: c'est encore pas répandu. J'ai une entrée dans ma TODO-list pour voir comment utiliser XMPP avec, mais comme ma TODO-list fait 200km de long…

Suivre le flux des commentaires

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