Creando una clave privada con OpenSSL y encriptándola con AES GCM

3

Mi objetivo era crear una clave privada y cifrarla con un cifrado sólido. Esa clave se usaría como un certificado raíz para una Autoridad de Certificación interna.

Sin embargo, aunque openssl admite AES 128 GCM , no puedo generar ni cifrar una clave con este algoritmo de cifrado. OpenSSL reporta error writing key . El AES 128/256 GCM falló, sin embargo, AES 128 CBC funcionó. ¿Qué estoy haciendo mal? ¿Necesito parámetros adicionales al usar GCM?

Aquí está el comando:

$ openssl genpkey -out ca.key.pem -aes-128-gcm -algorithm rsa -pkeyopt rsa_keygen_bits:4096

La salida es esta:

.........................................................................+++
............................+++
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
Error writing key
:error:23077006:PKCS12 routines:PKCS12_pbe_crypt:EVP lib:p12_decr.c:96:
:error:2306C067:PKCS12 routines:PKCS12_item_i2d_encrypt:encrypt error:p12_decr.c:175:
:error:2307D067:PKCS12 routines:PKCS8_encrypt:encrypt error:p12_p8e.c:88:

Nota: la mayoría de los recursos en línea están desactualizados (nota al pie de página-1) y utilizan las marcas genrsa, o -nodes / -des reemplazadas. Así que utilizo esos recursos en línea como base, más las páginas man (también bastante obsoletas) de openssl y el indicador "-help" de los diversos comandos de openssl para crear el comando anterior, IMHO, actualizado.

En el comando anterior, he intentado reemplazar -aes-128-gcm con:

-aes-256-gcm
-aes-128-xts
-aes-256-xts

Y todos fallaron. Los XTS fallaron con el siguiente error:

:error:0D0A706C:asn1 encoding routines:PKCS5_pbe2_set_iv:cipher has no object identifier:p5_pbev2.c:103:
:error:2307D00D:PKCS12 routines:PKCS8_encrypt:ASN1 lib:p12_p8e.c:79:

Utilizando:

-aes-128-cbc (like in an example in the man page from genpkey)
-aes128
-aes256

Todo funcionó bien.

Extrañamente todos los cifrados anteriores son compatibles con la versión de openssl que estoy usando.

$ openssl enc -help 2>&1 | grep aes | egrep "128|256"
-aes-128-cbc               -aes-128-cfb               -aes-128-cfb1
-aes-128-cfb8              -aes-128-ctr               -aes-128-ecb
-aes-128-gcm               -aes-128-ofb               -aes-128-xts
-aes-192-gcm               -aes-192-ofb               -aes-256-cbc
-aes-256-cfb               -aes-256-cfb1              -aes-256-cfb8
-aes-256-ctr               -aes-256-ecb               -aes-256-gcm
-aes-256-ofb               -aes-256-xts               -aes128
-aes192                    -aes256

Nota: probado en Ubuntu 14.04.2, Debian 7.8 y CentOS 7. Todos mostraron el mismo comportamiento.

nota al pie-1 : si buscas en Google " openssl generar certificado raíz autofirmado ", ninguno de los 5 primeros resultados le dice que cifre su certificado raíz privado con algo mejor que triple DES!?! Un enlace de los 5 primeros enlaces aconseja 4096 bit, mientras que el otro proporciona 2048 o 1024!?! La mayoría no proporciona ningún indicador de cifrado, por lo que la clave no está cifrada. En realidad, solo el 7th link hace un trabajo decente al explicar qué y cómo hacerlo.

Actualización 20161218 : se probó nuevamente sin éxito en Ubuntu 16.04 LTS con openssl 1.0.2g.

    
pregunta Huygens 09.03.2015 - 17:03
fuente

1 respuesta

2

Respuesta actualizada:

De acuerdo con: enlace el soporte de gcm está actualmente roto v1.0.1f (lo que Ubuntu usa actualmente). Debería haber parches para la versión v1.0.1.g que luego debería tener un modo GCM viable. Sin embargo, actualmente solo me quedo con el modo CBC, ya que para el ajuste de clave es totalmente compatible desde openssl genrsa y openssl genpkey

  

Respuesta anterior:

     

Según la documentación: enlace

     

AESGCM    AES en el modo de contador de Galois (GCM): estos conjuntos de cifrado solo se admiten en TLS v1.2.

     

El registro de cambios de openssl para los estados de Ubuntu para una versión anterior:   openssl (1.0.1e-4ubuntu2) trusty; urgencia = bajo * Re-habilitar completo   Soporte TLSv1.2 (LP: # 1257877)       - debian / patches / tls12_workarounds.patch: deshabilita el parche para volver a habilitarlo         soporte TLSv1.2 completo. La mayoría de los sitios problemáticos han sido arreglados ahora, y         Realmente queremos un soporte adecuado de TLSv1.2 en un LTS. Actualmente he instalado 1.0.1f-1ubuntu9.1, así que al menos en teoría debería   trabajo. Pero te puedo asegurar, no lo hace. Tal vez los modos todavía están   considerado roto, pero estoy asumiendo.

    
respondido por el evildead 09.03.2015 - 20:27
fuente

Lea otras preguntas en las etiquetas