LibrePGP, un fork mis à jour d'OpenPGP

Le principal développeur et mainteneur de l'outil de chiffrement et de signature. Le principal développeur et mainteneur de Werner Koch. dévoilé il y a quelques jours la nouvelle deCréation du projet LibrePGP, c'est laquelle une fourchette concentré sur le développement d’une spécification alternative mise à jour au standard OpenPGP.

Il est mentionné que dans les raisons de la création de cette fourchette C'est apparemment en réponse à un différend au sein de l'Internet Engineering Task Force (IETF) sur le développement futur du standard OpenPGP, car Koch percevait la prochaine mise à jour de la spécification OpenPGP comme discutable du point de vue de la compatibilité et de la sécurité.

Selon Koch :

Le point de départ de la séparation des travaux au sein de l'IETF et du lancement de LibrePGP est que les mises à jour prévues du standard OpenPGP (RFC 4880) sont "préjudiciables à l'utilisation actuelle du logiciel OpenPGP", a-t-il déclaré. Dans la publicité, il écrit. Sans entrer dans des détails techniques précis, le différend renvoie à la question de savoir comment adapter le standard OpenPGP actuel pour le futur.

Et le jeETF, au lieu de mettre à jour progressivement la spécification, a tenté de réinventer la norme et y apporter des modifications importantes qui violaient l'interopérabilité, en plus d'imposer le support du mode de cryptage symétrique GCM, difficile à mettre en œuvre correctement, ignorant l'OCB (Offset codebook mode), dont les brevets ont expiré depuis plusieurs années.

Les développeurs des projets GnuPG, RNP (implémentation Thunderbird OpenPGP) et Gpg4win qui supportaient le fork craignent que les changements prévus soient préjudiciables aux implémentations existantes d'applications basées sur OpenPGP, dont les utilisateurs s'attendent à ce que la spécification soit stable à long terme. pas prêt à prendre en charge les modifications qui rompent la compatibilité.

En plus de cela, le Les créateurs de LibrePGP s'interrogent sur l'ajout de packages facultatifs avec un remplissage aléatoire pour se protéger contre l’analyse du trafic. Selon eux, ces paquets au remplissage aléatoire initial invérifiable menacent d'être utilisés pour créer des canaux de transmission de données cachés et contourner les systèmes de prévention des fuites de données. Auparavant, l'idée d'inclure le remplissage était rejetée comme un problème au niveau de l'application plutôt qu'un problème au niveau du cryptage.

En outre, Ils remettent également en question l'utilisation d'un système de cryptage ECDH modifié., au lieu d'utiliser l'option déjà décrite dans la RFC-6637 et implémentée dans PGP et GnuPG, ainsi que la suppression de certaines fonctionnalités pratiques, comme la méthode classique de révocation de clé, l'indicateur "m" pour marquer les données MIME et le "t " pour séparer le texte des données binaires (l'indicateur "t" a été remplacé par l'indicateur "u" pour le texte codé en UTF-8).

Compte tenu de ce problème et d'autres, les raisons pour lesquelles création de LibrePGP, qui est mentionné comme intégrant des améliorations utiles qui ont été développées ces dernières années pour une future version de la spécification OpenPGP, mais évite les changements qui affecteraient négativement la compatibilité. Par exemple, par rapport à la norme RFC-4880 actuelle, LibrePGP a adopté les fonctionnalités suivantes :

• Prise en charge de l'algorithme de chiffrement Camellia (RFC-5581),
• Extensions ECC (cryptographie à courbe elliptique) pour OpenPGP (RFC-6637).
• Prise en charge obligatoire des hachages SHA2-256 (SHA-1 et MD5 sont classés comme non recommandés, et la possibilité de déchiffrer des données sans vérification d'intégrité est classée comme complètement obsolète).
• Augmentation de la taille de l'empreinte digitale à 256 bits.
• Prend en charge le schéma de signature numérique EdDSA et les schémas de signature à courbe elliptique BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 et X448.
• Prise en charge de l'algorithme CRYSTALS-Kyber, qui résiste à la sélection dans les ordinateurs quantiques.
• Prise en charge des modes de cryptage authentifiés OCB (Offset Codebook Mode).
• Implémentation de la cinquième version du format de signature numérique avec protection des métadonnées.
• Prise en charge des sous-packages étendus avec signatures numériques.

Enfin, il convient de mentionner que les partisans d'OpenPGP Ils ont déjà publié critiques sur critiques. En conséquence, si un compromis ne peut être trouvé, la scission peut conduire à des incompatibilités croissantes dans les implémentations OpenPGP/LibrePGP. Pour résoudre partiellement ce problème, les développeurs d'OpenPGP ont corrigé la cinquième version du format de signature comme étant compatible avec LibrePGP et ont ensuite travaillé sur la sixième version.

Si vous intéressé à en savoir plus, vous pouvez vérifier les détails dans le lien suivant.