ECC en (abierto) PGP

23

¿Qué tal el soporte para ECC (criptografía de curva elíptica) en (abierto) PGP hasta el momento? Parece que GnuPG (GNU Privacy Guard) no tiene una implementación oficial, pero encontré el gnupg-ecc project ( GnuPG habilitado para ECC por RFC 6637 ) en Google Code:

  

Este proyecto dio vida al soporte de criptografía de curva elíptica en   OpenPGP como una característica de usuario final. Los usuarios pueden simplemente seleccionar una clave ECC   Opción de generación en

     

gpg2 --gen-key

     

y luego usa el generado   clave pública como normalmente utilizarían cualquier otra clave pública, como se muestra    aquí .

Sé que Symantec es compatible con ECC. ¿Hay razones para no usar ECC?

EDIT

Investigué un poco más y descubrí que ECC encontró su camino hacia la línea principal de gnupg hace mucho tiempo, pero solo en versión de desarrollador :

$ gpg2 --expert --gen-key
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Please select what kind of key you want:
    (1) RSA and RSA (default)
    (2) DSA and Elgamal
    (3) DSA (sign only)
    (4) RSA (sign only)
    (7) DSA (set your own capabilities)
    (8) RSA (set your own capabilities)
    (9) ECDSA and ECDH
   (10) ECDSA (sign only)
   (11) ECDSA (set your own capabilities)
Your selection?'
    
pregunta esskar 19.04.2013 - 02:54
fuente

3 respuestas

24

Veo dos razones principales por las que es posible que no quieras usar ECC :

Razón práctica: la comunicación implica necesariamente dos partes, el remitente y el destinatario. ECC solo se puede utilizar si tanto el remitente como el receptor lo admiten. Como ha notado, las implementaciones existentes y desplegadas no están necesariamente en condiciones todavía; Si usa una clave pública de ECC, las personas pueden enviarle mensajes cifrados con esa clave o verificar sus firmas con esa clave, solo si su implementación de OpenPGP incluye el código correspondiente.

Por lo tanto, su elección de ECC o no depende de si desea maximizar la interoperabilidad o prefiere ser un "adoptador temprano" (aunque en el caso de ECC, realmente los primeros adoptadores ya están allí; el ECC se está convirtiendo en la corriente principal). / p>

Razón moral: matemáticamente, no tenemos pruebas de que ninguno de los algoritmos criptográficos que empleamos sea realmente sólido contra los ataques. Ni siquiera sabemos si es matemáticamente posible ser robusto contra los ataques. En este momento, el único método que tenemos para evaluar la fuerza de cualquier algoritmo criptográfico es definirlo, y luego dejar que muchos criptógrafos trabajen en él durante algunos años. Si ninguna de estas personas inteligentes encontró algo incorrecto en el algoritmo, entonces puede saber que si el algoritmo es débil, al menos no es obviamente débil.

Las curvas elípticas se han propuesto como objetos adecuados para la criptografía en 1985 (por Koblitz y Miller, de forma independiente). Las matemáticas de las curvas elípticas se han estudiado durante unos 40 años antes de eso. Así que ECC puede exhibir aproximadamente 70 años de exposición, 30 de los cuales se encuentran en un entorno definitivamente criptográfico. Eso no es malo.

Factorización de enteros , en la que se basa el RSA, puede presumir de 35 años de exposición criptográfica (el RSA se propuso en 1978) , y más que un 2500 años para las matemáticas subyacentes. Por lo tanto, se puede argumentar que la seguridad de RSA es "más entendida" que la de las curvas elípticas.

Personalmente, creo que el ECC es lo suficientemente maduro como para ser implementado, y dado que el ECC está muy de moda, las implementaciones se vuelven comunes y podemos esperar que GnuPG se alinee pronto. Por lo tanto, mi recomendación es: ECC está bien, siempre y cuando esté preparado para enfrentar algunos problemas de interoperabilidad durante algunos años.

(Un punto oscuro de la implementación de ECC es que hay muy pocas implementaciones de ECC "genéricas"; la mayoría de las implementaciones son específicas de un conjunto restringido de curvas admitidas, a menudo restringidas a las dos curvas NIST P-256 y P-384. la elección de la curva para su clave por lo tanto tiene un impacto no trivial en la interoperabilidad. Sin embargo, la P-256 está bien para la seguridad, por lo que puede usarla y dejar de preocuparse.)

    
respondido por el Thomas Pornin 19.04.2013 - 13:47
fuente
9

Actualmente, ECC es compatible con GnuPG 2.1 beta. Puede compilarlo desde la fuente y ver por sí mismo que se admiten las siguientes curvas:

nistp256 nistp384 nistp521 brainpoolP256r1 brainpool p384r1 brainpoolP512r1 secp256k1

    
respondido por el Adrian 01.07.2014 - 05:29
fuente
5

en GPG, por seguridad, uno se mantendría alejado del cerebro y las curvas nist. Las curvas de edDSA, montgomery y edwards están bien. ed25519 por suerte se está implementando sin subrterfuge por ahora.

Aunque es solo para firmar / certificar / autentificar. El cifrado seguirá.

las listas de correo en ietf.org son lugares brillantes para comenzar, y también están verificando cryp.to.

El uso de ECC con la implementación de Folly es peor que usar incluso RSA.

    
respondido por el Njomsky 03.02.2015 - 06:28
fuente

Lea otras preguntas en las etiquetas