Gnupg è open source (sì!) e quindi si può cercare cosa succede.
Quando si crea un certificato di revoca per una chiave, via
'gpg --gen-revoke name "
passa internamente attraverso le seguenti funzioni / passaggi chiave
-
main() in gpg.c (lo strumento della riga di comando gpg) viene chiamato, quindi
Parametri - analizzati e quindi
gen_revoce( const char *uname) in revoce.c è chiamato,
- all'interno quindi recupera la chiave segreta e pubblica per uname
- quindi chiama
make_keysig_packet in sign.c come questo rc = make_keysig_packet( &sig, pk, NULL, NULL, sk, 0x20, 0,
opt.force_v4_certs?4:0, 0, 0,
revocation_reason_build_cb, reason );
con la coppia di chiavi (pubblico pk e segreto sk ) e fornisce inoltre un functionpointer to revocation_reason_build_cb e una stringa con la revoca reason ).
- internally
make_keysig_packet quindi utilizza un hash_algo per creare un messaggio digest md, che viene infine fornito a complete_sig( sig, sk, md ); che richiama internamente do_sign e utilizza la crittografia asimmetrica su md .
- viene creato il certificato di revoca creato (che è una specie di tipo firmato con il messaggio chiave privata / segreta).
Quindi, in questo certificato fornito a un server delle chiavi, questo (come @WayToDoor è stato formulato) consentirà il commento alla chiave sul server.
Solo la persona in possesso della chiave privata segreta può firmare messsages da verificare con la chiave pubblica e quindi, una revoca è un "invio di un messaggio con chiave privata firmata, hash del messaggio generato e crittografato in modo assimetrico" .
La mia opinione sulla cosa ulteriore è che una volta revocata, la coppia di chiavi viene bruciata (inutilmente senza senso).
Quindi sarebbe stato intelligente aver usato una sottochiave per una chiave di crittografia master più sicura (con air gap), consentendo la riemissione di una nuova sottochiave funzionante per sostituire la chiave revocata, senza la necessità di verificare la chiave pubblica del canale sicuro la nuova sottochiave-keypair.