Prioridad de selección de subclave GnuPG durante el cifrado

3

Tengo el siguiente conjunto de 6 subclaves

$ gpg -K
...
ssb>  rsa2048 2017-10-04 [E] [expires: 2027-10-02]
ssb>  rsa2048 2017-10-04 [S] [expires: 2027-10-02]
ssb>  rsa2048 2017-10-04 [A] [expires: 2027-10-02]
ssb>  rsa2048 2015-02-12 [E] [expires: 2025-01-05]
ssb>  rsa2048 2016-01-05 [A] [expires: 2026-01-02]
ssb>  rsa2048 2016-08-20 [S] [expires: 2026-08-18]

El contexto es que compré una nueva tarjeta inteligente (Yubikey) y generé nuevas subclaves para ella. Quería mantener el registro de las subclaves antiguas en mi pubkey para que, por ejemplo, Github sigue mostrando mis antiguas confirmaciones firmadas con antiguas subclaves como "verificadas".

Sin embargo, me gustaría asegurarme de que a partir de ahora solo se usen las nuevas subclaves primarly . p.ej. Si alguien me envía un mensaje cifrado, quiero que utilicen la nueva subclave.

Noté que gpg -e usa mi nueva subclave de cifrado de forma predeterminada, por lo que funciona como estaba previsto, pero mi pregunta es ¿por qué ?

En otras palabras, ¿cómo determina gpg qué clave usar durante el cifrado ? ¿Se basa en el orden en que se guardan las subclaves en el archivo (como se indica arriba) o en la fecha de creación / vencimiento (la prioridad más reciente)?

    
pregunta Radek Simko 04.10.2017 - 22:51
fuente

1 respuesta

1

GnuPG siempre selecciona la clave (sub) válida más reciente para la operación respectiva (generalmente, la clave no revocada más reciente con un algoritmo compatible). Incluso si selecciona una subclave específica, GnuPG primero resuelve la clave primaria asociada y luego inicia este proceso de selección. Para anular esto, postfix ! a una clave dada. Esto es algo que podría hacer, por ejemplo, en su configuración de git si es necesario.

No conozco ninguna referencia normativa ( aparte del código GnuPG ): ni el RFC 4880 (OpenPGP) ni el manual o manual de GnuPG parecen definir el comportamiento. Las líneas de código relevantes de la función de comparación de claves:

if (old->validity == new->validity && uid_is_ok (&new->key, uid)
    && old->creation_time < new->creation_time)
  return -1;      /* Both keys are of the same validity, but the
                     NEW key is newer.  */
    
respondido por el Jens Erat 05.10.2017 - 10:33
fuente

Lea otras preguntas en las etiquetas