Mirando un manual de GnuPG sobre openskills , observo que la clave principal id GEBV933F está en un formato diferente al hexadecimal habitual ( G no es un dígito hexadecimal).
¿Cómo se hace esto?
Mirando un manual de GnuPG sobre openskills , observo que la clave principal id GEBV933F está en un formato diferente al hexadecimal habitual ( G no es un dígito hexadecimal).
¿Cómo se hace esto?
tl; dr: se componen de ID de personas que intentan ocultar la información real. No son ID de clave de OpenPGP válidas.
Siguiendo a RFC 4880, OpenPGP, 3.3 ID de clave , a
La ID de clave es un escalar de ocho octetos que identifica una clave.
12.2 ID de clave y huellas digitales especifica aún más el cálculo, pero nuevamente no hay representación de esos 64 bits más bajos para ser utilizados. A menudo, los valores de 32 bits ("ID de clave corta") se usan en la práctica. Un ejemplo describe bastante bien cómo se relacionan los identificadores de claves:
fingerprint: 0D69 E11F 12BD BA07 7B37 26AB 4E1F 799A A4FF 2279 (160 bits)
long id: 4E1F 799A A4FF 2279 (64 bits)
short id: A4FF 2279 (32 bits)
XAF476E9 y GEBV933F forman ID de claves extrañas. No pueden ser hexadecimales, lo que no permitiría X y G . Probablemente estén usando un rango de dígitos que coincida con casi todos los dígitos decimales más las letras hasta X, lo que significa que los números de ocho dígitos permitirían almacenar alrededor de ld(36^8) ~= 41 bits, lo que no es suficiente para una representación más compacta de las ID de teclas (largas) .
Bueno, realmente no necesitas profundizar. Asumamos que la documentación fue escrita por alguien que usa las claves real , que al mismo tiempo intenta ocultar su identidad y que tiene una mala comprensión de las identificaciones clave o quiere revelar la manipulación de las identificaciones clave a la ojo experto.
El manual citado también proporciona ejemplos de firmas codificadas. Vamos a echar un vistazo a esos! Una cadena This is some text. se firma, probablemente usando la clave del autor. Y también obtenemos el resultado citado, que el autor almacenó como test.txt.asc :
La versión firmada se verá así:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is some text. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: 'Email me for my public key' iD8DBQE+ycRnF1uP4b67kz8RArZdAJ9e98RkcYICyJktEpah5/RoQX93vgCfUuOh 1I3aTPTGXitruRjhms3Kx7Y= =ju77 -----END PGP SIGNATURE-----
La salida que muestra las ID de claves extrañas en realidad verifica una firma de exactamente este archivo:
[you@tiger]$ gpg --verify test.txt.asc gpg: Signature made Tue 20 May 2003 04:00:07 PM EST using DSA key ID GEBV933F gpg: Good signature from "[email protected]"
Ahora, ¿qué sucede si ejecutamos esto por nuestra cuenta?
gpg: Signature made Tue May 20 08:00:07 2003 CEST
gpg: using DSA key BEBB933F
gpg: Good signature from "[uid removed]"
gpg: aka "[uid removed]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3318 D8EC 1EAD 3771 3B54 2893 175B 8FE1 BEBB 933F
Eliminé el ID de usuario porque el usuario podría haber intentado permanecer en el anonimato. No me importó su ID de clave / huella dactilar, ya que de hecho lo publicó y todos pueden consultar la información si lo desea.
¿Sorprendido por una coincidencia cercana de las ID de clave?
real key ID: BEBB933F
claimed key ID: GEBV933F
Obviamente, los dos dígitos no hexadecimales han sido codificados. Ahora, ¿qué pasa con XAF476E9 ?
$ gpg --list-keys BEBB933F
pub 1024D/BEBB933F 2003-04-09
uid [uid removed]
uid [uid removed]
sub 1024g/CAC476E9 2003-04-09
Una nueva subclave! Nuevamente comparando las claves:
real key ID: CAC476E9
claimed key ID: XAF476E9
De nuevo, dos dígitos difieren.
Lea otras preguntas en las etiquetas encryption gnupg pgp decryption