gpg --armor --export-secret-key difieren en los últimos 4 caracteres

Question

gpg --armor --export-secret-key difieren en los últimos 4 caracteres

#1 de Mike Ounsworth (0 votos)

2

Creé una copia de seguridad de una clave gpg haciendo:

gpg -a --export-secret-keys foo@bar > private.key
gpg -a --export foo@bar > public.key

Luego, en otro sistema, los importo:

gpg --import private.key
gpg --import public.key

Confié en la clave como definitiva, y la copia de seguridad parece estar funcionando, lo único que noté es que al hacer:

gpg --armor --export-secret-key foo@bar

Los últimos 4 caracteres difieren, por ejemplo:

dutrV4c4hoPc6ntI3n9VztsL4LmmvoCcH969nJD6bTh4H1VMH98r8zECshtCSfVE
tMIIhXjA9xO1IZ6vMqHJU8TNhV2ttOE1Z/sUjcB46X4=
=TGyi
-----END PGP PRIVATE KEY BLOCK-----

En la nueva computadora:

dutrV4c4hoPc6ntI3n9VztsL4LmmvoCcH969nJD6bTh4H1VMH98r8zECshtCSfVE
tMIIhXjA9xO1IZ6vMqHJU8TNhV2ttOE1Z/sUjcB46X4=
=/eDz
-----END PGP PRIVATE KEY BLOCK-----

Preguntándose por qué los últimos caracteres difieren, en este caso =TGyi y =/eDz

gnupg

pregunta nbari 15.08.2018 - 22:52

fuente

1 respuesta

Lea otras preguntas en las etiquetas gnupg

PCI Compliance y Git "Fallo en el mecanismo de protección (CWE ID 693)

score 0 · Answer 1

A LA ESPEC. DE ARMOR ASCII! - RFC 4880 . La especificación de ARMOR ASCII se proporciona en Sección 6.2 :

La concatenación de los siguientes datos crea una Armadura ASCII:


Una línea de encabezado de armadura, apropiada para el tipo de datos

Encabezados de armadura

Una línea en blanco (de longitud cero, o que solo contiene espacios en blanco)

Los datos blindados de ASCII

Una suma de control de armadura

La cola de armadura, que depende de la línea de encabezado de armadura

Así que los últimos 5 caracteres ( =TGyi y =/eDz ) son una suma de comprobación de los datos blindados. Curiosamente, la Sección 6.2 no define el formato de suma de comprobación, sino una versión anterior de la especificación, el Borrador de Internet de 1995 para PGP , hace:

La suma de comprobación de armadura es un CRC de 24 bits convertido a cuatro bytes de codificación radix-64, anteponiendo un signo igual (=) a los cuatro bytes código.

Las sumas de verificación que se utilizan en otros lugares son las RFC, siempre definidas como sumas de dos octetos, módulo 65536:

Luego se agrega una suma de comprobación de dos octetos, que es igual a la suma de los octetos clave de la sesión anterior, sin incluir el algoritmo identificador, módulo 65536.

Parece un poco extraño que dos copias de los mismos datos tengan diferentes sumas de comprobación, ... ¿tal vez haya suficiente ambigüedad en la especificación de que diferentes versiones de openpgp usan diferentes métodos para calcular la suma de comprobación?

(Descargo de responsabilidad: esta es la primera vez que me meto en la especificación de PGP, tal vez alguien más familiarizado pueda explicarlo correctamente)