Forma correcta de reemplazar una clave GPG

1

Quiero crear una nueva clave GPG con un tamaño de clave más largo.
¿Cuáles son las mejores maneras de reemplazar la llave?
Mi clave actual está asociada con muchas cosas como GitHub, etc.
¿Debo revocar mi vieja llave y firmar la nueva con la antigua?
Entonces, ¿cuál es la mejor manera de hacerlo?

    
pregunta Emil 16.12.2018 - 18:24
fuente

1 respuesta

0

En tu pregunta

Al inspeccionar sus claves que están publicadas en servidores de claves públicas, veo que ya ha publicado su certificado de revocación para su clave anterior. El certificado de revocación incluye la huella digital de la nueva clave. Por lo tanto, su método parece aceptable, y probablemente sea mejor que muchos otros intentos en el proceso de transferencia de claves.

La gestión de claves personales es principalmente un ejercicio basado en la opinión. Las recomendaciones abundan, y algunas parecen mejores que otras. La firma cruzada de las claves públicas es probablemente un método mejor sin tener que recurrir a un servicio de seguimiento de identidades de terceros como keybase.io

Por lo general, es una buena idea revocar las claves solo cuando sea absolutamente necesario, como una clave privada perdida o una clave comprometida. Las implementaciones modernas de gpg crean un certificado de revocación como parte del proceso de generación de claves. En mi sistema Debian Buster, esos certificados se almacenan automáticamente en ~/.gnupg/openpgp-revocs.d Entonces, mientras uno mantenga el certificado de revocación, uno puede revocar una clave pública publicada a voluntad, independientemente de si uno recuerda o no la contraseña o tiene la clave privada.

La caducidad de las claves antiguas en lugar de revocarlas es probablemente el método mejor , porque la fecha de caducidad de una clave pgp se puede cambiar fácilmente a voluntad y se puede publicar en un servidor de claves públicas sin repercusiones permanentes. p>

Por último, siempre mantenga las llaves antiguas. No deseche las claves privadas pensando que ya no las necesitará. No se podrá acceder a todos los mensajes antiguos cifrados con claves públicas antiguas sin las claves privadas antiguas.

En servidores de clave pública

Cualquier persona puede publicar cualquier clave pública en un servidor de claves públicas. Por lo tanto, no es una buena idea confiar ciegamente en las claves descubiertas en servidores de clave pública. Los servidores de claves también están llenos de claves antiguas, comprometidas, caducadas y revocadas. Es muy difícil averiguar o verificar que una clave dada en un servidor de claves sea la clave correcta y actual para la comunicación con la información de identidad que se encuentra en la clave.

La idea original era que las personas con llaves se reunieran en reuniones de persona a persona denominadas partes clave para firmar para firmar las claves del otro y crear una web de confianza . Sin embargo, las partes de firma de claves no son tan comunes y la mayoría de las claves que he encontrado son simplemente autofirmadas con ninguna otra firma. Entonces, en la práctica general, la red de confianza no funciona tan bien para determinar qué clave pertenece a qué identidad y cuál es la clave más actual.

Estos son algunos de los problemas que keybase.io ha estado tratando de resolver. Keybase reemplaza la red de confianza persona a persona con el seguimiento de identidad verificado en servicios web de terceros, como Github. Sin embargo, el uso efectivo de keybase requiere que uno mantenga cuentas de terceros en servicios web que lo rastreen. Por lo tanto, el anonimato en línea tiene un gran éxito con el uso de la base de teclas. Algunos pueden decir que es una compensación aceptable, y algunos pueden no desear aceptar esa compensación.

    
respondido por el RubberStamp 17.12.2018 - 15:46
fuente

Lea otras preguntas en las etiquetas