{"id":112077,"date":"2023-12-08T15:10:14","date_gmt":"2023-12-08T13:10:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp"},"modified":"2023-12-08T15:10:14","modified_gmt":"2023-12-08T13:10:14","slug":"avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","title":{"rendered":"L'auteur de GnuPG a fond\u00e9 LibrePGP, fork de la norme OpenPGP","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Werner Koch, le d\u00e9veloppeur principal et cr\u00e9ateur du projet GnuPG (GNU Privacy Guard), a fond\u00e9 le projet LibrePGP, ax\u00e9 sur le d\u00e9veloppement d'une sp\u00e9cification mise \u00e0 jour, alternative \u00e0 la norme OpenPGP. Le fork a \u00e9t\u00e9 cr\u00e9\u00e9 en r\u00e9ponse aux changements pr\u00e9vus par le groupe de travail IETF pour la prochaine mise \u00e0 jour de la sp\u00e9cification OpenPGP (RFC-4880) et que Koch consid\u00e8re comme douteux en ce qui concerne la compatibilit\u00e9 et la s\u00e9curit\u00e9. Les d\u00e9veloppeurs soutenant le fork provenant des projets GnuPG, RNP (la mise en \u0153uvre OpenPGP de Thunderbird) et Gpg4win craignent que les changements propos\u00e9s nuisent aux mises en \u0153uvre existantes des applications bas\u00e9es sur OpenPGP, dont les utilisateurs comptent sur la stabilit\u00e9 de la sp\u00e9cification \u00e0 long terme et ne sont pas pr\u00eats \u00e0 accepter des modifications compromettant la compatibilit\u00e9. <\/p>\n
LibrePGP comprend des am\u00e9liorations utiles, d\u00e9velopp\u00e9es ces derni\u00e8res ann\u00e9es pour une future version de la sp\u00e9cification OpenPGP, tout en excluant les modifications ayant un impact n\u00e9gatif sur la compatibilit\u00e9. Par exemple, par rapport \u00e0 la norme actuelle RFC-4880, LibrePGP a adopt\u00e9 les fonctionnalit\u00e9s suivantes : <\/p>\n
\n
Prise en charge de l'algorithme de chiffrement Camellia (RFC-5581),\n
Extensions ECC (Elliptic Curve Cryptography) pour OpenPGP (RFC-6637).\n
Prise en charge obligatoire des hachages SHA2-256 (SHA-1 et MD5 sont consid\u00e9r\u00e9s comme non recommand\u00e9s, et la possibilit\u00e9 de d\u00e9chiffrer des donn\u00e9es sans v\u00e9rification d'int\u00e9grit\u00e9 est consid\u00e9r\u00e9e comme totalement obsol\u00e8te).\n
Augmentation \u00e0 256 bits de la taille du fingerprint.\n
Prise en charge du sch\u00e9ma de signatures num\u00e9riques EdDSA et des courbes elliptiques BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 et X448.\n
Prise en charge de l'algorithme CRYSTALS-Kyber, r\u00e9sistant aux attaques par ordinateurs quantiques.\n
Prise en charge des modes de chiffrement authentifi\u00e9 OCB (Offset codebook mode).\n
Impl\u00e9mentation de la cinqui\u00e8me version du format de signatures num\u00e9riques avec protection des m\u00e9tadonn\u00e9es.\n
Prise en charge des sous-paquets \u00e9tendus avec des signatures num\u00e9riques. <\/ul>\n
\u00c9l\u00e9ments principaux de la critique de la nouvelle sp\u00e9cification OpenPGP : <\/p>\n
\n
Le groupe de travail IETF, au lieu de proc\u00e9der \u00e0 une mise \u00e0 jour incr\u00e9mentale progressive de la sp\u00e9cification, a tent\u00e9 de r\u00e9inventer compl\u00e8tement la norme et d'y apporter des changements significatifs qui compromettent la compatibilit\u00e9.\n
Imposition de la prise en charge du mode de chiffrement sym\u00e9trique GCM (Galois\/Counter Mode), qui est difficile \u00e0 mettre en \u0153uvre correctement, en ignorant le mode OCB (Offset Codebook Mode), dont les brevets ont expir\u00e9 depuis plusieurs ann\u00e9es.\n
Ajout de paquets optionnels avec un remplissage al\u00e9atoire suppl\u00e9mentaire pour \u00e9viter l'analyse du trafic. Selon les cr\u00e9ateurs de LibrePGP, de tels paquets avec un remplissage al\u00e9atoire initial non v\u00e9rifiable posent une menace d'utilisation pour cr\u00e9er des canaux de transmission de donn\u00e9es cach\u00e9s et contourner les syst\u00e8mes de pr\u00e9vention des fuites de donn\u00e9es. Auparavant, l'id\u00e9e d'inclure un remplissage suppl\u00e9mentaire \u00e9tait rejet\u00e9e, consid\u00e9r\u00e9e comme un enjeu non pas au niveau du chiffrement, mais au niveau de l'application.\n
Utilisation d'un sch\u00e9ma de chiffrement ECDH modifi\u00e9 (changement de format OID), au lieu d'utiliser l'option d\u00e9j\u00e0 d\u00e9crite dans la RFC-6637 et mise en \u0153uvre dans PGP et GnuPG.\n
Suppression de certaines fonctionnalit\u00e9s pratiques, telles que la m\u00e9thode classique de r\u00e9vocation des cl\u00e9s, le drapeau «m» pour marquer les donn\u00e9es MIME et le drapeau «t» pour s\u00e9parer les donn\u00e9es textuelles des donn\u00e9es binaires (le drapeau «t» a \u00e9t\u00e9 remplac\u00e9 par le drapeau «u» pour le texte en codage UTF-8).\n
Refus d'inclure dans le nouveau format de signature la protection des m\u00e9tadonn\u00e9es du fichier sign\u00e9 (par exemple, il est possible de changer le nom du fichier sans violer la signature).\n
Possibilit\u00e9 douteuse d'ajouter du «sel» aux signatures (Salted signature) pour renforcer la protection contre les attaques par collision avec un pr\u00e9fixe donn\u00e9. La valeur avec sel peut \u00eatre utilis\u00e9e comme un canal cach\u00e9 non d\u00e9sactivable pour transmettre 32 octets de donn\u00e9es dans la signature.\n
D\u00e9placement de la norme vers une utilisation principale pour la communication en ligne, ignorant les besoins de conservation \u00e0 long terme des donn\u00e9es. <\/ul>\n
Les partisans d'OpenPGP ont d\u00e9j\u00e0 publi\u00e9 des critiques \u00e0 l'encontre de cette critique. En cons\u00e9quence, si aucun compromis n'est trouv\u00e9, la scission pourrait entra\u00eener une augmentation des incompatibilit\u00e9s dans les mises en \u0153uvre d'OpenPGP\/LibrePGP. En partie pour r\u00e9soudre ce probl\u00e8me, les d\u00e9veloppeurs d'OpenPGP ont fix\u00e9 la cinqui\u00e8me version du format de signature de mani\u00e8re compatible avec LibrePGP et ont commenc\u00e9 \u00e0 travailler sur la sixi\u00e8me version. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"