{"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\/es\/blog\/news\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","title":{"rendered":"El autor de GnuPG fund\u00f3 LibrePGP, un fork del est\u00e1ndar OpenPGP.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Werner Koch, el desarrollador principal y creador del proyecto GnuPG (GNU Privacy Guard), fund\u00f3 el proyecto LibrePGP, centrado en el desarrollo de una especificaci\u00f3n actualizada, alternativa al est\u00e1ndar OpenPGP. El fork se cre\u00f3 en respuesta a los cambios propuestos por el grupo de trabajo de IETF para la pr\u00f3xima actualizaci\u00f3n de la especificaci\u00f3n OpenPGP (RFC-4880), percibidos por Koch como cuestionables en t\u00e9rminos de mantener la compatibilidad y garantizar la seguridad. Los desarrolladores que apoyaron el fork, de los proyectos GnuPG, RNP (implementaci\u00f3n de OpenPGP por Thunderbird) y Gpg4win, temen que los cambios propuestos resulten perjudiciales para las implementaciones actuales de aplicaciones basadas en OpenPGP, cuyos usuarios dependen de la estabilidad de la especificaci\u00f3n a largo plazo y no est\u00e1n dispuestos a aceptar cambios que rompan la compatibilidad. <\/p>\n
LibrePGP incluye mejoras \u00fatiles desarrolladas en los \u00faltimos a\u00f1os para una futura versi\u00f3n de la especificaci\u00f3n OpenPGP, pero excluye los cambios que afectan negativamente a la compatibilidad. Por ejemplo, en comparaci\u00f3n con el est\u00e1ndar actual RFC-4880, LibrePGP ha adoptado las siguientes capacidades: <\/p>\n
\n
Soporte para el algoritmo de cifrado Camellia (RFC-5581),\n
Extensiones ECC (Criptograf\u00eda de Curva El\u00edptica) para OpenPGP (RFC-6637).\n
Soporte obligatorio para hashes SHA2-256 (SHA-1 y MD5 se consideran obsoletos, y la posibilidad de descifrar datos sin verificar la integridad se considera completamente desactualizada).\n
Aumento del tama\u00f1o del fingerprint a 256 bits.\n
Soporte para el esquema de firmas digitales EdDSA y curvas el\u00edpticas BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 y X448.\n
Soporte para el algoritmo CRYSTALS-Kyber, resistente a ataques con computadoras cu\u00e1nticas.\n
Soporte para modos de cifrado autenticado OCB (Modo de libro de c\u00f3digos desplazado).\n
Implementaci\u00f3n de la quinta versi\u00f3n del formato de firmas digitales con protecci\u00f3n de metadatos.\n
Soporte para subpaquetes extendidos con firmas digitales. <\/ul>\n
Los principales elementos de cr\u00edtica a la nueva especificaci\u00f3n de OpenPGP: <\/p>\n
\n
El grupo de trabajo de IETF, en lugar de realizar una actualizaci\u00f3n incremental gradual de la especificaci\u00f3n, intent\u00f3 reinventar el est\u00e1ndar y realizar cambios significativos que rompen la compatibilidad.\n
Imposici\u00f3n de soporte para el modo de cifrado sim\u00e9trico GCM (Galois\/Counter Mode), que es dif\u00edcil de implementar correctamente, ignorando al mismo tiempo el modo OCB (Offset Codebook Mode), cuyo patente expir\u00f3 hace varios a\u00f1os.\n
Adici\u00f3n de paquetes opcionales con relleno aleatorio para proteger contra el an\u00e1lisis de tr\u00e1fico. Seg\u00fan los creadores de LibrePGP, tales paquetes con relleno aleatorio inicial no verificable representan una amenaza para la creaci\u00f3n de canales ocultos de transmisi\u00f3n de datos y para eludir sistemas de prevenci\u00f3n de filtraciones de datos. Anteriormente, la idea de incluir relleno adicional fue rechazada, consider\u00e1ndola un asunto de nivel de aplicaci\u00f3n y no de cifrado.\n
Implementaci\u00f3n de un esquema de cifrado ECDH modificado (cambio en el formato OID), en lugar de utilizar la variante ya descrita en la RFC-6637 y realizada en PGP y GnuPG.\n
Eliminaci\u00f3n de algunas funcionalidades utilizadas en la pr\u00e1ctica, como el m\u00e9todo cl\u00e1sico de revocaci\u00f3n de claves, el flag «m» para marcar datos MIME y el flag «t» para separar datos de texto de los binarios (el flag «t» fue reemplazado por el flag «u» para texto en codificaci\u00f3n UTF-8).\n
Decisi\u00f3n de no incluir en el nuevo formato de firmas la protecci\u00f3n de los datos del metadato del archivo firmado (por ejemplo, es posible cambiar el nombre del archivo sin romper la firma).\n
Funcionalidad dudosa de a\u00f1adir «salt» a las firmas (Salted signature) para aumentar la protecci\u00f3n contra ataques de colisi\u00f3n con un prefijo dado. El valor con salt puede ser utilizado como un canal oculto inhabilitable para la transmisi\u00f3n de 32 bytes de datos en la firma.\n
Desplazamiento del est\u00e1ndar hacia un uso principal para la comunicaci\u00f3n en l\u00ednea, ignorando las necesidades de almacenamiento a largo plazo. <\/ul>\n
Los partidarios de OpenPGP ya han publicado cr\u00edticas sobre la cr\u00edtica. En consecuencia, si no se encuentra un compromiso, la divisi\u00f3n puede llevar a un aumento de la incompatibilidad en las implementaciones de OpenPGP\/LibrePGP. Para abordar parcialmente este problema, los desarrolladores de OpenPGP han fijado la quinta versi\u00f3n del formato de firmas en un formato compatible con LibrePGP y han comenzado a trabajar en la sexta versi\u00f3n. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"