Journal Quelques brèves sur OpenPGP

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
43
4
juin
2015
Ce journal a été promu en dépêche : Quelques brèves sur OpenPGP.

Sommaire

Un petit journal bookmark pour annoncer quelques nouvelles intéressantes dans le monde OpenPGP.

La reformation du groupe de travail OpenPGP

Le groupe de travail OpenPGP à l’IETF s’était dissous en 2008 peu après la publication du RFC 4880, la version actuelle du standard OpenPGP. Depuis, il n’y avait pas eu grand’chose de nouveau dans OpenPGP, le plus gros changement étant l’introduction des algorithmes Camellia (RFC 5581) et ECDSA/ECDH (RFC 6637).

Maintenant, suite à un regain d’activité ces derniers mois sur sa liste de discussion, le groupe de travail est en train de se reformer. Les participants se sont accordés pour dire que le standard avait besoin d’être un peu rafraîchi.

Pêle-mêle, les points qui devraient/pourraient être abordés par ce « nouveau » groupe de travail incluent, entre autres :

  • La mise-à-jour des différents algorithmes qui DOIVENT être implémentés. Aujourd’hui, il s’agit de DSA et ElGamal pour les algorithmes asymétriques, 3DES pour le chiffrement symétrique, et SHA-1 pour la condensation. Il serait question d’ajouter ECDSA et ECDH en complément de DSA et ElGamal, de passer de 3DES à AES (qui aujourd’hui DEVRAIT être implémenté mais n’est pas obligatoire), et de passer de SHA-1 à SHA-2 voire à SHA-3).
  • Le remplacement de SHA-1 utilisé pour calculer les empreintes de clefs. Même si la probable vulnérabilité de SHA-1 aux attaques par collision ne remet pas en cause cette utilisation particulière — ce dont on a besoin ici est la résistance aux attaques sur la seconde préimage, et SHA-1 ne montre pas de signes de faiblesse de ce côté —, les participants estiment globalement qu’il serait plus simple de se débarasser purement et simplement de SHA-1 plutôt que de faire le tri des usages pour lesquels cet algorithme est encore sûr. Ne serait-ce que parce que ça éviterait aux développeurs d’avoir à expliquer à longueur de journée la différence entre collision et préimage, et partant d’avoir à justifier pourquoi ils utilisent encore SHA-1 alors que le monde autour d’eux répète à l’envie que SHA-1 est « complètement cassé ».
  • Le remplacement du mode d’opération pour le chiffrement symétrique. OpenPGP utilise, historiquement, sa propre variante du mode « Cipher Feedback ». Aujourd’hui, plusieurs développeurs préféreraient utiliser tel quel un mode bien défini et bien étudié par ailleurs plutôt qu’un mode créé sur mesure pour OpenPGP et utilisé seulement par lui (et qui vient avec ses propres attaques). Par ailleurs, dans la version actuelle la vérification de l’intégrité des données se fait en mode « MAC-then-encrypt » (un MAC est calculé sur le texte clair, puis chiffré avec le reste des données — le receveur est obligé de déchiffrer avant de pouvoir vérifier l’intégrité des données), ce qui n’est généralement plus recommandé aujourd’hui. Pour corriger d’un coup les deux problèmes (l’utilisation d’un mode spécifique à OpenPGP et la question de la vérification d’intégrité), les regards se tournent vers les nouveaux modes d’opération permettant le « chiffrement authentifié » (AEAD).
  • La mise à jour des algorithmes permettant de dériver une clef symétrique à partir d’une phrase de passe (String-to-Key specifiers ou S2K, selon le terme du RFC 4880). C’est un peu le même problème que le point précédent : les concepteurs de PGP et par suite d’OpenPGP avaient élaboré leur propre mécanisme de dérivation de clefs, et il serait question aujourd’hui de le remplacer par un mécanisme plus standard — les regards se tournent principalement soit vers PBKDF2 (RFC 2898), soit vers le (futur) vainqueur de la compétition PHC qui se tient actuellement sur le modèle des compétitions qui ont choisi AES et SHA-3.

L’objectif annoncé du groupe de travail est de publier d’ici fin 2016 un nouveau RFC qui remplacera le RFC 4880 actuel.

Une nouvelle version de la carte OpenPGP

La spécification de la carte OpenPGP, une application pour carte à puce, vient d’être mise à jour en version 3.0.

Au menu principalement :

  • la possibilité de générer et stocker sur la carte des clefs ECDSA et ECDH, et non plus seulement des clefs RSA ;
  • la taille minimale prise en charge pour une clef RSA est désormais de 2048 bits au lieu de 1024 ;
  • passage de SHA-1 aux algorithmes de la famille SHA-2 pour les opérations de signature.

Côté implémentations, Kernel Concepts, distributeur de l’implémentation de référence, n’a pas encore annoncé de carte au standard 3.0. En revanche, Gnuk, l’implémentation pour processeur STM32F103, est a priori déjà à jour.

Facebook se met à OpenPGP

Depuis quelques jours, Facebook permet à ses utilisateurs d’ajouter leur clef publique à leur profil. Dès lors et si l’utilisateur le souhaite, Facebook chiffrera les e-mails de notification.

Quoique je puisse penser de Facebook, c’est à ma connaissance le premier « gros » site web (a fortiori dans la catégorie « grand public ») à proposer une telle fonctionnalité, et j’apprécie cela. J’apprécie encore plus quand cela s’accompagne d’un soutien financier pour le développeur principal de GnuPG.

  • # record battu !

    Posté par  . Évalué à 10. Dernière modification le 04 juin 2015 à 13:33.

    c'est le plus long journal bookmark à ce jour
    d'ailleurs il devrait devenir la première dépêche bookmark de linuxfr

  • # RSA

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

    Il y a quelques années, on générait couramment des doubles paires de clefs DSA de 1024 bits — pour la certification net la signature — et ElGamal de 2048 bits — pour le chiffrement — à cause me semble-t-il de problèmes de brevets sur RSA. Depuis, cette pratique a été largement découragée, et comme les brevets RSA ont expiré en 2000, on recommande généralement d'utiliser des clefs RSA de 2048 bits ou plus, si possible 4096 bits, avec sous-clefs séparées par rôles.

    Je suis donc surpris de lire que RSA ne fait pas partie des algorithmes obligatoires, et qu'il n'est pas envisagé de l'y ajouter.

    • [^] # Re: RSA

      Posté par  . Évalué à 4.

      Il y a quelques années, on générait couramment des doubles paires de clefs DSA de 1024 bits

      D’abord, il faut noter que DSA n’est plus limité à 1024 bits : on peut avoir des clefs DSA de 2048 ou 3072 bits — en revanche, on ne peut pas aller au-delà de 3072, simplement parce que la spécification de DSA ne le prévoit pas.

      on recommande généralement d'utiliser des clefs RSA de 2048 bits ou plus

      C’est ce que je recommande en effet (plus précisément, je recommande RSA-4096 pour la clef primaire et RSA-2048 pour les sous-clefs), mais je n’irai pas jusqu’à dire que ça fait consensus. DSA a toujours ses défenseurs.

      Je suis donc surpris de lire que RSA ne fait pas partie des algorithmes obligatoires, et qu'il n'est pas envisagé de l'y ajouter.

      RSA fait pour l’instant partie des algorithmes qui DEVRAIENT être implémentés, et personne ne semble vouloir discuter pour transformer ce SHOULD en MUST.

  • # Facebook se met à OpenPGP

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

    Depuis quelques jours, Facebook permet à ses utilisateurs d’ajouter leur clef publique à leur profil. Dès lors et si l’utilisateur le souhaite, Facebook chiffrera les e-mails de notification.

    Deux solutions: quelque chose m'échappe ou c'est complétement con (passez-moi l'expression).

    Si je comprends bien mon interlocuteur va envoyer un message en clair vers Facebook qui se chargera de le chiffrer avec ma clef publique. Le message sera donc parfaitement confidentiel…sauf pour moi et FaceBook \o/ Voilà un progrès en matière de vie privée.

    • [^] # Re: Facebook se met à OpenPGP

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

      Non, c'est pour quand Facebook t'écrit des trucs directement. Ce n'est pas pour utiliser Facebook comme intermédiaire de chiffrement.

      • [^] # Re: Facebook se met à OpenPGP

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

        Je pense que je comprends mieux: FB peut m'écrire des messages que moi seul je pourrais lire et qui ne seront connus que de FB et de moi, sauf si quelqu'un le demande à FB…

      • [^] # Re: Facebook se met à OpenPGP

        Posté par  . Évalué à 9.

        D'ailleurs, Facebook signera aussi les mails qu'il émet. C'est particulièrement intéressant pour les mails de changement de mot de passe (on est sûr qu'ils soient bien émit par Facebook, donc le lien de reset est correct, et on évite que les intermédiaires aient accès au lien). Même si on peut bien sûr être intéressé que ses notifications ne circulent pas en clair.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Facebook se met à OpenPGP

          Posté par  . Évalué à 7. Dernière modification le 04 juin 2015 à 17:06.

          Ça va peut-être ENFIN démocratisé la crypto auprès du commun des mortels. Ce serait une bonne nouvelle.

  • # Pendant ce temps là, à la tour Maubourg

    Posté par  . Évalué à 4.

  • # Clé publique sur facebook

    Posté par  . Évalué à 7.

    Ce qui est surtout bien avec la possibilité d'ajouter sa clé publique sur facebook, c'est qu'on peut mettre l'empreinte en visible pour ses amis ou même en public. Ça offre un moyen supplémentaire de vérifier l'authenticité d'une clé.

    • [^] # Re: Clé publique sur facebook

      Posté par  . Évalué à 1.

      Mouais : si tu communique ta clef et l'empreinte par le même canal, ça perd un peu de son utilité…

Suivre le flux des commentaires

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