Gnupg es de código abierto (¡sí!) y, por lo tanto, puede consultarse qué sucede.
Cuando creas un certificado de revocación para una clave, es decir, a través de
'gpg --gen-revocar nombre "
se mueve internamente a través de las siguientes funciones / pasos clave
-
main() en gpg.c (la herramienta de línea de comando gpg) se llama, luego
- los parámetros se analizaron y luego
gen_revoce( const char *uname) en revoce.c se llama,
- dentro, luego recupera la clave secreta y pública para la uname
- luego llama a
make_keysig_packet en sign.c como este 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 el par de llaves (public pk y secret sk ) y proporciona además un puntero de función a revocation_reason_build_cb y una cadena con la revocación reason ).
- internamente,
make_keysig_packet luego usa un hash_algo para crear un md de resumen de mensaje, que finalmente se proporciona a complete_sig( sig, sk, md ); que internamente va a do_sign y usa cifrado asimétrico en el md .
- se crea el certificado de revocación creado (que es una especie de tipo firmado con el mensaje de clave privada / secreto).
Luego, en este certificado proporcionado a un servidor de claves, esto permitirá (como @WayToDoor) redactar el comentario a la clave en el servidor.
Solo la persona en posesión de la clave privada secreta puede firmar los mensajes que deben verificarse con la clave pública y, por lo tanto, una revocación es un "envío de un mensaje firmado de clave privada, hash del mensaje generado y cifrado asimétricamente". .
Mi opinión sobre lo que sigue es que, una vez revocada, el par de llaves se quema (no vale la pena).
Por lo tanto, sería inteligente haber utilizado una subclave para una clave de cifrado maestra más segura (con espacio de aire), lo que permite la reemisión de una nueva subclave de trabajo para reemplazar la clave revocada, sin la necesidad de un canal seguro verificar la clave pública de el nuevo subkey-keypair.