Quelques brèves sur OpenPGP

NdM : gouttegd livre régulièrement des journaux traitant d'OpenPGP. Il vient de réaliser une petit tour d'horizon de quelques brèves à ce propos.

Au sommaire :

• La reprise d'activité sur OpenPGP ;
• Une nouvelle version de la carte OpenPGP ;
• Facebook se met à OpenPGP.

Bonne lecture !

Sommaire

• La reformation du groupe de travail OpenPGP
• Une nouvelle version de la carte OpenPGP
• Facebook se met à OpenPGP

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ébarrasser 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’envi 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 avec sa clé afin que lui seul puisse les lire, tout en les signant pour assurer leur authenticité a l'utilisateur.

Quoique je puisse penser de Facebook, c’est à ma connaissance le premier « gros » site web (à 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.

Aller plus loin

• "Petit journal bookmark" à l'origine de la dépêche (279 clics)