No, sin embargo no es necesario. Algunas de sus presunciones son incorrectas para comenzar. Las cosas que señala como problemas de seguridad no son necesariamente problemas reales. Déjame entrar en más detalles.
MDC utiliza SHA-1 y MAC-then-Encrypt
El MDC está diseñado para evitar un descifrado del ataque oráculo , así como Corrupción accidental. Ambos de estos problemas se mitigan de manera efectiva incluso cuando se utiliza una función hash "modesta". De hecho, incluso MD5 probablemente no causaría problemas, considerando que el MDC actúa de manera similar a un MAC donde la resistencia a la colisión no importa. Usar una función hash más fuerte no le daría ningún beneficio real. Para tener garantías reales de integridad, debe firmar digitalmente el mensaje. Eso evitará una gran clase de ataques que MDC no puede hacer. En general, MDC no está diseñado para ofrecer una garantía sólida de integridad. No se pretende ni es capaz de hacerlo. Solo tiene la intención de protegerse de un ataque particular y oscuro, y de brindar cierta protección contra la corrupción accidental que pueda llevar a descifrar un mensaje confuso.
BLAKE2 y Whirlpool no son compatibles
Para firmar un mensaje, se utiliza una función hash. Para este propósito, SHA-256 y SHA-512 están bien. En esta situación, SHA-1 puede no ser ideal, y por esta razón, se está eliminando gradualmente en favor de funciones más fuertes. Si bien las funciones completamente diferentes pueden ser agradables, no es necesario para la seguridad. SHA-2 está bien. Son completamente resistentes a la preimagen y tienen muy buena resistencia a las colisiones. También tenga en cuenta que Whirlpool, aunque no está respaldado por NIST, se basa directamente en AES, que alguien que no confía en NIST puede querer evitar (no es que haya alguna razón para sospechar que es particularmente débil). Los ataques a los que SHA-2 es vulnerable (como los ataques de extensión de longitud) son completamente irrelevantes en la forma en que se utilizan en el formato OpenPGP. Cuando surja la necesidad, se pueden agregar más hashes.
Las curvas NIST se utilizan para ECC
Esto no es del todo cierto. Se usa una curva NIST (P-256, específicamente) cuando ECDSA está en uso, pero ECDSA está en desuso debido a la mismas debilidades que DSA normal tiene. Se admite, pero no se recomienda ni se requiere. Las versiones más recientes de GnuPG tienen una curva que no es NIST, específicamente Ed25519 para reemplazar ECDSA. No está tan bien soportado, pero es más rápido y tiene una seguridad superior. También me gustaría señalar que P-256 y otras curvas NIST no son "conocidas como comprometidas", como usted lo dice. El problema con el P-256 es que no usa los números de nada-arriba-mi-manga, lo que hace teóricamente posible que los valores se hayan elegido para habilitar una clase de ataques aún desconocidos. No hay evidencia real para eso, pero es bueno ser cauteloso. Esa es una de las razones por las cuales ECDSA está siendo reemplazado por Ed25519.
Los problemas reales
Hay problemas reales con GnuPG, pero no están entre las cosas que mencionaste. Estos problemas tienden a ser cosas nuevas que no eran una preocupación cuando se pensó en el formato OpenPGP:
- El secreto hacia adelante no está presente. El compromiso de la clave privada permite el descifrado retroactivo.
-
La criptografía post-cuántica no está en uso. NTRU sería genial, pero simplemente no es compatible.
-
La Web de confianza es difícil de lograr, por lo que la mayoría de las personas que usan PGP tienden a confiar en TOFU.
- GnuPG es muy complejo. Para analizar formatos complejos, un filtro de compás ajustado sería bueno.
- PGP involucra conceptos no intuitivos, lo que dificulta su uso. Esto dificulta gravemente las tasas de adopción.