Werner Koch, le développeur principal et créateur du projet GnuPG (GNU Privacy Guard), a fondé le projet LibrePGP, axé sur le développement d'une spécification mise à jour, alternative à la norme OpenPGP. Le fork a été créé en réponse aux changements prévus par le groupe de travail IETF pour la prochaine mise à jour de la spécification OpenPGP (RFC-4880) et que Koch considère comme douteux en ce qui concerne la compatibilité et la sécurité. Les développeurs soutenant le fork provenant des projets GnuPG, RNP (la mise en œuvre OpenPGP de Thunderbird) et Gpg4win craignent que les changements proposés nuisent aux mises en œuvre existantes des applications basées sur OpenPGP, dont les utilisateurs comptent sur la stabilité de la spécification à long terme et ne sont pas prêts à accepter des modifications compromettant la compatibilité.
LibrePGP comprend des améliorations utiles, développées ces dernières années pour une future version de la spécification OpenPGP, tout en excluant les modifications ayant un impact négatif sur la compatibilité. Par exemple, par rapport à la norme actuelle RFC-4880, LibrePGP a adopté les fonctionnalités suivantes :
- Prise en charge de l'algorithme de chiffrement Camellia (RFC-5581),
- Extensions ECC (Elliptic Curve Cryptography) pour OpenPGP (RFC-6637).
- Prise en charge obligatoire des hachages SHA2-256 (SHA-1 et MD5 sont considérés comme non recommandés, et la possibilité de déchiffrer des données sans vérification d'intégrité est considérée comme totalement obsolète).
- Augmentation à 256 bits de la taille du fingerprint.
- Prise en charge du schéma de signatures numériques EdDSA et des courbes elliptiques BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 et X448.
- Prise en charge de l'algorithme CRYSTALS-Kyber, résistant aux attaques par ordinateurs quantiques.
- Prise en charge des modes de chiffrement authentifié OCB (Offset codebook mode).
- Implémentation de la cinquième version du format de signatures numériques avec protection des métadonnées.
- Prise en charge des sous-paquets étendus avec des signatures numériques.
Éléments principaux de la critique de la nouvelle spécification OpenPGP :
- Le groupe de travail IETF, au lieu de procéder à une mise à jour incrémentale progressive de la spécification, a tenté de réinventer complètement la norme et d'y apporter des changements significatifs qui compromettent la compatibilité.
- Imposition de la prise en charge du mode de chiffrement symétrique GCM (Galois/Counter Mode), qui est difficile à mettre en œuvre correctement, en ignorant le mode OCB (Offset Codebook Mode), dont les brevets ont expiré depuis plusieurs années.
- Ajout de paquets optionnels avec un remplissage aléatoire supplémentaire pour éviter l'analyse du trafic. Selon les créateurs de LibrePGP, de tels paquets avec un remplissage aléatoire initial non vérifiable posent une menace d'utilisation 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 un remplissage supplémentaire était rejetée, considérée comme un enjeu non pas au niveau du chiffrement, mais au niveau de l'application.
- Utilisation d'un schéma de chiffrement ECDH modifié (changement de format OID), au lieu d'utiliser l'option déjà décrite dans la RFC-6637 et mise en œuvre dans PGP et GnuPG.
- Suppression de certaines fonctionnalités pratiquement utilisées, telles que la méthode classique de révocation des clés, le drapeau « m » pour marquer les données MIME et le drapeau « t » pour séparer les données textuelles des données binaires (le drapeau « u » pour le texte en UTF-8 a remplacé le drapeau « t »).
- Refus d'inclure dans le nouveau format de signature la protection des métadonnées du fichier signé (par exemple, il est possible de changer le nom du fichier sans violer la signature).
- Possibilité douteuse d'ajouter du « sel » aux signatures (Salted signature) pour renforcer la protection contre les attaques par collision avec un préfixe donné. La valeur avec le sel peut être utilisée comme un canal caché non désactivable pour transmettre 32 octets de données dans la signature.
- Déplacement de la norme vers une utilisation principale pour la communication en ligne, ignorant les besoins de conservation à long terme des données.
Les partisans d'OpenPGP ont déjà publié des critiques à l'encontre de cette critique. En conséquence, si aucun compromis n'est trouvé, la scission pourrait entraîner une augmentation des incompatibilités dans les mises en œuvre d'OpenPGP/LibrePGP. En partie pour résoudre ce problème, les développeurs d'OpenPGP ont fixé la cinquième version du format de signature de manière compatible avec LibrePGP et ont commencé à travailler sur la sixième version.
Source : opennet.ru
