Werner Koch, el desarrollador principal y creador del proyecto GnuPG (GNU Privacy Guard), fundó el proyecto LibrePGP, centrado en el desarrollo de una especificación actualizada, alternativa al estándar OpenPGP. El fork se creó en respuesta a los cambios propuestos por el grupo de trabajo de IETF para la próxima actualización de la especificación OpenPGP (RFC-4880), percibidos por Koch como cuestionables en términos de mantener la compatibilidad y garantizar la seguridad. Los desarrolladores que apoyaron el fork, de los proyectos GnuPG, RNP (implementación 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ón a largo plazo y no están dispuestos a aceptar cambios que rompan la compatibilidad.
LibrePGP incluye mejoras útiles desarrolladas en los últimos años para una futura versión de la especificación OpenPGP, pero excluye los cambios que afectan negativamente a la compatibilidad. Por ejemplo, en comparación con el estándar actual RFC-4880, LibrePGP ha adoptado las siguientes capacidades:
- Soporte para el algoritmo de cifrado Camellia (RFC-5581),
- Extensiones ECC (Criptografía de Curva Elíptica) para OpenPGP (RFC-6637).
- 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).
- Aumento del tamaño del fingerprint a 256 bits.
- Soporte para el esquema de firmas digitales EdDSA y curvas elípticas BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 y X448.
- Soporte para el algoritmo CRYSTALS-Kyber, resistente a ataques con computadoras cuánticas.
- Soporte para modos de cifrado autenticado OCB (Modo de libro de códigos desplazado).
- Implementación de la quinta versión del formato de firmas digitales con protección de metadatos.
- Soporte para subpaquetes extendidos con firmas digitales.
Los principales elementos de crítica a la nueva especificación de OpenPGP:
- El grupo de trabajo de IETF, en lugar de realizar una actualización incremental gradual de la especificación, intentó reinventar el estándar y realizar cambios significativos que rompen la compatibilidad.
- Imposición de soporte para el modo de cifrado simétrico GCM (Galois/Counter Mode), que es difícil de implementar correctamente, ignorando al mismo tiempo el modo OCB (Offset Codebook Mode), cuyo patente expiró hace varios años.
- Adición de paquetes opcionales con relleno aleatorio para proteger contra el análisis de tráfico. Según los creadores de LibrePGP, tales paquetes con relleno aleatorio inicial no verificable representan una amenaza para la creación de canales ocultos de transmisión de datos y para eludir sistemas de prevención de filtraciones de datos. Anteriormente, la idea de incluir relleno adicional fue rechazada, considerándola un asunto de nivel de aplicación y no de cifrado.
- Implementación 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.
- Eliminación de algunas funcionalidades prácticas, como el método clásico de revocación de claves, la bandera 'm' para marcar datos MIME y la bandera 't' para separar datos de texto de binarios (la bandera 't' fue reemplazada por la bandera 'u' para texto en codificación UTF-8).
- Decisión de no incluir en el nuevo formato de firmas la protección de los datos del metadato del archivo firmado (por ejemplo, es posible cambiar el nombre del archivo sin romper la firma).
- Cuestionable posibilidad de añadir 'sal' a las firmas (Salted Signature) para mejorar la protección contra ataques de colisión con prefijo específico. El valor con sal puede ser utilizado como un canal oculto permanente para transmitir 32 bytes de datos en la firma.
- Desplazamiento del estándar hacia un uso principal para la comunicación en línea, ignorando las necesidades de almacenamiento a largo plazo.
Los partidarios de OpenPGP ya han publicado críticas sobre la crítica. En consecuencia, si no se encuentra un compromiso, la división 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ón del formato de firmas en un formato compatible con LibrePGP y han comenzado a trabajar en la sexta versión.
Fuente: opennet.ru
