La plus grande GPG key signing party approche

Posté par . Édité par ZeroHeure, Nÿco et palm123. Modéré par Nÿco. Licence CC by-sa
Tags :
15
10
jan.
2014
Internet

Le Fosdem 2014 a lieu a Bruxelles pendant le week-end du 1er et 2 février. Au Fosdem a lieu tous les ans la plus grande rencontre visant à faire de la signature de clef GnuPG.

Vu les affaires récentes (les écoutes de la NSA, la récente loi de programmation militaire en France), on redécouvre la nécessité de protéger ses échanges de données avec de la cryptographie. Mais la cryptographie ne repose pas que sur les maths et les nombres premiers. Pour l'utiliser, il faut avoir confiance dans l'identité de ses correspondants. Autrement dit, il faut des tiers de confiance. Feriez-vous confiance à un organisme ? Moi non plus ! C'est pourquoi il est très important de participer à une « key signing party » pour renforcer la toile de confiance communautaire.

Si vous prévoyez de vous rendre au Fosdem et si vous voulez participer à la signature de clés il faut s'inscrire avant le 27 Janvier 2014. Les instructions pour le faire se trouvent à https://fosdem.org/2014/keysigning/.

  • # Limites de GPG

    Posté par (page perso) . Évalué à 2. Dernière modification le 10/01/14 à 10:01.

    Même si j'utilise moi-même GPG, je vous propose quelques liens en expliquant les limites :
    Off-the-Record Communication | Why Not To Use PGP (pdf)
    Why the Web of Trust Sucks
    15 reasons not to start using PGP

    Si vous ne voulez pas tout lire, je vous conseille le début du pdf (le premier lien, sections 2 et 3).

    blog.rom1v.com

    • [^] # Re: Limites de GPG

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

      Why the Web of Trust Sucks

      Pas de chance, l'unique argument présenté dans ce message est faux. Il suppose que GnuPG accorde automatiquement une confiance entière à toutes les clefs identifiées comme valides, ou à la rigueur à toutes les clefs signées avec une indication de signature complète, ce qui n'est pas le cas.

      Au contraire donc, GnuPG distingue bien ces deux notions :

      • la validité d'une clef, c'est à dire le fait qu'elle appartienne bien à la personne indiquée ;
      • le niveau de confiance que l'utilisateur accorde à cette personne, c'est à dire le fait qu'elle vérifie correctement les identités des gens avant de signer leurs clefs, et donc la valeur à accorder aux certifications qu'elle émet.

      Le fonctionnement de GnuPG est donc une itération de deux étapes :

      1. à partir des clefs valide auxquelles l'utilisateur accorde une confiance ultime, entière ou marginale, déterminer les nouvelles clefs valides, c'est à dire signées par au moins une clef à confiance ultime ou entière, ou trois clefs à confiance marginale ;
      2. pour les nouvelles clefs valides, demander à l'utilisateur quelle confiance il accorde à leurs propriétaires : s'il s'agit d'un inconnu, l'utilisateur peut, et doit répondre « je ne sais pas », ce qui revient à lui accorder une confiance nulle.

      Lorsqu'on certifie une clef, il est possible d'indiquer dans cette signature le niveau de confiance qu'on accorde à son propriétaire, mais, en tout cas pour GnuPG, il ne s'agit là que d'une information indicative, qu'il ne répercute pas automatiquement dans la base de confiance des utilisateurs. Ou plutôt, pour être plus précis :

      1. si vous certifiez une clef en indiquant dans cette signature une confiance, disons entière, GnuPG ne vous proposera ensuite, comme niveau de confiance accordé à cette clef dans votre propre trousseau, que « entière » et « je ne sais pas » : ça, c'est plutôt cohérent, vous n'êtes pas censés mentir en émettant publiquement des signatures de confiance tout en appliquant quelque chose de différent à votre propre trousseau ;
      2. si vous récupérez une clef signée par quelqu'un à qui vous accordez une confiance entière, et que cette signature précise une confiance, disons entière, GnuPG vous l'affichera si vous demandez la liste des signatures de cette nouvelle clef, mais n'appliquera pas ce niveau de confiance à cette nouvelle clef : comme pour toute nouvelle clef identifiée comme valide, vous devrez préciser librement le niveau de confiance à lui accorder.
      • [^] # Re: Limites de GPG

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

        Je sais pas si on a lu le même article.

        l'unique argument présenté dans ce message est faux.

        Les message est composé de trois points numérotés présentant trois arguments complétement différents. Il me semble que tu ne réponds que au point numéro 2.

        Il suppose que GnuPG accorde automatiquement une confiance entière à toutes les clefs identifiées comme valides, ou à la rigueur à toutes les clefs signées avec une indication de signature complète

        Non, je ne crois pas qu'il suppose ça.
        D'ailleurs tu peux très bien avoir une confiance absolue en Roger. Si le sysadmin parviens à infecter le portable de Roger avec un troyen pour s'emparer de ses clés, t'es foutu.
        Et si tu as confiance en 10 personnes, ça fait 10 point d'attaques.

        • [^] # Re: Limites de GPG

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

          Les message est composé de trois points numérotés présentant trois arguments complétement différents. Il me semble que tu ne réponds que au point numéro 2.

          Oui, en effet.

          Il suppose que GnuPG accorde automatiquement une confiance entière à toutes les clefs identifiées comme valides, ou à la rigueur à toutes les clefs signées avec une indication de signature complète

          Non, je ne crois pas qu'il suppose ça.

          Si :

          Edward's GPG client has trust in a couple keys. It turns out that one of
          his trusted keys, Bruce, has full trust in Roger's key (the compromised
          key).

          Edward's GPG client then computes a fully trusted path from Bruce to
          Roger to the fake Glenn, and Edward then sends an encrypted email to
          fake Glenn that is then subsequently read by the network systems
          administrator.

          La proposition que j'ai soulignée laisse supposer que GnuPG va automatiquement accorder à la clef de Roger une confiance entière, alors qu'il n'en est rien.

          D'ailleurs tu peux très bien avoir une confiance absolue en Roger. Si le sysadmin parviens à infecter le portable de Roger avec un troyen pour s'emparer de ses clés, t'es foutu.

          Exact. Mais je ne crois pas qu'il puisse exister la moindre parade contre cela, parce que tant qu'à faire, il peu aussi infecter le tien, de portable, c'est plus direct. Si Roger s'en rend compte, son devoir est de révoquer sa clef, et si un signataire de la clef de Roger s'en rend compte, il doit révoquer sa signature sur la clef de Roger.

          Et si tu as confiance en 10 personnes, ça fait 10 point d'attaques.

          Onze, en te comptant toi, et douze en comptant le destinataire des messages que tu veux envoyer. C'est vrai, ça c'est un défaut, et pas que de la toile de confiance à vrai dire : je n'imagine aucun système qui pourrait éviter cela.

          • [^] # Re: Limites de GPG

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

            Il semble qu'il y ait eux cas différents traités ici, celui ou qulqu'un crée une 'fausse' clef et la certifie avec une clef compromise, et celui ou le destinataire s'est fait voler sa clef. Dans le deuxième cas, c'est clair que c'est ballot. Mais dans le premier cas, s'il y a plus de points d'attaque potentiels, en même temps il y a plus de possibilités d'avoir de chaines de confiance vers certaines clef, donc le nombre de points d'attaque plus grand est bénéfique, non?

            • [^] # Re: Limites de GPG

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

              En effet, mais c'est là une critique qui s'applique de façon identique à tous les modèles de certification. La confiance par rencontre directe uniquement, c'est ce qui fait de plus sûr mais c'est impratique au possible. Tous les autres modèles améliorent la mise en pratique en diminuant de façon raisonnable la sécurité.

          • [^] # Re: Limites de GPG

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

            Edward's GPG client has trust in a couple keys. It turns out that one of
            his trusted keys, Bruce, has full trust in Roger's key (the compromised
            key).

            Edward's GPG client then computes a fully trusted path from Bruce to
            Roger to the fake Glenn, and Edward then sends an encrypted email to
            fake Glenn that is then subsequently read by the network systems
            administrator.

            La proposition que j'ai soulignée laisse supposer que GnuPG va automatiquement accorder à la clef de Roger une confiance entière, alors qu'il n'en est rien.

            Il y a bien une forme de transivité dans les clés, non ? Si je fais confiance à Bruce qui fait confiance à Roger, je ne fais pas du tout confiance à Roger ?

            • [^] # Re: Limites de GPG

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

              Il y a bien une forme de transivité dans les clés, non ?

              Pour la validité des clés, oui. Pour la confiance accordée au propriétaire de la clef, non.

              Si je fais confiance à Bruce qui fait confiance à Roger, je ne fais pas du tout confiance à Roger ?

              Non. Si tu fais pleinement confiance à Bruce et que Bruce dit que la clé de Roger est valide, alors la clé de Roger est automatiquement considérée valide.¹ Cela n’implique pas du tout que tu fasses automatiquement confiance à Roger, et ce quelle que soit la confiance éventuelle que Bruce accorde à Roger.

              Une fois qu’une clé a été validée (que ce soit par toi-même ou par quelqu’un de ton réseau en qui tu as confiance), c’est à toi et à toi seul de décider de la confiance que tu accordes à son propriétaire.


              ¹ Dans la configuration par défaut de GnuPG, mais c’est modifiable.

            • [^] # Re: Limites de GPG

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

              Il est possible, lorsqu'on signe une clef, d'indiquer avec sa signature le niveau de confiance qu'on accorde à son propriétaire, mais pour GnuPG, cest informations sont uniquement indicatives.

              • [^] # Re: Limites de GPG

                Posté par . Évalué à 1.

                En fait, si mon inteprétation de la section 5.2.3.13 de la RFC4880 est bonne, c'est la confiance en la validité de la clef et non la confiance en la manière de valider du propriétaire de la clef qu'on indique ici.

    • [^] # Re: Limites de GPG

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

      15 reasons not to start using PGP

      Je n'ai pas lu l'article, mais même si GPG/PGP c'était de la grosse merde, je ne vois pas en quoi ça serait mieux de ne pas l'utiliser.

      • [^] # Re: Limites de GPG

        Posté par . Évalué à 2.

        J'aurais tendance à dire : parce qu'il vaut mieux parfois savoir que l'on n'a pas confiance en quelquechose, qu'avoir l'illusion que l'on peut avoir totalement confiance en cette chose.
        En l'occurence, il faut avoir en tête que l'on peut faire confiance en PGP, dans une certaine mesure (et comme l'article le dit, la limitation étant que si quelqu'un enregistre toutes les conversations chiffrées aujourd'hui, et dispose de votre clef demain, il pourra alors lire toutes vos communications passées et futures)

      • [^] # Re: Limites de GPG

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

        C'est marrant, c'est exactement ce que dit le paragraphe d'introduction de cette page :

        Pretty Good Privacy is better than no encryption at all, and being end-to-end it is also better than relying on SMTP over TLS (that is, point-to-point between the mail servers while the message is unencrypted in-between), but is it still a good choice for the future? Is it something we should recommend to people who are asking for better privacy today?

        • [^] # Re: Limites de GPG

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

          Oui bon, comme j'ai dit, je n'avais pas lu l'article. Avouez quand même que le titre laisse supposer que le contenu soit un tissu d'âneries.
          Mea Culpa.

          • [^] # Re: Limites de GPG

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

            Un tissu d'âneries, non. En revanche le titre est excessif, clairement : “why the web of trust is not perfect” serait plus pertinent. Voire même “why the web of trust is not perfect, even though we found nothing better”.

  • # arithmétique

    Posté par . Évalué à 3.

    Très bien, mais il n'est pas forcement possible de se déplacer à Bruxelles à une date déterminée.

    Du coup, je me pose une question. Question entièrement ouverte, puisqu'il (me) manque des données pour y répondre.

    L'intérêt de GPG repose sur le maillage du réseau de confiance. Pour établir ce réseau on organise des "key signing party" regroupant n participants. Cela peut donc donner lieu à n(n-1)/2 = (n²-n)/2 échanges de clés.

    L'intérêt des grandes rencontres (n grand) est apparemment évident, mieux vaut une rencontre à n participants que k rencontres à n/k participants : n(n-1)/2 > k(n/k(n/k-1))/2

    Mais en organisant beaucoup de réunions plus petites :
    - il est plus facile de s'y rendre
    - on peut participer à plus de réunions

    peut-on envisager q réunions à k/n personnes telles que q(n/k(n/k-1))/2 > n(n-1)/2

    D'un autre côté, dans plusieurs réunions plus petites, on risque d'y re-croiser des gens déjà connus : le "rendement" baisse.

    Quel est votre avis sur cette question àlak' ?

    • [^] # Re: arithmétique

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

      Oui mais désires-tu n grand avis d'experts ou k petits avis de noobs?

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: arithmétique

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

      peut-on envisager q réunions à k/n personnes telles que q(n/k(n/k-1))/2 > n(n-1)/2

      Il faudrait estimer, via une loi de probabilité, le taux de convergence des signatures entre les k/n personnes quand le nombres de réunions tend vers k, interpolées à la primitive issues de la théorie des graphes restreints de q.

      P.-S.: les questions ça finit par des points d'interrogation. :p

      Écrit en Bépo selon l’orthographe de 1990

Suivre le flux des commentaires

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