Comparando claves supuestamente idénticas de OpenPGP publicadas a través de diferentes canales

4

versión tldr: Cuando trato de comparar claves públicas que se supone que son para la misma entidad, las versiones que obtengo a través de diferentes canales NO son las mismas y las que descargo como un archivo como somekey.sig.asc son archivos más pequeños.

Estoy tratando de aprender todo el gpg y practico usarlo correctamente. Un paso crucial es verificar que una clave pública, de hecho, pertenezca a la parte a la que se supone. En ausencia de una cadena de contactos personales, lo obvio es obtener múltiples copias de diferentes fuentes y verificar que sean idénticas. Nunca puedo hacer eso. Sospecho que parte del problema radica en las nuevas líneas, vueltas, espacios, tabulaciones y otros personajes inventados por el SCOPTDUI (Conspiración secreta de programadores para volver locos a los usuarios). Aquí hay un ejemplo donde estoy bastante seguro de que las claves SON idénticas, pero no puedo encontrar un procedimiento para probarlo.

Clave del equipo de Veracrypt del servidor de claves MIT: enlace

Clave del equipo de Veracrypt del sitio de Veracrypt: enlace

He descargado ambos directamente. He copiado y pegado ambos en archivos de texto. He quitado los preámbulos y los finales, dejando bloques que comienzan con el mismo alboroto y terminan con el mismo alboroto.

Los he corrido a través de todo tipo de filtros tr, como:

cat file | tr -d '0125' > file-tred

El de MIT es todavía un archivo mucho más grande. Los he cargado en gedit y puedo copiar partes sustanciales de una y buscar esa parte en la otra y encontrar una subcadena idéntica, pero no con todo el archivo.

Este no es un ejemplo aislado. MIT no es único. El segundo servidor de claves que revisé (en Nueva Zelanda, pero no puedo publicar un tercer enlace aquí) tiene el mismo problema. Tampoco es Veracrypt un caso especial. Me he topado con esto cada vez que he decidido aprender a hacer gpg de la "manera correcta" y golpear mi cabeza contra la misma pared por unos días antes de rendirme. ¿Hay alguna razón para que estas cosas no se publiquen de forma estandarizada? ¿Hay alguna manera de hacer esto fácil? ¿Me estoy perdiendo algo obvio? ¿Qué hace que ese archivo MIT sea tan grande?

Anexo: En la práctica:

gpg --keyserver address.like-this-with-no-protocol-prefix-and-no-trailing-slash.net --search SOMETHING

parece estar verificando duplicados de las claves que ya tengo e informando "sin cambios", siempre que escoja ALGO bien. Entonces, funcionalmente, supongo que esto está bien. Todavía me gustaría saber por qué fallan mis comparaciones manuales.

    
pregunta Lew Rockwell Fan 18.01.2016 - 00:47
fuente

2 respuestas

4

Un archivo de claves PGP no es una cadena de clave única , sino que contiene varias entradas (paquetes). En lugar de intentar comparar la representación ASCII de ambos archivos, debe usar las herramientas adecuadas, como gpg(1) y comparar las huellas digitales .

  

¿Hay alguna manera de hacer esto fácil?

Sí, así:

$ wget https://www.idrix.fr/VeraCrypt/VeraCrypt_PGP_public_key.asc
$ gpg --with-fingerprint VeraCrypt_PGP_public_key.asc
pub  rsa4096/54DDD393 2014-06-27
      Key fingerprint = 993B 7D7E 8E41 3809 828F  0F29 EB55 9C7C 54DD D393
uid                   VeraCrypt Team <[email protected]>

La huella digital mostrada debe ser igual para ambos archivos. Tenga en cuenta cómo los pocos bits más bajos del hash representan la ID de la clave ( EB559C7C54DDD393 ).

  

¿Hay alguna razón para que estas cosas no se publiquen de forma estandarizada?

Lo están, solo echa un vistazo a RFC 4880 para el OpenPGP Message Format especificación.

  

¿Por qué es tan grande ese archivo MIT?

Contiene mucho más paquetes de firma . De nuevo, desde el RFC:

  

Un mensaje OpenPGP se construye a partir de una serie de registros que son      Tradicionalmente llamados paquetes. Un mensaje OpenPGP, llavero,      certificado, y así sucesivamente se compone de una serie de paquetes.

Puede listar todos los paquetes en un archivo a través de --list-packets (o usar pgpdump(1) para una versión más legible).

$ gpg --list-packets VeraCrypt_PGP_public_key.asc

Esto producirá una enumeración como esta:

# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
    version 4, algo 1, created 1403892630, expires 0
    pkey[0]: [4096 bits]
    pkey[1]: [17 bits]
    keyid: EB559C7C54DDD393
# off=528 ctb=b4 tag=13 hlen=2 plen=35
:user ID packet: "VeraCrypt Team <[email protected]>"
# off=1137 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid D6BE7DAF738161CE
    version 4, created 1403950017, md5len 0, sigclass 0x10
    digest algo 2, begin of digest 08 92
    hashed subpkt 2 len 4 (sig created 2014-06-28)
    subpkt 16 len 8 (issuer key ID D6BE7DAF738161CE)
...

Como puede ver, el paquete de clave pública tiene el ID de clave familiar EB559C7C54DDD393 , mientras que los paquetes de firmas vienen con su ID de clave del respectivo emisor (que puede También busque en el servidor de claves).

Nota al margen: lo que llamas "preámbulo" se llama armadura ASCII y se usa para transfiera mensajes PGP a través de canales que tienen dificultades con datos binarios arbitrarios (por ejemplo, correos electrónicos). Es parte del formato y puede dejarlo en el archivo.

    
respondido por el Arminius 18.01.2016 - 05:21
fuente
2

tl; dr: ambos volcados contienen las mismas claves, pero obtiene algunas certificaciones adicionales del servidor de claves que no están incluidas en la exportación mínima del sitio web de VeraCrypt.

Paquetes OpenPGP

Las

claves OpenPGP están compuestas por un conjunto de paquetes OpenPGP , que pueden enumerarse por gpg --list-packets y pgpdump . Para las claves exportadas, hay un paquete requerido, el public key packet . Sneak peak (explicación a continuación): esto es lo mismo para ambas teclas.

:public key packet:
  version 4, algo 1, created 1403892630, expires 0
  pkey[0]: [4096 bits]
  pkey[1]: [17 bits]
  keyid: EB559C7C54DDD393

Una clave es difícilmente utilizable sin ningún paquete de ID de usuario. No puede ser consultado por un nombre y ni siquiera puede recibir certificaciones (las firmas en las claves apuntan a tuplas de huellas dactilares de claves públicas e ID de usuario).

:user ID packet: "VeraCrypt Team <[email protected]>"

Finalmente, generalmente se emite una autofirma. Los servidores de claves a menudo niegan las claves de carga sin autofirma.

:signature packet: algo 1, keyid EB559C7C54DDD393
  version 4, created 1403892630, md5len 0, sigclass 0x13
  digest algo 2, begin of digest 7f 33
  hashed subpkt 2 len 4 (sig created 2014-06-27)
  hashed subpkt 27 len 1 (key flags: 0F) 
  hashed subpkt 11 len 6 (pref-sym-algos: 9 8 7 3 2 1)
  hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11) 
  hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
  hashed subpkt 30 len 1 (features: 01) 
  hashed subpkt 23 len 1 (key server preferences: 80) 
  subpkt 16 len 8 (issuer key ID EB559C7C54DDD393)
  data: [4096 bits]

Exportaciones mínimas

Esta es la parte mínima más o menos necesaria de las claves para que la clave sea utilizable. Para cada una de las ID de usuario, opcionalmente se podría adjuntar una lista de las certificaciones entrantes, para ayudar a otros a verificar la clave. Esta es la razón más probable de los diferentes resultados.

Comparando las claves

Ahora, ¿cómo comparar las claves? En primer lugar, vamos a buscarlos en los archivos locales mit.asc y veracrypt.asc . diff ing ésos sería la forma general de comparar archivos, pero los archivos OpenPGP son difícilmente legibles, por lo que primero debemos enumerar sus contenidos y diferenciarlos:

gpg --list-packets mit.asc >mit.asc.list
gpg --list-packets veracrypt.asc >veracrypt.asc.list
diff mit.asc.list veracrypt.asc.list

El diff revela muchas firmas adicionales en el volcado del servidor de claves. Mirando a veracraypt.asc.list , parece que veracraypt.asc es una versión mínima, así que hagamos uso de las opciones de exportación de GnuPG para crear una copia mínima de mit.asc :

gpg --dearmor mit.asc # Dearmor first, to use it as keyring file
gpg --export-options export-minimal --no-default-keyring --keyring ./mit.asc.gpg \
    --export 0xEB559C7C54DDD393 >mit-minimal.asc
gpg --list-packets mit-minimal.asc >mit-minimal.asc.list

Diffing ahora revela que veracrypt.asc tiene exactamente una firma adicional:

:signature packet: algo 1, keyid D6BE7DAF738161CE
  version 4, created 1403950017, md5len 0, sigclass 0x10
  digest algo 2, begin of digest 08 92
  hashed subpkt 2 len 4 (sig created 2014-06-28)
  subpkt 16 len 8 (issuer key ID D6BE7DAF738161CE)
  data: [4091 bits]

Al menos una firma que afirma pertenecer al autor de VeraCrypt (aunque no validé la clave).

    
respondido por el Jens Erat 18.01.2016 - 10:49
fuente

Lea otras preguntas en las etiquetas