¿Hay alguna razón para que la ID de la clave de cifrado OpenPGP del video ISIS se encuentre fuera de la base 16?

  

¿Es posible en PGP cambiar la configuración para permitir una clave de cifrado fuera de la base 16?

Esto no está definido por OpenPGP (aunque no pude encontrar ninguna fuente que definiera una representación hexadecimal). Analicé un ejemplo similar en ¿Cómo se muestra esta clave OpenPGP en un formato no hexedecimal? , donde algunos caracteres han sido ilegible probablemente buscando el anonimato.

  

¿Hay configuraciones que permitan una clave de cualquier cosa que te guste?

En primer lugar, lo que se imprimió en el video era solo una clave ID , no una clave real. Las ID de clave son versiones abreviadas de la clave hash, porque sería una molestia pasar las grandes claves RSA de 4 kbits a otros (aunque ya es una molestia con las ID de clave y las huellas digitales).

Para volver a su pregunta: no, GnuPG no conoce esa opción. Puede elegir entre ID de clave corta y larga, y si prefijarlas con 0x para denotar números hexadecimales usando el parámetro --keyid-format y los valores short , 0xshort , long y 0xlong - no Opción para cualquier cosa no hexadecimal.

  

¿Existe una forma de retrasar el cifrado que explique las diferencias de fecha?

Esto puede suceder cuando se usan diferentes equipos para crear la clave y realizar operaciones con ella, cuando esos equipos tienen diferentes horarios configurados (con otras palabras, al menos uno de los equipos tiene un muy ajuste de reloj incorrecto).

Puede hacer cumplir fácilmente estas combinaciones cambiando la hora de su computadora o usando la herramienta faketime (cuando se compila con la configuración de depuración, GnuPG también conoce un parámetro --faketime ).

Mirando el mensaje propuesto, pasándolo a través de pgpdump que imprime los encabezados del paquete OpenPGP, revela alguna otra clave completamente distinta:

$ pgpdump
> -----BEGIN PGP MESSAGE-----
> Version: GnuPG v2
>  
> hQIMA9vC6Cu3Y8+AAQ/9GHzcyGJyXWR3vp3T9chiAOF/VkaBrZUlerKSSrH3O
> ual8yGt68kQP67AeZqu+mwN4qw+kouURJZp3deMfaEub42Umlzszhwdq6dL43
> E7h3OKL8RGngTchTNqHLZrVDBvaFSUCn9ihS1ua5LXqu3uiYi2oszfe3uFM
> Jsiu6YszAF+1nkqjqNS/FsKYwauZ/zPRUkJ+mFRs8uHYCgP9U6PdeFOBSpTXr+
> Frd6pd0YU1Gwyc84ldTwODSszmevaKICHNrbKHOcBlvBtpS9DZHciF88qYURB
> w3ggaCa847A28karOhdeBPSfchdRerOthtJG/LZ7wRthchtsOle/H9BAI
> ra4bex8sdjJUYEUl8nsXxsp8anAwoePW7JAjTXagyUYSSkaYh6Q6v8vmena5I
> qSEhAusCochQ/F5J9o+85jBQG4ththu50CMR29BchoV1pLRYh3ngsEG2mn8
> EMthdncJ+qNDwaG2TVu9Pynw5HYTAdeA1HiOxZ1quvU44SFgGSer27waa2
> L90m80bYquV66DA9/xT2y0xAX3SuWOSXsi+uqioAhdo+140Eth77CqXUEIrme
> idwx+FDv9KhBPsnT8HC/cMEUz+5beSULBOTDNTQt6YCarG50PngxkkdngssPS
> wJUBtKC7Fx3Tc1c1PSImv+WO3DTF9V41NquyvVA8DoDEMUOJKHLLS6DloFImLAE
> nglHZ/yMN+hEF+AKWOpGAg3Eyfpb3IC/waI4TOIfG71E0q+ich6w3DQZk00vP
> j52092IVKNf19h50LquL1Zulzn30erXBWNGan3NJ8802/jcgpudXD+DGWgIeP
> X3XL4denHyLPVzl6wtts7TwHHf2twaknaGhuROBWXz+rI/anSRy9Iqa7t1tng
> wQTubedN3tdFsOAy8hUvZSyJQ3NLpdNerttePaTQ5PzOoprTTq0d4bClthoT
> vaQlNTMlDehYAHscbe4D7bN2M2fnxUMQEthFYRZDUSMPCTyjHBTgX3DwEMAdY
> mkadYxczOKOKEL22CvSMa7aHAC5th1iHj+cF4jN1t4uLCinxOngsz+G+GqT
> meYOimS/g==
>  
> =UmHe
>  
> —--—-END PGP MESSAGE-----
Old: Public-Key Encrypted Session Key Packet(tag 1)(524 bytes)
    New version(3)
    Key ID - 0xDBC2E82BB763CF80
    Pub alg - RSA Encrypt or Sign(pub 1)
    RSA m^e mod n(4093 bits) - ...
        -> m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02
Old: Reserved(tag 0)(until eof)

Descargo de responsabilidad: Recuperé esta consulta al buscar los primeros caracteres hQIMA9vC6Cu3Y8 y encontré un documento pastebin que parece contener el mensaje, pero con errores de línea y otros problemas, parece una mala exploración de OCR. No verifiqué más, pero al menos es lo suficientemente correcto como para ser analizado. Si alguien los compara, siéntase libre de dejar un mensaje.

  

¿Es posible en PGP cambiar la configuración para permitir una clave de cifrado fuera de la base 16? ¿Hay configuraciones que permitan una clave de cualquier cosa que te guste?

No. Esa pieza de salida se muestra en la base 16 (hexadecimal) solo porque es una buena manera de mostrar datos binarios (en este caso un hashsum).

En este caso, es como si hubieran codificado un mensaje en código morse, y la salida, además de puntos y guiones, tenía comas y puntos y comas. El "mensaje" subyacente puede tener cualquier cosa, pero si lo muestra en morse (por ejemplo, para la transmisión de radio) no tendría comas.

  

¿Existe una forma de retrasar el cifrado que explique las diferencias de fecha?

No es que el cifrado se retrase, sino que el mensaje se cifra 3 días antes de que se haya creado la clave de cifrado.

Como si pudiera haber una explicación plausible, podrían haber generado la clave en una computadora y luego usarla en una diferente, con una de ellas (o ambas) con la fecha configurada incorrectamente. Sin embargo, lo más probable es que fueron dos piezas grabadas recientemente, con las fechas establecidas manualmente en el pasado, y nadie lo suficientemente inteligente como para notar que las fechas generadas eran inconsistentes.