Journal Messagerie instantanée sécurisée (fortement)

Posté par .
Tags : aucun
9
28
sept.
2010
Cher journal, en effet, je réfléchissais ces derniers jours à ce sujet...

J'observe les communautés de tchatteurs sur l'Internet et je me suis demandé comment penser un tchat sécurisé. J'entends par là le chiffrement du mot de passe de connexion bien sûr, mais aussi le contrôle d'intégrité de chaque post émis/reçu (ainsi que l'authenticité de l'auteur de chaque post émis/reçu) et encore le chiffrement optionnel des posts. Il ne s'agit pas, pour l'instant, de sécurité forte au sens d'une multiplicité de signes authentifiants à produire (exemple clé privée de chiffrement + empreinte digitale).

Le premier problème étant de limiter l'infiltration d'un tchat par des "agents compromis" (des pirates), une fois l'authenticité garantie (même en tant qu'anonyme, avec une référence) et l'intégrité des messages garantie, (avec ou sans chiffrement des messages), le reste est affaire de confiance qui se développe avec le temps, selon ce qui peut s'observer des comportements sur le tchat.

Je développe ci-après tout cela, mais sache déjà, Oh mon journal, que si te vient l'idée de susciter des propositions d'architecture logicielle, n'hésite pas ! Je ne connais pas l'état de l'art hors Pidgin (client libre de messagerie instantanée - on peut lui ajouter OTR, une extension de chiffrement à la volée) et le Flash-qui-pue en tant qu'utilisateur, mais j'ai pondu une sacrée réflexion argumentée sur les tenants et aboutissants de la sécurisation d'un tchat (avec quelques contraintes simples) !


Les enjeux fonctionnels sont donc :

a) Rendre possible l'authentification par mot de passe chiffré a un très grand intérêt. Avec les tchats en Flash qui pullulent sur le web, il est peu probable que ce soit le cas, le mot de passe transite probablement en clair (non chiffré) sur l'Internet. Le code source du module de tchat en Flash n'est pas publié, l'hébergeur du service est typiquement hors de contrôle. Le mot de passe serait ainsi interceptable. Pour aller au bout de la démarche, il faut maitriser la technologie, c'est à dire contrôler le serveur de tchat et le code qui y tourne, sinon on peut toujours se tamponer pour l'authentification un peu "forte", même si le mot de passe est chiffré.

b) Donner la possibilité de contrôler l'intégrité des échanges (conformité entre ce que j'envoie et ce qui est reçu) a un très grand intérêt, complémentaire du point a). Car... si des agents mal-intentionnés s'en donnent les moyens, tant que n'est pas mis en oeuvre un contrôle d'intégrité systématique de tous les posts échangés sur le tchat (par clé cryptographique (1)), il est possible que les messages que l'un reçoit de l'autre soient trafiqués à la volée, par rapports à ceux que l'autre voit sur son écran comme émanant de lui-même (renvoyés en écho par le serveur ou l'application en local avec du Javascript/Flash/Java). Il peut y avoir une injection/modification de trames entre le serveur de tchat et le destinataire (ou les destinataires, selon... et sélectivement), il suffit aux agents malintentionnés de contrôler un des points de passage du trafic vers le destintaire, un des routeurs de cette route donc, comme le FAI du destinataire par exemple...
(1) signature GPG, signature SHA-1 ? (pas MD5, on sait qu'il peut y avoir collision de signature).

Notons à ce stade, un facteur de risque : si le PC d'un des participants est correctement piraté (un cheval de Troie ayant ouvert une porte dérobée par exemple), tout ce que cet utilisateur émet est modifiable par le pirtate.

c) Rendre illisible les échanges par chiffrement peut présenter un intérêt. L'intérêt peut se manifester pour les échanges en Messagerie Privée (éventuellement à plus de deux interlocuteurs), selon le besoin. Ici, si le PC d'un des participants est corrompu, tout ce que l'utilisateur voit peut être visible pour le pirate. Si on veut échanger en mode chiffré (exemple avec GPG : clé publique/privée), dans la mesure où la maitrise du serveur est assurée, la machine et le code qu'elle exécute peuvent être considérés comme étant de confiance, auquel cas elle peut lire le contenu des échanges chiffrés et authentifier tous les post transmis avec sa propre signature GPG privée authentifiante ! Si le serveur n'est pas complètement sous contrôle ou si l'on veut absolument garantir la confidentialité entre une sous-partie quelconque des tchatteurs, il suffit pour le serveur de relayer les posts constitués de telle façon qu'il y en a autant d'émis par le posteur qu'il y a de destinataires dans le sous-groupe : ils sont chiffrés par l'émetteur en autant d'exemplaires qu'il y a de destinataires, avec leur clé publique respective, et avec une authentification systématique par la clé privée de l'émetteur. A noter : dans le premier cas, le serveur peut enrichir les posts émis (avec génération de liens cliquables, intégration des vidéos en vignette à la place des URL, etc) - mais tout ce traitement peut aussi être fait localement à chaque machine -. Dans le deuxième cas, aucune inspection et enrichissement des posts émis ne peut avoir lieu sur le serveur.


Compatibilité avec l'anonymat et la participation d'un collectif d'auteurs :

Si un utilisateur se présente en anonyme (en passant par le réseau TOR par exemple), il peut être "authentifié" par un compte qui n'est pas relié à une identité définie, il produit donc un commentaire en tant qu'anonyme référencé, l'ensemble de ses contributions seront reconnues comme venant du même auteur (voire d'un collectif d'auteur, qui partagerait cette clé privée). Ainsi la crédibilité de cet anonyme référencé lors d'une contribution sera fonction de la crédibilité des ses contributions antérieures, lues par la communauté.


Lorsque l'on regarde l'état de l'art en Flash...

On voit à l'oeuvre une technologie sur laquelle on n'a que très peu de maitrise, avec des mots de passe qui transitent probablement en clair entre le client et le serveur, un serveur hébergé par une entreprise commerciale, tout ça avec de l'injection de trame possible tout le long du chemin, du fait de l'absence de contrôle d'intégrité (entre ce qui est émit par toi et reçu par moi, par exemple). On sait que Flash est une technologie "propriétaire" (propriété d'Adobe), dite fermée (code source inaccessible), pleine de failles de sécurité. La communauté du logiciel libre dépense beaucoup d'énergie pour faire une (en fait des) extension(s) pour les navigateurs (ainsi qu'un logiciel de visualisation indépendant) qui puisse exploiter le code Flash, avec une technologie ouverte. Pour réaliser cela, il faut faire de la rétro-ingénierie sur le FLASH d'Adobe, ce qui est pénible, mais tellement nécessaire que c'est fait.


Je résume ainsi les principes à mettre en oeuvre pour tendre vers une solution (passage au HTML/Javascript et/ou applet Java côté client) :

En quittant le Flash, on obtiens des points positifs :
- plus rapide (le Flash est gourmand en ressource machine)
- sans les trous de sécurité de Flash
- capacité d'indexation par les moteurs de recherche actuels (par ex pour un tchat qui sert de fil d'actualité)
- possibilité d'authentification avec *chiffrement du mot de passe* (qui ne transite pas en clair vers le serveur)
- possibilité de contrôle d'intégrité de chaque post (conformité entre ce qui est envoyé par l'un et reçu par les autres)
- possibilité de chiffrement des échanges (confidentialité)
- maitrise des algorithmes (logiciel libre) / de l'hébergement (maitrise du devenir des données) // Ce point n'est probablement pas un plus côté serveur, je crois qu'il y a au moins un serveur libre de bytecode ActionScript opérationnel. Côté client, en libre, c'est de toute façon encore problématique pour l'instant.
- maitrise des opérations de sauvegarde/restauration pour l'historisation du tchat (exemple du fil d'actualité)

Point négatif :
- Si le client est purement HTML, il n'y a pas d'intégration des vidéos en vignette (cliquable pour déclencher la vidéo en fenêtre popup) comme dans un contexte flash typique (à moins que, avec l'arrivée de la balise dans le HTML version 5, c'est à voir). Si client Java, pas de limitation. Notons que c'est une caractéristique un peu secondaire : en cliquant un lien, on peut l'avoir dans une autre fenêtre superposable au tchat (mais perte d'avant plan de la vidéo lors de rédaction sur le tchat), ou un autre onglet.

Je considère les contraintes suivantes : le tchat doit rester accessible depuis une simple page HTML - en consultation comme en contribution, en tant qu'anonyme non authentifié, sans nécessiter un logiciel client dédié. Idéalement, toutes les opérations avec authentification seront aussi possible depuis une page HTML. Ainsi, un même tchat doit pouvoir être répliqué sur différents blogs.


Discussion sur la solution technique :

Un client java (applet) avec un serveur Irc peut s'envisager. Les utilisateurs connus auraient un compte avec mot de passe chiffré, contôle d'intégrité et authentification des messages, ainsi que leur chiffrement optionnel. Java est disponnible pour tous les systèmes d'exploitations (une très vaste majorité). Java est lourd (alourdissement du poste client - au moins au démarrage, et en phase de croisière pour les petites machines -, car finalement, il est rare qu'il soit chargé quand on surfe) mais cela permet un meilleur contrôle (on peut garantir une bonne qualité de chiffrement) et évite que les messages postés sur le tchat ne se retrouvent archivés par les moteurs de recherche. Si le référencement (qu'un lien puisse pointer vers ce contenu) est utile, l'usage du Java (applet) est exclu côté client.

Je vois un problème avec l'applet Java, du fait des contraintes d'accessibilité d'une part, depuis une simple page HTML [je le définissais ainsi : en consultation comme en contribution, en tant qu'anonyme non authentifié, sans nécessiter un logiciel client dédié (idéalement, toutes les opérations avec authentification étant aussi possible depuis une page HTML)] ; d'autre part, du fait de la possibilité souhaitée de pouvoir répliquer le tchat sur divers blogs.

On peut envisager {PHP|Java|...} (côté serveur) et HTML/Javascript (côté client).
Par exemple, fonctionner en PHP avec un certificat SSL donc un chiffrement d'office (du mot de passe en 2048 bits et des données en 256 bits), ce qui contraint au chiffrement systématique des messages (quoiqu'un mécanisme doit pouvoir permettre d'échanger en mode non chiffré à la demande). Si le serveur est en Java, il peut générer du HTML/javascript pour le client. Dans cette configuration, on doir utiliser Javascript pour réaliser le contrôle d'intégrité/d'authenticité des messages envoyés/reçus (qui nécessitent un calcul programmé sur le poste client) ainsi que le chiffrement optionnel (pour éviter le chiffrement systématique par SSL).


Pour référence, quelques vidéos d'actualité :

1) Le président de la CNIL, "Alex TÜRK", dénonce la dérive totalitaire galopante du Système.
19-05-2010 - LCP - Commission "Droits de l'individu, et révolution numérique" (en 3 parties).
1/3 : http://www.dailymotion.com/video/xeh2uu_commission-sur-la-di(...)
2/3 : http://www.dailymotion.com/video/xeh32m_commission-sur-la-di(...)
3/3 : http://www.dailymotion.com/video/xeh3p6_commission-sur-la-di(...)

2) http://lacantine.ubicast.eu/videos/anonymat-identites-numeri(...) notamment à la minute 77 environ (pour 5 ou 6 minutes). On y entend quelques informations sur le risque que présente la consultation de pages web qui font appel à l'interface de programmation de Facebook (par du code javascript qui s'exécute à votre insu, bien sûr, le code de l'API ou Application programming interface de FaceBook). Cela peut se produire lorsque vous êtes connectés à votre compte facebook sur un autre onglet du navigateur. Votre activité en ligne sur le site qui fait appel à l'interface de programmation de Facebook est alors connue par le service Facebook ! On peut imaginer qu'un problème similaire existe avec Yahoo, Gmail ou autres services.
  • # Retroshare

    Posté par . Évalué à 2.

    Salut,
    pour répondre en partie à ton besoin, il existe Retroshare. C'est un réseau de type a-centré où la sécurité est basée sur un échange de clés GPG. Avec lui tu peux tchater, échanger des fichiers, il y a même un système de forum et un système de mail.

    Après, je ne l'ai pas trop utilisé mais bon.

    Voilà
  • # Rapidement

    Posté par . Évalué à 3.

    J'ai pas tout lu. Mais j'avais déjà réfléchit au même problème pour le mail.

    L'idée global provient d'un article de Guillomovitch concernant son aversion des key signing parti. Son argument est que l'on se fout de savoir qui est exactement derrière une clef, du moment que c'est toujours la même personne depuis le début des communications.

    Dans le cas d'un échange de mail, cela revient à signer le mail et fournir la clef publique avec chaque mail. Si la clef change, c'est que ce n'est plus la même personne derrière.

    L'idée est en fait de lier les messages cryptographiquement entre eux.

    L'intérêt est de ne plus avoir besoin obligatoirement de tier de confiance, pour échanger les signatures de clef.

    Concernant les hash et les algo de cryptage, les satellites TV utilisent un cryptage fermé qui n'est toujours pas cassé. Le principe est d'avoir 2 algo complètement différent, utilisant des principes différents. Pour casser le chiffrement, il faut absolument casser les 2 algo en même temps. Il faut qu'il y est une vrai indépendance sur les clefs.

    Concernant le hash, cela revient à fournir 2 hash d'algo différent. Genre sha-256 et md5sum. Il est difficile de trouver une collision sur un algo alors sur 2 en même temps...

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

    • [^] # Re: Rapidement

      Posté par . Évalué à 2.

      Dans le cas d'un échange de mail, cela revient à signer le mail et fournir la clef publique avec chaque mail. Si la clef change, c'est que ce n'est plus la même personne derrière.
      Que fais tu du cas où quelqu'un est victime de "man in the middle" dès le début ? Dans ce cas le pirate peut prendre la place de l'intervenant sans changer de clef.
      • [^] # Re: Rapidement

        Posté par . Évalué à 2.

        Oui, c'est la raison d'être des key signing party.

        Sauf que c'est un cas plus que théorique qui n'a presque aucun intérêt.

        En gros, il est plus important de relier les messages entre eux, que d'être sûr de la réelle identité de la personne. Et si un jour tu as réellement besoin de cette identité réelle, tu peux toujours vérifier la signature par d'autres canaux.

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

        • [^] # Re: Rapidement

          Posté par . Évalué à 4.

          Oui mais lier les message entre eux n'est pas aisé pour autant.

          Imaginons que titi intercepte TOUTES les communications de toto sur la communauté bidule, en les resignant à la volé avec une clef que titi possède (man in the middle depuis le début). À tout moment titi peut prendre la place de toto. Et au niveau uniformité clefs utilisées dans les messages, il y a aucun problème.

          Donc non tu as besoin de vérifier le lien entre la clef et la personne, et non juste pour vérifier une identité réelle.

          Par exemple quelqu'un que je connais depuis 3 ans, pour le signer, je ne vais pas demander une piece d'identité, j'en ai rien a foutre qui se balade sous un faux nom aux yeux de la république, mais je veux vérifier l'adéquation entre sa clef et sa personne. Par contre je ne vais pas pour autant le signer sans qu'il me fournisse sa clef lui même directement, quelqu'un peut avoir intercepté tous les modes de communications qui nous lient.

          Sauf que c'est un cas plus que théorique qui n'a presque aucun intérêt.
          Il est théorique si on ne lui donne pas la possibilité d'être applicable en pratique.
          • [^] # Re: Rapidement

            Posté par . Évalué à 2.

            Merci, je connais les attaques man-in-the-middle.

            Le problème des key signing party est que cela peut être très complexe pour des personnes à l'autre bout du monde.

            Cela concerne seulement les personnes en contact peu de temps. un peu comme les personnes qui utilisent une fausse adresse mail pour se faire passer pour quelqu'un d'autre.

            L'avantage de ma solution est d'être complètement automatique et "forte". Pas besoin de signer d'autre clef (à part les siennes si on en a plusieurs), pas besoin de serveur de clef, pas de gestion de trousseau, etc...

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

            • [^] # Re: Rapidement

              Posté par . Évalué à 1.

              Cela concerne seulement les personnes en contact peu de temps. un peu comme les personnes qui utilisent une fausse adresse mail pour se faire passer pour quelqu'un d'autre.
              Dans ce cas l'attaquant peut très bien se faire passer pour quelqu'un d'autre, et ta solution ne prévient pas ce genre de cas.


              L'avantage de ma solution est d'être complètement automatique et "forte"
              Je ne vois pas en quoi ta solution est forte, tu ne te base sur qu'une source de la clef (les messages originaux) qui peut être compromise.

              Imaginons une communauté de gens communiquant sur une mailing list, imaginons un attaquant qui a accès au logiciel de gestion de la ML. L'attaquant génère une nouvelle clef pour chaque nouvel intervenant, qu'il utilise ultérieurement dans toutes les falsifications du même intervenant. Puis il peut à tout moment prendre la place de chaque intervenant sans que ton système de lien cryptographique ne voit quelque chose.
              • [^] # Re: Rapidement

                Posté par . Évalué à 2.

                Si une personne envoit un mail par ailleurs, celui qui reçoit le mail, voit immédiatement le problème.

                De plus, avant de se faire hacker, la ml fonctionnait, les clefs ont déjà été échangé. Au moment du hack, le changement de clef se voit tout de suite.

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

                • [^] # Re: Rapidement

                  Posté par . Évalué à 1.

                  Qui te garantie que tu peux avoir confiance à ceux qui gère le logiciel de la ML ? Qui tu garantie que l'attaque n'a pas lieu dès le début ?

                  La garantie est insuffisante et lier des messages les uns aux autres ne constitue pas un gage de constance de l'identité de la personne.
                  • [^] # Re: Rapidement

                    Posté par . Évalué à 2.

                    Dés le début ? Quel intérêt ?

                    Pourquoi des gens aurait a échanger des choses sensibles sur une ML (publique ?) qui serait pirate dés le début ?

                    Et il y a toujours le cas du mail envoyé directement qui signalerait le problème immédiatement.

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

  • # je sais pas... Pourquoi réinventer la roue

    Posté par . Évalué à 3.

    xchat me semble pas mal, un petit client irc,
    * capable de se connecter en chiffré (ssl),
    * en général les serveurs mettent en place un nickserv (demandant un /msg nickserv "monPassword"
    *certain chan n'autorisent que les personnes identifiées pour entrer.
    * Un lien http est clicable.
    * Ils peuvent être archivé.
    * Il existes quelques webclient

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: je sais pas... Pourquoi réinventer la roue

      Posté par . Évalué à 2.

      arf il manque la fin.
      La plupart des clients permettent l'installation de greffons; on peut très bien en prendre un qui chiffre et/ou signe chaque messages selon une clé (pas forcément visible en plus, (les options de mise en forme %C0) bien placés.

      Comme ça même en cas de compromission du serveur, tu peux t'assurer de l'identité des correspondant.
      Par contre comme dans toute authentification, tu ne de dispensera pas de la phase d'initialisation (donner la clé permettant de vérifier sa signature à un tiers)

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: je sais pas... Pourquoi réinventer la roue

      Posté par . Évalué à 2.

      Le truc avec xchat c'est que dans ce cas, un serveur centralisé détient toutes les conversations en clair ce me semble (c'est d'ailleurs auprès de lui qu'on s'identifie). Impossible alors d'avoir une conversation privée par exemple.
      • [^] # Re: je sais pas... Pourquoi réinventer la roue

        Posté par . Évalué à 2.

        alors la je regrette,
        DCC (Direct_Client-to-Client se passe du serveur. (dcc send ou dcc chat )
        Tu as même des versions chiffrés du dcc chat.

        Alors oui les chan sont lisible du serveur, mais pas les sessions DCC.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: je sais pas... Pourquoi réinventer la roue

          Posté par . Évalué à 2.

          La version chiffrée n'est pas n'importe quoi mais du SSL, il suffit que chacun des interlocuteurs utilise un certificat et un trousseau de clés pour avoir une conversation réellement privée. KVIrc le fait très bien (et mIRC je crois), mais malheureusement pour ce logiciel il ne propose pas la génération de certificat (contrairement à Mumble) et donc SSL est souvent utilisé sans certificat (et du coup l'intérêt est réduit). Voici comment faire pour générer un certificat:

          > openssl genrsa -out paire.key 4096
          > openssl req -new -x509 -days 365 -key paire.key -out public.pem

          La première commande crée le fichier "paire.key", il faut s'en servir en tant que clé privé dans KVIrc. La seconde ligne crée le fichier public.pem qui correspond au certificat.

          Le fait que le certificat soit auto-signé n'est pas un problème, pour les plus paranoïaques on peut s'échanger l'empreinte de la clé par un autre moyen, ou sinon dans le cadre d'une conversation personnelle avec une personne que l'on connait déjà, on peut classer le certificat dans les éléments de confiance à la fin de la conversation.

          La seule contrainte du DCC est que l'un des ordinateurs joue le rôle de serveur. Seulement un seul car il existe le Reverse DCC, celui qui initialise la session DCC n'est plus obligé d'être le serveur. Mais généralement ce n'est pas un problème car beaucoup sont habitués à rediriger des ports de leur box grâce au phénomène du peer to peer.
  • # à la masse

    Posté par . Évalué à 2.

    Il pourrait également y avoir une possibilité de sécurité par le nombre. Chiffrer un flux ne vaut en général que pour les vilains pirates, mais pas pour des sociétés ou des Etats. A moins d'utiliser un chiffrement fort.

    Il peut, pourrait, être intéressant d'y ajouter un flux non seulement en clair mais en plus totalement public. Distribution p2p. Affichage chez tout le monde de tout les messages du canal.

    ??

    -> à la charge des personnes de choisir un mode d'échange de reconnaissance, détaché de l'utilisation du canal (sms, mail ...)
    -> à la charge des personnes de vérifier l'identité par recoupement régulier.
    -> l'aspect totalement public et en clair sur un seul canal noie par design les informations.
    -> à la charge du client de filtrer l'affichage (et non la réception)
    • [^] # Re: à la masse

      Posté par . Évalué à 2.

      Je crois que tu viens en partie de réinventer OTR (authentification et déniabilité)
      • [^] # Re: à la masse

        Posté par . Évalué à 2.

        Je ne connaissais pas OTR, à la lecture il me semble comprendre pourquoi tu fais le rapprochement. Mais OTR est bien plus complexe ! :-)

        C'est l'idée d'association systématique entre chiffrement et sécurité que je refute un peu, pour certains usages uniquement bien sûr. Bref pour de la "haute sécurité" il me semble (humblement) qu'il est toujours mieux de dissocier les éléments. Dissocier l'identification du transport.

        Merci :)
  • # Jabber + GPG

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

    Je n'ai pas bien compris tes besoins, vu que ça parle de trucs bizarres comme le web et Flash, qui n'ont pas grand chose à voir avec la MI, et sont plutôt inadaptés.

    Mais sache que Jabber permet déjà de faire du chiffrement et de la signature avec PGP.
    • [^] # Re: Jabber + GPG

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

      Suffit de tester la communication entre 2 Gajim par exemple. A-t-on une liste plus précise des clients jabber qui supportent ça ? Quelle compatibilité inter-clients ? Quelle XEP utilisée ?
      Bon après, je suis pas sûr que ça permette de faire tout ce dont l'auteur parle mais bon...
    • [^] # Re: Jabber + GPG

      Posté par . Évalué à 4.

      J'allais faire la même remarque.

      "Salut, je veux faire la même chose que XMPP, mais en HTTP".

      On dirait un défi absurde..

      "Salut, je veux faire la même chose que SMB, mais en POP".

      Heu.. ouais, pourquoi pas?

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # clefs et stockage

    Posté par . Évalué à 3.

    Tout ça c'est génial, mais il me semble qu'il y a un point essentiel oublié :
    Le stockage des clefs.

    Parceque perso je n'ai qu'une confiance très limitée dans le ~

    Probable qu'un atout de plus à placer du côté d'une telle solution serait d'obliger l'utilisateur à avoir une carte sd ou une clef usb qui ne soit utilisée qu'à la demande. On pourrait aussi voir cela par "contraindre l'utilisateur à avoir de bonnes pratiques en lui proposant un système simple"

    ??
  • # Deux petites remarques...

    Posté par . Évalué à 2.

    (1) signature GPG, signature SHA-1 ? (pas MD5, on sait qu'il peut y avoir collision de signature).
    Attention, une signature n'est pas un haché. La signature authentifie le message avec une clef, un hachage SHA1 (à remplacer d'ailleurs, il faut utiliser au minimum SHA256) n'authentifie rien du tout s'il n'est pas associé à une clef.

    Pour donner un exemple, la signature GPG c'est un peu comme signer sur la fermeture de l'enveloppe, quand le hachage n'est que fermer l'enveloppe. On peut s'assurer que l'enveloppe n'a pas été ouverte, mais sans signature on ne sait pas qui l'a envoyée.


    Notons à ce stade, un facteur de risque : si le PC d'un des participants est correctement piraté (un cheval de Troie ayant ouvert une porte dérobée par exemple), tout ce que cet utilisateur émet est modifiable par le pirtate.
    Si c'est avec ce PC que l'utilisateur envoie ses messages, toute prise de contrôle à distance sera fatale.
  • # SILC + Tor

    Posté par . Évalué à 1.

    Regarde du côté de SILC pour l'identification/authentification/chiffrement :

    http://en.wikipedia.org/wiki/SILC_(protocol)

    Et utilises tor pour passer ça anonymement sur le réseau

Suivre le flux des commentaires

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