Esaminando un manuale di GnuPG su openskills , ho notato che l'id chiave principale GEBV933F è in un formato diverso dal solito esadecimale ( G non è una cifra esadecimale).
Come è fatto?
Esaminando un manuale di GnuPG su openskills , ho notato che l'id chiave principale GEBV933F è in un formato diverso dal solito esadecimale ( G non è una cifra esadecimale).
Come è fatto?
tl; dr: questi sono gli ID delle chiavi di qualcuno che cerca di nascondere le informazioni effettive. Non sono ID di chiavi OpenPGP validi.
seguenti RFC 4880, OpenPGP, 3.3 ID chiave , a
Key ID is an eight-octet scalar that identifies a key.
12.2 ID chiave e impronte digitali specifica ulteriormente il calcolo, ma ancora nessuna rappresentazione di quei 64 bit inferiori da utilizzare. Spesso, in pratica vengono utilizzati valori a 32 bit ("ID chiave breve"). Un esempio descrive abbastanza bene come sono collegati gli ID delle chiavi:
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 e GEBV933F formano gli ID chiave strani. Non possono essere esadecimali, il che non consentirebbe X e G . Probabilmente stanno usando un intervallo di cifre che corrisponde praticamente a tutte le cifre decimali più le lettere fino a X, il che significa che i numeri a otto cifre consentirebbero di memorizzare circa% bit% di bit - non abbastanza per una rappresentazione più compatta di ID di chiave (lunghi) .
Bene, non hai davvero bisogno di scavare in profondità. Supponiamo che la documentazione sia stata scritta da qualcuno che usa le chiavi real , che allo stesso tempo cerca di nascondere la sua identità e ha una cattiva comprensione degli ID delle chiavi, o vuole rivelare la manipolazione degli ID delle chiavi occhio esperto.
Il manuale citato fornisce anche esempi di firme codificate. Diamo un'occhiata a quelli! Una stringa ld(36^8) ~= 41 viene firmata, probabilmente usando la chiave dell'autore. E otteniamo anche il risultato quotato, che l'autore ha memorizzato come This is some text. :
The signed version will look something like this:
-----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-----
L'output che mostra gli ID chiave strani in realtà verifica una firma esattamente di questo file:
[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]"
Ora, cosa succede se lo eseguiamo da soli?
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
Ho rimosso l'ID utente in quanto l'utente potrebbe aver tentato di rimanere anonimo. Non mi importava della sua chiave ID / impronta digitale, perché in effetti l'ha postata e tutti possono interrogare le informazioni se lo desiderano.
Sorpresi di una corrispondenza ravvicinata degli ID della chiave?
real key ID: BEBB933F
claimed key ID: GEBV933F
Ovviamente, le due cifre non esadecimali sono state codificate. Ora, che dire di test.txt.asc ?
$ gpg --list-keys BEBB933F
pub 1024D/BEBB933F 2003-04-09
uid [uid removed]
uid [uid removed]
sub 1024g/CAC476E9 2003-04-09
Una nuova sottochiave! Di nuovo confrontando i tasti:
real key ID: CAC476E9
claimed key ID: XAF476E9
Ancora una volta, le due cifre differiscono.
Leggi altre domande sui tag encryption pgp gnupg decryption