Usando: gpg (GnuPG) 2.0.22 libgcrypt 1.5.3
Estoy intentando descifrar un archivo desde un sitio remoto. Exporté nuestra clave a un archivo. gpg <filename>devuelve: (ID de clave cambiadas)
pub 2048R/656CC421 2018-04-19
sub 2048R/99F89J32 2018-04-19
Se lo envié al remitente y le pedí que lo importara, lo firmara y confiara en él.
Me enviaron dos archivos de claves diferentes. Usando gpg <filename>devoluciones:
1. pub 2048R/62568LK1 2015-09-03
2. pub 2048R/J561VE25 2015-09-23
Si hago una clave de edición, obtengo lo siguiente:
Mi llave:
Secret key is available.
pub 2048R/656CC421 created: 2018-04-19 expires: never usage: SC
trust: ultimate validity: ultimate
sub 2048R/99F89J32 created: 2018-04-19 expires: never usage: E
[ultimate] (1).
Sus claves:
1. pub 2048R/62568LK1 created: 2015-09-23 expires: never usage: SCE
trust: full validity: full
[ full ] (1).
2. pub 2048R/99F89J32 created: 2015-09-03 expires: never usage: SC
trust: full validity: full
[ full ] (1).
Estoy ejecutando el comando decrypt en un script bash con los siguientes parámetros.
echo $passphrase | /usr/bin/gpg --verbose --passphrase-fd 0 --no-tty --output $output_file --recipient myuser --decrypt $input_file
A continuación se muestra el resultado del comando:
Version: GnuPG v1.2.4 (MingW32)
gpg: armor header:
gpg: public key is 99F89J32
gpg: using subkey 99F89J32 instead of primary key 656CC421
gpg: using subkey 99F89J32 instead of primary key 656CC421
gpg: cancelled by user
gpg: encrypted with 2048-bit RSA key, ID 99F89J32, created 2018-04-19
"usrname (Description) <[email protected]>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key
Mi conclusión de todo esto es que el remitente debe enviarme su clave pública en el mismo formato que le envié. Como:
pub 2048R/J561VE25 2015-09-23
sub 2048R/SOM3NUMB 2015-09-23
Pensé que los archivos de claves que me enviaron no tienen la información de publicación/sub correspondiente y, por lo tanto, gpg no puede validarlo porque solo tengo una parte de la información de su par de claves.
¿Alguien puede decirme si estoy equivocado en esto o si mis pensamientos son correctos?
¡Gracias!
Respuesta1
Version: GnuPG v1.2.4 (MingW32)
Santas bolaseso es antiguo: la versión 1.2.4 se lanzó en2003. Al parecer, al remitente no le importa mucho actualizar su software de seguridad.
(Su propia versión 2.0.22 no es mucho mejor, con 2013 como fecha de lanzamiento).
gpg: public key is 99F89J32 gpg: using subkey 99F89J32 instead of primary key 656CC421 gpg: using subkey 99F89J32 instead of primary key 656CC421
Eso es normal. El par de claves "principal" sólo se utiliza para firmar (también conocido como certificar) otras claves; a menudo también para firmar mensajes. No se puede utilizar para el cifrado; siempre tiene una subclave para ese propósito.
(La separación también permite cosas como la firma fuera de línea o la rotación frecuente de claves de cifrado).
gpg: cancelled by user gpg: encrypted with 2048-bit RSA key, ID 99F89J32, created 2018-04-19 "usrname (Description) <[email protected]>" gpg: public key decryption failed: Operation cancelled gpg: decryption failed: No secret key
Parece que GnuPG intentó mostrar una frase de contraseña para desbloquearsupar de claves, pero la ventana de frase de contraseña no se pudo abrir o usted mismo la canceló accidentalmente.
La solicitud de contraseña se muestra en el navegador de GnuPG.entradacomponente, que a su vez se inicia medianteagente-gpg. Realmente no sé por dónde empezar a solucionar problemas en Windows, tal vezuna versión más nuevafuncionaría mejor. (Su GnuPG 2.0.22 se lanzó en 2013).
Las versiones más recientes, comenzando con GnuPG 2.1, admiten un modo de "pinentry de bucle invertido" que puede funcionar sin elentradacomponente. Si la actualización no ayuda por sí sola, intente activar esta opción.
que el remitente necesita enviarme su clave pública
La clave pública del remitente es inútil para el descifrado y sólo es necesaria para la verificación de la firma.
Como:
pub 2048R/J561VE25 2015-09-23Pensé que los archivos de claves que me enviaron no tienen la información de publicación/sub correspondiente y, por lo tanto, gpg no puede validarlo porque solo tengo una parte de la información de su par de claves.
No. Esta información está destinada atú, el usuario: resume el tipo de clave, la identificación corta (inútil) y la fecha de vencimiento. GnuPG puede extraerlo perfectamente de la propia clave, aunque no es necesario.
Respuesta2
Bueno, después de mucho ir y venir, encontré la solución en dos cambios.
pinentry-program /usr/bin/pinentry-cursesEra necesario agregar gpg-agent.conf .El guionista necesitaba agregar algo
--batcha su línea de comando.
Una vez hecho esto, gpg pudo obtener la clave secreta y descifrarla.
Gracias a gracity por responder. Se agradece su tiempo.