Jump to content

GnuPG (Español)

From ArchWiki

Este artículo o sección necesita ser traducido.

Notas: (Discusión en Talk:GnuPG (Español)#)

Related articles

De acuerdo al sitio web oficial:

GnuPG es una implementación gratis y completa del estándar OpenPGP como lo define RFC 4880 (también conocido como PGP). GnuPG le permite cifrar y firmar sus datos y comunicaciones; cuenta con un sistema versátil de manejo de claves, junto con módulos de acceso para todo tipo de directorios de claves públicas. GnuPG, también conocido como GPG, es una herramienta de línea de comando que posee características que facilitan la integración con otras aplicaciones. Se dispone de una gran cantidad de librerías y aplicaciones front-end. GnuPG también otorga apoyo para S/MIME y Secure Shell (ssh).
Advertencia GnuPG comenzó como una implementación del formato OpenPGP. Sin embargo, en años recientes su mantenedor se ha alejado activamente del esfuerzo de estandarización de OpenPGP, y está extendiendo el formato por separado, en un modo único a GnuPGP (vea draft-koch-librepgp). Estos cambios están causando problemas de compatibilidad con otras implementaciones desde la versión 2.4. Vea #OpenPGP compatibility.

Instalación

gnupg ya debería estar instalado en su sistema, al ser una dependencia de pacman.

Esto también instalará pintentry[enlace roto: package not found], una colección de diálogos de entrada de frases de contraseñas o PIN simple, que GnuPG utiliza para la entrada de contraseñas (permitiéndole leerlas de manera segura). El guión de concha /usr/bin/pinentry determina cuál diálogo pinentry será usado, en el orden descrito en #pinentry.

Si quiere usar un front-end gráfico o un programa que se integra con GnuPG, vea List of applications/Security#Encryption, signing, steganography.

Configuración

Carpeta de Usuario

La carpeta de usuario de GnuPG es el sitio en el cuál el suite GnuPG guarda sus anillos de claves y claves privadas, y de donde lee configuraciones. Por defecto, la ruta utilizada es ~/.gnupg. Existen dos métodos para modificar esto:

Por defecto, la carpeta de usuario tiene sus Permisos configurados en 700, y los archivos que contiene tiene sus permisos configurados en 600. Solamente el dueño del directorio tiene permiso de leer, escribir y acceder a los archivos. Esto es por motivos de seguridad, y no debe ser modificado. En caso de que este directorio o cualquier archivo dentro de aquel no cumpla esta medida de seguridad, usted recibirá avisos sobre permisos de archivos carpeta de usuario inseguros.

Archivos de configuración

Todo el comportamiento de GnuPG es configurable mediante argumentos de línea de comando. Los argumentos que usted quisera establecer como defectos, los puede añadir al respectivo archivo de configuración:

  • Comprobaciones gpg gnupg_home/gpg.conf (usuario) y /etc/gnupg/gpg.conf (global) [2]. Como gpg es el punto de entrada principal para GnuPG, la mayoría de la configuración importante se encontrará aquí. Vea Opciones GPG para conocer las opciones posibles.
  • Comprobaciones dirmngr gnupg_home/dirmngr.conf y /etc/gnupg/dirmngr.conf. dirmngr es un programa invocado internacionalmente por gpg para acceder a servidores de claves PGP [3]. Vea Opciones Dirmngr para conocer las opciones posibles.

Estos dos archivos de configuración cubren los casos de uso más comunes, pero existen más programas auxiliares en el suite GnuPG con sus propias opciones. Vea el manual GnuPG para una lista completa.

Cree los archivos deseados, y configure sus permisos en 600 como se discutió en Carpeta de Usuario

Añada todas las opciones que quiera a estos archivos. No escribo los dos guiones, sinó solamente el nombre de la opción y los argumentos requeridos. Por ejemplo, para que GnuPG siempre utilize un anillo de claves en una ruta específica, como si fuese invocado como gpg --no-default-keyring --keyring keyring-path ...: 

gnupg_home/gpg.conf (or /etc/gnupg/gpg.conf)
no-default-keyring
keyring keyring-path

Otros ejemplos se encuentran en #Véase también.

Adicionalmente, pacman utiliza un conjunto diferente de archivos de configuración para las verificaciones de firmas de paquetes. Vea Pacman/Firmas de paquetes para más detalles.

Opciones de defecto para usuarios nuevos

Si usted quiere configurar algunas opciones de defecto para nuevos usuarios, ubique archivos de configuración en /etc/skel/.gnupg/. Cuando el usuario nuevo sea añadido al sistema, archivos de esta ruta serán copiados a su carpeta de usuario de GnuPG. También existe un guión simple llamado addgnupghome, el cual usted puede usar para crear nuevas carpetas de usario de GnuPG para usuarios existentes: 

# addgnupghome user1 user2

Esto añadirá, respectivamente, /home/user1/.gnupg/ and /home/user2/.gnupg/ y copiará los archivos del directorio esquelético a él. Usuarios con una carpeta de usuario de GnuPG existente son omitidos.

Uso

Nota
  • Cuando user-id sea requerido en un comando, puede ser especificado con su ID de clave, huella, parte de su nombre o correo electrónico, etc. GnuPG es flexible en este sentido.
  • Cuando se necesita un key-id, lo puede encontrar añadiendo --keyid-format=long al comando. Para mostrar la clave maestra secreta, por ejemplo, ejecuta gpg --list-secret-keys --keyid-format=long user-id, el key-id es el hash hexadecimal entregado en la misma línea que sec.

Crear una pareja de claves

Genere una pareja de claves escribiendo en una consola: 

$ gpg --full-gen-key
Advertencia Al usar --full-gen-key la clave generado anunciará un mecanismo AEAD, el cual no es comprendido por otras implementaciones OpenPGP. Para desabilitar esto posterior a la creación de la clave vea Desabilitar mecanismo AEAD no soportado.

También añada la opción --expert a la línea de comando para acceder a más cifrados, particularmente algunas curvas elípticas nuevas, como Curve448.

El comando pedirá respuestas a varias preguntas. Para uso general, la mayoría de usuarios querrán:

  • El defecto ECC (sign and encrypt) para claves de cifrado y firmas.
  • El defectoCurve 25519 para usar Curve25519 y Ed25519.
  • Una fecha de expiración: un periodo de un año es suficiente para el usuario promedio. De este modo, incluso si se pierde acceso a la clave, permitirá que otros usuarios sepan que ya no es válida. Si es necesario, en una etapa posterior, es posible extender la fecha de expiración sin tener que entregar una nueva clave.
  • Su nombre y dirección de correo electrónico. Puede añadir múltiples identidades a la misma clave más tarde (por ejemplo, si usted tiene varios correos que quisiera asociar a esta clave).
  • no comentario opcional. Como la semántica del comentario no está bien definida, tiene un valor limitado para identificación.
  • Una contraseña segura, encuentre guías en Seguridad#Escogiendo claves seguras.
Nota El nombre y correo que especifique aquí serán vistos por cualquiera que importe su clave.
Tip La opción más simple --gen-key usa parámetros de defecto para el cifrado de la clave, el tamaño y la fecha de expiración, pidiendo tan solo real name (nombre real) y email address (correo electrónico).

--JG27 (talk) 04:51, 21 June 2026 (UTC)

Listar claves

Para mostrar las claves en tu anillo de claves públicas: 

$ gpg --list-keys

Para mostrar las claves en tu anillo de claves secretas: 

$ gpg --list-secret-keys

Exportar una clave pública

El principal uso de GnuPG es asegurar la confidencialidad de los mensajes intercambiados usando criptografía de claves públicas. Con él, cada usuario distribuye la clave pública de su anillo de claves, que puede ser usada por otros para cifrar mensajes para el usuario. La clave privada siempre debe ser privada, de otro modo, no existe confidencialidad. Vea Wikepedia:Public-key cryptography para ejemplos del intercambio de mensajes.

Así, para que otros puedan enviarle mensajes cifrados, necesitan su llave pública.

Para generar una versión ASCII de la llave pública de un usuario al archivo public-key.asc (e.g. para distribuirla por correo electrónico): 

$ gpg --export --armor --output public-key.asc user-id

Alternativamente, o en adición, puede Usar un servidor de claves para compartir su clave.

Tip
  • Agregue --no-emit-version para evitar imprimir el número de la versión, o añada la configuración correspondiente a su gpg.conf.
  • Puede omitir el user-id para exportar todas las claves públicas dentro de su anillo de claves. Esto es útil si quiere compartir varias identidades a la vez, o para importar en otra aplicación, e.g. Thunderbird.

Importar una clave pública

Para cifrar mensajes a otros, así como verificar sus firmas, necesita su llave pública. Para importar una clave públcia con el nombre de archivo public-key.asc a su anillo de claves públicas: 

$ gpg --import public-key.asc

Alternativamente, intente obtener su clave pública via WKD (en el caso de que el dominio de su correo electrónico lo apoye) o usando un servidor de claves.

Si usted desea importar un ID de clave para instalar un paquete de Arch Linux específico, vea pacman/Package signing#Managing the keyring (Español) and Makepkg#Signature checking (Español).

Usar un servidor de claves

Enviar claves

Puede registrar su clave con un servidor de claves públicas PGP, para que otros la puedan obtener sin tener que contactarle directamente: 

$ gpg --send-keys key-id
Advertencia Hay servidores de claves donde las claves enviadas no pueden ser borradas. Algunos de los motivos se explican en MIT PGP Public Key Server FAQ.
Nota El correo electrónico asociado, al ser compartido públicamente, puede ser víctima de spammers, y en este caso puede ser necesario realizar filtramiento anti-spam.

Buscar y recibir claves

Para conocer detalles de una clave en un servidor de claves, sin importarla, haga: 

$ gpg --search-keys user-id

Para importar una clave de un servidor de claves: 

$ gpg --receive-keys key-id

Para refrescar/actualizar la cadena de claves con la última version de un servidor de claves: 

$ gpg --refresh-keys
Advertencia
  • Usted debería verificar la autenticidad de la clave pública obtenida comparando su huella con una que el/la dueño/a publicó en fuentes independientes (e.g., contactando a la persona directamente). Vea Wikipedia:Public key fingerprint para más información.
  • Es recomendado usar el ID largo de la clave, o la huella completa, al recibir una clave. Al usar un ID corto puede encontrarse en colisiones. Todas las claves que tengan el ID corto serán importadas, vea fake keys found in the wild para ejemplos.
Tip Añadir auto-key-retrieve al Archivo de configuración GPG obtendrá las claves necesitadas del servidor de claves automáticamente. Esto no compromente la seguridad, pero sí puede ser considerado una violación de privacidad, vea "web bug" en gpg(1) § auto-key-retrieve.

Servidores de claves

Vea OpenPGP#Servidor de claves para un resumen general de los servidores de claves OpenPGP y sus características.

Un servidor de claves alternativo puede ser especificado con la opción keyserver en uno de los archivos de configuración, por ejemplo: 

~/.gnupg/dirmngr.conf
keyserver hkp://keyserver.ubuntu.com

El uso temporal de otro servidor es útil cuando el servidor regular no funciona adecuadamente. Esto puede ser logrado, por ejemplo, del siguiente modo: 

$ gpg --keyserver hkps://keys.openpgp.org/ --search-keys user-id
Tip
  • Si usted está experimentado fallos relacionados al servidor de claves, puede ser útil revisar su DNS y sus configuraciones de resolvedor o sus logs de antemano (e.g. systemd-resolved).
  • Si la recepción falla con el mensage gpg: keyserver receive failed: Connection refused, intente usar otro servidor DNS.
  • Si no logra conectar a un servidor de claves con el mensaje gpg: keyserver receive failed: Server indicated a failure, puede necesitar configurar gpg para usar un puerto alternativo. Por ejemplo, para usar port 80 en el servidor de claves de Ubuntu, use keyserver hkp://keyserver.ubuntu.com:80.
  • Puede conectar al servidor de claves sobre Tor con Tor#Torsocks; o usar la opción de línea de comando --use-tor. Vea [4] para más información.
  • Puede conectarse a un servidor de claves utilizando un proxy, al configurar la variable de entorno honor-http-proxy y establecer honor-http-proxy en dirmngr.conf. Alternativamente, configure http-proxy host[:port] en el archivo de configuración para anular la variable de entorno del mismo nombre. Reinicie el servicio de usuario dirmngr.service para que los cambios hagan efecto.

Directorio de Claves Web

Vea OpenPGP#Web Key Directory para un resumen general.

Buscar certificados usando WKD

Al cifrar para una dirección de correo electrónico (e.g. usuario@ejemplo.org), si no está en el anillo de claves local, GnuPG, por defecto, obtendrá la clave pública OpenPGP utilizando el protocolo de Directorios de Claves Web (Web Key Directory o WKD en inglés), es decir, GnuPG descargará la clave via HTTPS desde el servidor web ejemplo.org. Por ejemplo: 

$ gpg --recipient user@example.org --encrypt doc

Para obtener una clave pública e importarla a su anillo de claves, utilize la opción--locate-keys o --locate-external-keys. La primera no hará nada si la clave ya existe en el anillo de claves local, mientras que la segunda siempre actualizará la clave. Por ejemplo: 

$ gpg --locate-external-keys user@example.org
Nota La obtención automática de claves de GnuPG es controlada con la opción --auto-key-locate, que se establece por defecto en local,wkd; vea su descripción en gpg(1). En caso de que usted haya establecido auto-key-locate en un valor sin wkd en el archivo de configuración GPG, puede utilizar la opción de línea de comando --auto-key-locate clear,wkd para suprimirlo.

Crear un WKD

Si usted controla el dominio de su correo electrónico personalmente, y tiene un servidor web que le provee HTTPS con un certificado TLS de confianza, puede seguir esta guía ppara habilitar WKD en su dominio.

Cifrado y Descifrado

Asimétrico

Usted necesita importar una clave pública de un usuario antes de cifrar (opción -e/--encrypt) un archivo o mensaje para dicho receptor (opción -r/--recipient). Adicionalmente, necesita crear una pareja de claves si no lo ha hecho previamente.

Para cifrar un archivo con el nombre doc, use: 

$ gpg --recipient user-id --encrypt doc

Para descifrar (opción -d/--decrypt) un archivo con el nombre doc.gpg cifrado con su clave pública, use: 

$ gpg --output doc --decrypt doc.gpg

gpg le pedirá su contraseña, y luego descifrará y escribirá los datos de doc.gpg a doc. Si usted omite la opción -o/--output, gpg escribirá los datos descifrados a stdout.

Tip
  • Agregue --armor para cifrar un archivo usando armadura ASCII, útil para copiar y pegar un mensaje en formate de texto.
  • Use -R user-id o --hidden-recipient user-id en vez de -r para no incluir el ID de clave del receptor en el mensafe cifrado. Esto ayuda a esconder la identidad de los receptores del mensaje, y es una contramedida limitada para el análisis de tráfico.
  • Agregue --no-emit-version para evitar imprimir el número de versión, o aqreque la configuración correspondiente a su archivo de configuración.
  • Usted puede usar GnuPG para cifrar sus documentos sensibles o privados, al usar su propio ID de usuario como receptor, o al usar la bandera --default-recipient-self; sin embargo, solamente puede hacer esto un archivo a la vez, aunque siempre puede hacer 'tarball' (agrupar) a varios archivos y luego cifrar el tarball. Véase también Cifrado de datos-en-descanso#Métodos disponibles si quiere cifrar directorios o un sistema de archivos completo.

Simétrico

El cifrado simétrico no requiere la generación de una pareja de claves, y puede ser usado para simplemente cifrar datos con una contraseña. Use -c/--symmetric para realizar un cifrado simétrico: 

$ gpg -c doc

El siguiente ejemplo:

  • Cifra doc con un cifrado simétrico utilizando una contraseña
  • Utiliza el algoritmo de cifrado AES-256 (AES-256 cipher) para cifrar los datos
  • Utiliza el algoritmo de digestión SHA-512 (SHA-512 digest algorithm) para barajar la contraseña y generar la clave de cifrado
  • Baraja la contraseña en 65536 iteraciones
$ gpg -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 65536 doc

Para descifrar un archivo doc.gpg cifrado simétricamente utilizando una contraseña, y pasar los datos descifrados al mismo directorio que doc, use: 

$ gpg --output doc --decrypt doc.gpg

Directorio

Se puede cifrar/descifrar un directorio con gpgtar(1).

Cifrar: 

$ gpgtar -c -o dir.gpg dir

Descifrar: 

$ gpgtar -d dir.gpg

Mantención de claves

Respaldando su clave privada

Para respaldar su clave privada haga lo siguiente: 

$ gpg --export-secret-keys --armor --output private-key.asc user-id

Si la clave privada está protegida con una contraseña, el archivo de clave exportado será protegido por la misma.

GnuPG podría pedirle entrar la contraseña para la clave. Esto es requerido, porque el método de protección interna de la clave secreta es distinto al método especificado por el protocolo OpenPGP. [5]

Advertencia
  • La contraseña usualmente es el eslabón más debil en la protección de su clave secreta. Ubique la clave secreta en un sistema o aparato diferente, como un contenedor con llave o un drive cifrado. Es el único seguro que tiene para recuperar el control de su anillo de claves en caso de, por ejemplo, un fallo del drive, un robo, o peor.
  • Este método de respaldar la clave tiene algunas limitaciones de seguridad. Vea el post en VHSblog Moving GPG Keys Privately para conocer una manera potencialmente más segura de respaldar e importar claves utilizando gpg.

Para importar el respaldo de su clave privada: 

$ gpg --import private-key.asc
Tip Paperkey puede ser usado para exportar claves privadas como texto legible para el ser humano, o códigos de barras legibles por máquinas, que pueden ser impresos en papel y archivados.

Respaldando su certificado de revocación

Para claves recién generadas, se crea automáticamente el certificado de revocación. Estos se ubican por defecto en ~/.gnupg/openpgp-revocs.d/. El nombre del archivo del certificado es la huella de la clave que revocaría. Los certificados de revocación también pueden ser generados más tarde por el usuario, manualmente, utilizando: 

$ gpg --gen-revoke --armor --output revcert.asc user-id

Este certificado puede ser usado para revocar una clave si esta ha sido perdida o comprometida. El respaldo será útil si ya no tiene acceso a la clave secreta, y por lo tanto no puede generar un nuevo certificado de revocación con el comando de arriba. Es lo suficientemente corto para ser impreso en papel, y tecleado a mano si resulta necesario.

Advertencia Cualquiera que tenga acceso al certificado de revocación puede públicamente revocar la clave. Esta acción no se puede deshacer. Proteja su certificado de revocación de la misma manera en la que proteje su clave secreta.

Edite su clave

Al ejecutar el comando gpg --edit-key user-id, se presentará un menú que le permite realizar la mayoría de las tareas relacionadas al manejo de claves.

Escriba help en el sub menú abierto por --edit-key para mostrar la lista completa de comandos. Algunos de los útiles son: 

> passwd       # cambiar la contraseña
> clean        # compactar cualquier ID de usuario que ya no sea usable (e.g. revocado o expirado)
> revkey       # revocar una clave
> addkey       # añadir una subclave a esta clave
> expire       # cambiar la fecha de expiración de la clave
> adduid       # añadir nombres, comentarios y direcciones de correo electrónico adicionales
> addphoto     # añadir una foto a la clave (debe ser JPG, recomendablemente 240x288, entre ruta completa a la imagen cuando se lo pida)
Tip Si usted tiene varias cuentas de correo, puede añadir cada una de ellas como una identidad, usando el comando adduid. Luego, puede establecer su cuenta favorita como primary.

Exportar una subclave

Si usted planea utilizar la misma clave en varios dispositivos, puede desear excluir su clave maestra y solo guardar la clave de cifrado más mínima necesaria en sistemas menos seguros.

Primero, averigüe cuál subclave desea exportar: 

$ gpg --list-secret-keys --with-subkey-fingerprint

Selecciones solo esa subclave para exportar: 

$ mktemp -d
/tmp/tmp.XXXXXXXXXX

$ gpg --armor --export-secret-subkeys --output /tmp/tmp.XXXXXXXXXX/subkey.asc subkey-id!
Advertencia Si se le olvida agregar la marca de exclamación (!, todas sus subclaves serán exportadas

A este punto podría detenerse, pero probablemente es buena idea también cambiar la contraseña. Importe la clave a una carpeta temporal. 

$ gpg --homedir /tmp/tmp.XXXXXXXXXX --import /tmp/tmp.XXXXXXXXXX/subkey.asc
$ gpg --homedir /tmp/tmp.XXXXXXXXXX --edit-key user-id
> passwd
> save
$ gpg --homedir /tmp/tmp.XXXXXXXXXX --armor --output /tmp/tmp.XXXXXXXXXX/subkey.altpass.asc --export-secret-subkeys subkey-id!
Nota Recibirá una advertencia de que la clave maestra no estaba disponible y la contraseña no fue modificada, pero esto puede ser ignorado sin problema, ya que la contraseña de la subclave sí se cambió.

A esto punto, usted puede utilizar /tmp/tmp.XXXXXXXXXX/subkey.altpass.asc en sus otros dispositivos.--JGV (talk) 00:26, 22 June 2026 (UTC)

Extendiendo la fecha de caducidad

Advertencia Nunca borre sus subclaves caducadas o revocadas sin tener un buen motivo. Esto solamente le causará perder la abilidad de descifrar archivos cifrados con la subclave antigua. Por favor, solamente borre claves caducadas o revocadas de otros usuarios para limpiar su anillo de claves.

Es de buena práctica establecer una fecha de caducidad para sus subclaves, con tal de que si pierde acceso a la clave (e.g. se le olvida la contraseña), la clave no seguirá siendo usada indefinidamente por otros. Cuando la clave haya caducado, es relativamente simple extender la fecha de caducidad: 

$ gpg --edit-key user-id
> expire

Se le pedirá una nueva fecha de caducidad, al igual que la contraseña de su clave secreta, la cual es usada para firmar la nueva fecha de caducidad.

Tip Puede especificar una fecha y hora de caducidad exacta escribiendo una fecha con el formato YYYY-MM-DD o YYYYMMDDThhmmss para especificar la hora.

Repita esto para cualquier otra subclave que haya caducado: 

> key 1
> expire

Finalmente, guarde los cambios y salga: 

> save

Actualízelo a un servidor de claves: 

$ gpg --keyserver keyserver.ubuntu.com --send-keys key-id

Alternativamente, si usa esta clave en varios computadores, puede exportar la clave pública (con fechas de caducidad nuevas y firmadas) e importarla en esas máquinas:, 

$ gpg --export --output pubkey.gpg user-id
$ gpg --import pubkey.gpg

No hay necesidad de re-exportar su clave secreta o actualizar sus respaldos: la clave secreta maestra nunca caduca, y la firma de la fecha de caducidad en la clave pública y las subclaves es lo único que se necesita.

Rotar subclaves

Advertencia Nunca borre sus subclaves caducadas o revocadas a menos que tenga un buen motivo para hacerlo. Esto solamente le causará perder la habilidad de descifrar archivos cifrados con la subclave antigua. Por favor, solamente borre claves caducadas o revocadas de otros usuarios para limpiar su anillo de claves.

Alternativamente, si usted prefiere dejar de usar subclaves por completo una vez hayan caducado, puede crear algunas nuevas. Haga esto con vaias semanas de adelanto para permitirle a otros actualizar su anillo de claves.

Tip No es necesario crear una nueva clave solamente porque haya caducado. Puede extender la fecha de caducidad, vea Extendiendo la fecha de caducidad.

Cree una nueva subclave (repita para clave de cifrado y firma): 

$ gpg --edit-key user-id
> addkey

Responda las preguntas que se le harán (vea Creando una pareja de claves para opciones de configuración sugeridas).

Guarde sus cambios: 

> save

Súbala a un servidor de claves: 

$ gpg --keyserver pgp.mit.edu --send-keys user-id

Usted también necesitará exportar una copia nueva de sus claves secretas para respalos. Vea respaldar su clave secreta para instrucciones y detalles sobre esto.

Tip Revocar subclaves caducadas no es necesario, y se considera mala costumbre. Si usted constantemente revoca claves, puede causar desconfianza en usted.

Revocar una clave

La revocación de una clave debe realizarse si la clave está comprometida, reemplazada, en desuso, o se le olvidó su contraseña. Esto se hace combinando la clave con el certificado de revocación de la clave.

Si usted ya no tiene acceso a su pareja de claves, primero importe una clave pública para importar su propia clave.

Luego, para revocar la clave, importe el archivo guardado en Respalde su certificado de revocación: 

$ gpg --import revcert.asc

Ahora la revocación debe hacerse pública. Use un servidor de claves para enviar la clave revocada a un servidor PGP público si ha usado uno en el pasado, de otra manera, exporte la clave revocada a un archivo y distribúyala a sus parejas de comunicación.

Firmas

Las firmas certifican y marcan el tiempo de los documentos. Si un documento ha sido modificado, la verificación de su firma fallará. A diferencia del cifrado, que usa la clave pública del receptor para cifrar un documento, las firmas se crean con la clave privada del emisor. Luego, el receptor del documento firmado verifica la firma usando la clave pública del emisor.

Crear una firma

Firmar un archivo

Para firmar un archivo utilize la bandera -s/--sign: 

$ gpg --output doc.sig --sign doc

doc.sig contiene tanto el contenido comprimido del archivo original doc como la firma en formato binario, pero el archivo no está cifrado. Sin embargo, usted puede combinar la firma con el cifrado.

Firmar un archivo sin comprimirlo

Para firmar un archivo sin comprimirlo a formato binario, use: 

$ gpg --output doc.sig --clearsign doc

Así, tanto el contenido del archivo original doc como la firma son guardados en formato legible por el ser humano en doc.sig.

Crear una firma separada

Para crear un archivo con firma por separado para distribuirlo independientemente del documento o archivo en sí mismo, use la bandera --detach-sig: 

$ gpg --output doc.sig --detach-sig doc

Así, la firma se guarda en doc.sig, pero los contenidos de doc no se guardan ahí. Este método se usa frecuentemente en la distribución de proyectos de software para permitirles a los usuarios verificar que el programa no ha sido modificado por terceros.

Verificar una firma

Para verificar una firma use la bandera --verify: 

$ gpg --verify doc.sig

donde doc.sig es el archivo firmado conteniendo la firma que usted desea verificar.

Si usted está verificando una firma separada, tanto el archivo con los datos como el archivo con la firma deben estar presentes al momento de verificar. Por ejemplo, para verificar el último iso de Arch Linux, tendría que hacer: 

$ gpg --verify archlinux-version.iso.sig

donde archlinux-version.iso debe estar en el mismo directorio que archlinux-version.iso.sig.

También puede especificar el archivo con los datos firmados con un segundo argumento: 

$ gpg --verify archlinux-version.iso.sig /path/to/archlinux-version.iso

Si un archivo a sido cifrado además de firmado, simplemente descifre el archivo y su firma también será verificada.

gpg-agent (agente gpg)

This article or section needs expansion.

Reason: Document keyboxd.socket and keyboxd.service.[6] (Discuss in Talk:GnuPG (Español))

gpg-agent es usado principalmente como daemon para pedir y almacenar en caché la contraseña para la cadena de claves. Esto es útil si GnuPG es utilizado desde un programa externo como un cliente de correo. gnupg viene con sockets de systemd user que por defecto están habilitados. Estos sockets son gpg-agent.socket, gpg-agent-extra.socket, gpg-agent-browser.socket, gpg-agent-ssh.socket, y dirmngr.socket.

  • El gpg-agent.socket principal es usado por gpg para conectar al daemon gpg-agent.
  • El uso concebido para el gpg-agent-extra.socket en un sistema local es configurar un socket de dominio Unix enviando desde un sistema remoto. Esto permite usar gpg en el sistema remoto sin exponer las claves privadas al sistema remoto. Vea gpg-agent(1) para más detalles.
  • El gpg-agent-browser.socket permite a los navegadores web acceder al daemon gpg-agent.
  • El gpg-agent-ssh.socket puede ser usado por SSH para almacenar en caché las claves SSH añadidas por el programa ssh-add. Vea agente SSH para la configuración necesaria.
  • El dirmngr.socket inicia un daemon GnuPG que maneja las conexiones a servidores de claves.
Nota Si usted usa una carpeta de usuario GnuPG distinta a la de defecto, tendrá que editar el ListenStream (vea systemd.socket(5) § options) de todos los archivos de socket para ser consistente con gpgconf --list-dirs. Los nombres de los socket usan el hash de la carpeta de usuario GnuPG no-defecto [7], así que lo puede codificar rígidamente sin preocuparse de que hayan cambios.

Configuración

gpg-agent puede ser configurado mediante el archivo ~/.gnupg/gpg-agent.conf. Las opciones de configuración se encuentran listadas en gpg-agent(1). Por ejemplo, puede cambiar el caché tt1 para claves en desuso: 

~/.gnupg/gpg-agent.conf
default-cache-ttl 3600
Tip Para almacenar en caché su contraseña para toda la sesión, por favor realize el siguiente comando: 
$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXX

donde XXXXX es el 'keygrip'. Puede conseguir su valor al hacer gpg --with-keygrip --list-secret-keys. La contraseña será guardada hasta que gpg-agent sea reiniciado. Si usted configura el valor default-cache-tt1, este tomará prioridad.

Es necesario permitir esta preconfiguración de contraseña iniciando gpg-agent con --allow-preset-passphrase o configurando allow-preset-passphrase en ~/.gnupg/gpg-agent.conf.

Recargar el agente

Después de cambiar la configuración, recargue el agente usando gpg-connect-agent: 

$ gpg-connect-agent reloadagent /bye

Este comando debe imprimir OK.

Sin embargo, en algunos casos solo realizar el reinicio puede ser insuficiente, por ejemplo, cuando keep-screen ha sido añadido a la configuración del agente. En este caso, usted primero debe matar el proceso de gpg-agent en curso, y luego puede reiniciarlo como se explicó previamente.

pinentry

gpg-agent puede ser configurado mediante el stanza pinentry-program para usar un interfaz de usuario pinentry en particular al pedir la contraseña al usuario. Por ejemplo: 

~/.gnupg/gpg-agent.conf
pinentry-program /usr/bin/pinentry-curses

Hay otros programas pinentry entre los cuales usted puede escoger - vea pacman -Ql pinentry | grep /usr/bin/. Puede ser necesario instalar las dependencias opcionales relevantes para su programa pintentry elegido.

Tip
Note Al usar KDE, la integración de servicio secreto API es desactivada para prevenir un punto muerto en caso de que labilletera KDE use cifrado GnuPG. Si usted usa la billetera KDE con el archivo clásico, cifrado con blowfish, re-active la integración de servicio secreto API configurando la variable de entorno PINENTRY_KDE_USE_WALLET a un valor no vació. Si usted instaló KDE (Español) de los paquetes meta o un grupo de paquetes, ya debería tener instalado kwallet-pam, en cuyo caso su billetera KDE probablemente ya fue creada usando cifrado 'blowfish' contra la contraseña de su cuenta, por lo cual esta variable de entorno debería ser segura de usar.

Recuerde recargar el agente después de realizar cambios a la configuración.

Almacenar contraseñas en caché

max-cache-ttl y default-cache-ttl definen la cantidad de segundos por los cuales gpg-agent debe almacenar en caché las contraseñas. Para entrar la contraseña una vez por sesión, configúrelos a un número muy alto, por ejemplo: 

gpg-agent.conf
max-cache-ttl 60480000
default-cache-ttl 60480000

Para almacenar contraseñas en caché en modo emulación SSH, configure default-cache-ttl-ssh y max-cache-ttl-ssh en lugar de los anteriores, por ejemplo: 

gpg-agent.conf
default-cache-ttl-ssh 60480000
max-cache-ttl-ssh 60480000

Contraseña desatendida

Comenzando con GNuPG 2.1.0, se requiere el uso de gpg-agent y pinentry, lo cual puede romper la compatibilidad reversa para contraseñas canalizadas desde STDIN usando la opción de línea de comando --passphrase-fd 0. Para tener el mismo tipo de funcionalidad como las versiones antiguas, dos cosas deben hacerse:

Primero, edite la configuración de gpg-agent para permitir el modo pinentry loopback: 

~/.gnupg/gpg-agent.conf
allow-loopback-pinentry

Recargue el agente si está en marcha para permitir que los cambios tengan efecto.

Luego, o la aplicación debe ser actualizada para incluir un parámetro de línea de comando para usar modo loopback del siguiente modo: 

$ gpg --pinentry-mode loopback ...

...o, si esto no es posible, añada la opción a la configuración: 

~/.gnupg/gpg.conf
pinentry-mode loopback
Nota El autor ascendente indica que configurar pinentry-mode loopback en gpg.conf podría romper con otros usos, el uso de la opción de línea de comando siempre debe preferirse cuando sea posibe. [9]

Agente SSH

gpg-agent tiene emulación de agente OpenSSH. Si usted ya usa el suite GnuPG, podría considerar también usar su agente para almacenar en caché sus claves SSH. Adicionalmente, algunos usuarios pueden preferir el diálogo de entrada PIN que el agente GnuPG otorga como parte de su manejo de contraseñas.

Configure SSH_AUTH_SOCK

Fije las siguientes variables para comunicar con gpg-agent en lugar del defecto, ssh-agent: 

SSH_AGENT_PID=""
SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"
Nota
  • Si usted está usando un guión para manejar sus variables, también puede desconfigurar SSH_AGENT_PID en lugar de fijarlo en "", mediante unset SSH_AGENT_PID.
  • Si usted fijó su SSH_AUTH_SOCK manualmente, tenga en cuenta que la ubicación de sus socket puede ser distinta si está usando un GNUPGHOME customizado. Puede usar el siguiente ejemplo de bash, o cambiar SSH_AUTH_SOCK al valor de gpgconf --list-dirs agent-ssh-socket.
  • Si tiene instalado GNOME Keyring, es necesario desactivar su componente ssh. De otra manera, sobrescribirá SSH_AUTH_SOCK.

Alternativamente, dependa de Bash. Esto también funciona para ubicaciones no estándar de socket: 

~/.bashrc
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
  export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi
Nota La prueba involucrando la variable gnupg_SSH_AUTH_SOCK_by es en caso de que el agente está comenzado como gpg-agent --daemon /bin/sh, donde el shell hereda la variable SSH_AUTH_SOCK del apoderado, gpg-agent [10].

Configure pinentry para que use el TTY correcto

Tambiém fije el GPG_TTY y recargue el TTY en caso de que el usuario se haya cambiado a una sesión X como se explica en gpg-agent(1). Por ejemplo: 

~/.bashrc
export GPG_TTY=$(tty)
gpg-connect-agent updatestartuptty /bye >/dev/null

Si usted usa múltiples consolas simultáneamente, y quiere que gpg-agent le pida la contraseña mediante pinentry-curses desde la misma consola en la cual el comando ssh fue ejecutado, añada la siguiente configuración al archivo SSH. Esto recargará el TTY cada vez que se realize un comando ssh [11]: 

~/.ssh/config
Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"

Note que la variable de entorno GPG_TTY debe estar fijada para que esto funcione.

Agregue claves SSH

Una vez gpg-agent esté funcionando, puede usar ssh-add para aprobar claves, siguiendo los mismos pasos como para ssh-agent. La lista de claves aprobadas se guarda en el archivo ~/.gnupg/sshcontrol.

Una vez su clave haya sido aprobada, recibirá un diálogo pinentry cada vez que se necesite su contraseña. Para almacenar la contraseña en caché vea Almacenar contraseñas en caché

Usar una clave PGP para autentificación SSH

También puede usar su clave PGP como una clave SSH. Esto requiere de una clave con la habilidad Authentication (vea capacidades customizadas). Hay varios beneficios obtenidos al usar una clave PGP para autentificación SSH, incluyendo:

  • Menos mantención de claves, debido a que ya no necesitará mantener una clave SSH.
  • La habilidad de guardar la clave de autentificación en un smartcard. GnuPG detectará la clave automáticamente cuando la carta esté disponible, y la agregará al agente (revise con ssh-add -l o ssh-add -L). El comentario para la clave debería verse algo como: openpgp:key-id or cardno:card-id.

Para obtener la porción de la clave GPG/SSH correspondiente a la clave pública, haga gpg --export-ssh-key gpg-key. Si su clave es capaz de autentificarse, pero este comando falla con "Clave pública no usable" ("Unusable public key"), agregue un sufijo ! ([12]).

A no ser de que tenga su clave GPG en un keycard, debe agergar su clave a $GNUPGHOME/sshcontrol para que se le reconozca como una clave SSH. Si su clave está en un keycard, su keygrip se agrega implícitamente a sshcontrol. Si no, obtenga el keygrip de su clave del siguiente modo: 

$ gpg --list-keys --with-keygrip
sub   rsa4096 2018-07-25 [A]
      Keygrip = 1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7

Luego modifique sshcontrol así. Solo se agrega el keygrip una vez, no deberás editar el archivo nuevamente a menos que agregues claves adicionales: 

$GNUPGHOME/sshcontrol
1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7

Reenviando gpg-agent y ssh-agent a dispositivos remotos

Es posible reenviar su gpg-agent a un dispositivo remoto al reenviar sockets gpg a dicho dispositivo, como se explica en el wiki GnuPG.

Primero, agregue la siguiente línea a /etc/ssh/sshd_config en el dispositivo remoto, para habilitar la remoción automática de sockets anticuados al conectar. Si no hace esto, los socket(s) en el dispositivo remoto deberán ser removidos manualmente antes de conectar con el reenvío habilitado para que el reenvío de agentes funcione: 

/etc/ssh/sshd_config
...
StreamLocalBindUnlink yes
...
Nota Deberá recargar sshd.service en el dispositivo remoto para que sshd recargue la nueva configuración.

En el cliente, use el directivo SSH RemoteForward para reenviar tráfico destinado a un puerto remoto, a un puerto en su anfitrión local.Como se describe en ssh_config(5) § RemoteForward, los parámetros de este directivo son la ruta de socket de detección en el remoto, y luego la ruta de socket destinada en el anfitrión local. Su configuración debe verse algo así: 

~/.ssh/config
Host remote_name
    ...
    RemoteForward remote_agent_socket local_agent_extra_socket
    RemoteForward remote_agent_ssh_socket local_agent_ssh_socket

La primera línea configura el reenvío de gpg-agent:

  • remote_agent_socket is the output of gpgconf --list-dir agent-socket on the remote host.
  • local_agent_extra_socket is gpgconf --list-dir agent-extra-socket on the local host.

La segunda línea es opcional. Configura el reenvío de ssh-agent:

  • remote_agent_ssh_socket is gpgconf --list-dir agent-ssh-socket on the remote host.
  • local_agent_ssh_socket is gpgconf --list-dir agent-ssh-socket on the local host.
Nota Si está usando reenvío de ssh-agent, el dispositivo remoto debe tener a SSH_AUTH_SOCK fijado en el output de gpgconf --list-dir agent-ssh-socket como se menciona en agente SSH).

Así, con las rutas defecto, la configuración sería: 

    RemoteForward /run/user/1000/gnupg/S.gpg-agent /run/user/1000/gnupg/S.gpg-agent.extra
    RemoteForward /run/user/1000/gnupg/S.gpg-agent.ssh /run/user/1000/gnupg/S.gpg-agent.ssh

Con esta configuración, al invocar ssh remote_name, gpg-agent debería ser automáticamente reenviado al dispositivo remoto, y se debería permitir el uso de sus claves gpg para descifrado y firmas (y permite el uso de ssh-agent con gpg si la segunda línea RemoteForward ha sido incluida (la línea opcional)).

Smartcards

GnuPG utiliza scdaemon como un interfaz para su lector de smartcard, porfavor véase manpage scdaemon(1) para más detalles.

La herramienta de GnuPG gpg-card puede ser usado para configurar scdaemon y sirve como front-end para configuración de smartcard, vea gpg-card(1) para más detalles.

Advertencia GnuPG 2.4.3 (y 2.4.42, 2.4.2, no empacados por Arch Linux) contenía una regresión de seguridad que pudo haber retenido un respaldo de claves privadas, si lo usó para mover una clave a un smartcard con el comando gpg --edit-card. [13] Vea el consejo GnuPG para más información y remediación con gpg-card checkkeys.

Setups con solo GnuPG

Nota Para darle scdaemon acceso directo a lectores smartcard USB, la dependencia opcional libusb-compat debe estar instalada

Si usted no planea usar cartas además de aquellas basadas en GnuPG, debería revisar el parámetro reader-port en ~/.gnupg/scdaemon.conf. El valor '0' se refiere al primer lector de puertos en serie disponible, y un valor de '32768' (defecto) ser refiere la primer lector USB.

GnuPG con pcscd (PCSC Lite)

pcscd(8) es un daemon que maneja el acceso a smartcard (SCard API). En versiones más antiguas, si el scdaemon de GnuPG no lograba conectar directamente al smartcard (e.g. usando su soporte CCID integrado), se detractaba e intentaba encontrar un smartcard usando el driver PCSC Lite. Sin embargo, desde la versión 2.4, deberá agregar la opción disable-ccid en ~/.gnupg/scdaemon.conf, para poder usar pcscd.

Para usar pcscd instale pcsclite y ccid. Luego start (comienze) y/o enable (habilite) pcscd.service. Alternativamente, comienze o habilite pcscd.socket para activar el daemon cuando sea necesario.

Siempre use pcscd

Si usted está usando cualquier smartcard con un opensc driver (e.g.: cartas de ID de algunos países), debe poner algo de atención a su configuración GnuPG. Fuera de la caja podría recibir un mensaje así al usar gpg --card-status: 

gpg: selecting openpgp failed: ec=6.108

Por defecto, scdaemon intentará conectarse directamente al dispositivo. Esta conección fallará si el lector está siendo usado por otro proceso. Por ejemplo: el daemon pcscd usado por OpenSC. Para lidiar con esta situación deberíamos usar el mismo driver subyacente que opensc para que funcionen juntos de manera adecuada. Para indicar a scdaemon que use pcscd debería eliminar reader-port de ~/.gnupg/scdaemon.conf, especificar la ubicación a libpcsclite.so y deshabilitar ccid para asegurarse de usar pcscd: 

~/.gnupg/scdaemon.conf
pcsc-driver /usr/lib/libpcsclite.so
card-timeout 5
disable-ccid

Por favor véase scdaemon(1) si no utiliza OpenSC.

Acceso compartido con pcscd

GnuPG scdaemon is the only popular pcscd client that uses PCSC_SHARE_EXCLUSIVE flag when connecting to pcscd. Other clients like OpenSC PKCS#11 that are used by browsers and programs listed in Electronic identification are using PCSC_SHARE_SHARED that allows simultaneous access to single smartcard. pcscd will not give exclusive access to smartcard while there are other clients connected. This means that to use GnuPG smartcard features you must before have to close all your open browser windows or do some other inconvenient operations.

Starting from version 2.2.28 LTS and 2.3.0 you can enable shared access by modifying your scdaemon.conf file and adding the line pcsc-shared to the end of it. Keep in mind that scdaemon(1) § --pcsc-shared describes this flag as a "somewhat dangerous option" due to "certain information being cached from the card".

Multi applet smart cards

When using YubiKeys or other multi applet USB dongles with OpenSC PKCS#11 may run into problems where OpenSC switches your Yubikey from OpenPGP to PIV applet, breaking the scdaemon.

You can hack around the problem by forcing OpenSC to also use the OpenPGP applet. Open /etc/opensc.conf file, search for Yubikey and change the driver = "PIV-II"; line to driver = "openpgp";. If there is no such entry, use opensc-tool --atr provided by opensc. Search for the Answer to Reset ATR: 12 34 56 78 90 AB CD .... Then create a new card_atr block referencing your device ATR within the app block. 

/etc/opensc.conf
app default {
    ...
    card_atr 12:23:34:45:67:89:ab:cd:... {
        name = "YubiKey Neo";
        driver = "openpgp"
    }
}
...

After that you can test with pkcs11-tool -O --login that the OpenPGP applet is selected by default. Other PKCS#11 clients like browsers may need to be restarted for that change to be applied.

Using a smart card on a remote client

If for example you log into a machine via SSH or share a smart card to WSL via usbipd-win and try to use an attached device via pcscd, you will notice errors such as: 

gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

This is due to Polkit restricting access to local clients. To fix this, you can add a rule to allow certain users in all cases. The below rule allows all users in the wheel group to access devices via pcscd: 

/etc/polkit-1/rules.d/99-pcscd.rules
polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_card" &&
        subject.isInGroup("wheel")) {
        return polkit.Result.YES;
    }
});
polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_pcsc" &&
        subject.isInGroup("wheel")) {
        return polkit.Result.YES;
    }
});

After creating the file, make sure to restart polkit.service.

OpenPGP compatibility

GnuPG started out as an implementation of the OpenPGP format. Currently, the project is based on RFC 4880 and does not support RFC 9580 (which supersedes RFC 4880).

However, beginning with version 2.4.0 (from December 2022) GnuPG has opted to roll out changes and extensions to the format outside of the IETF process (see draft-koch-librepgp).

Most of the GnuPG-proprietary formats (which diverge from the OpenPGP standard) carry "version 5" or "packet type 20" (these code points are not used in the IETF OpenPGP standard) and introduce incompatibilities:

  • GnuPG's "version 5" keys use different fingerprints from v4 (longer, due to the use of SHA-256), but are also visually indistinguishable from v6 (RFC 9580) fingerprints.
  • GnuPG's "version 5" signatures use a different calculation method with known design flaws.
  • GnuPG's "type 20" symmetrically encrypted data packet format (OCB Encrypted Data Packet) is added, however it also has known design flaws. Support for this format is signalled with a "feature flag" which is aggressively enabled by default. See #Disable unsupported AEAD mechanism.
  • GnuPG's Post-Quantum Cryptography formats again diverge from the upcoming IETF specification (see draft-ietf-openpgp-pqc) in arbitrary details that cause incompatibility.

External reviews have raised concerns about the soundness of the format extensions by GnuPG (see A Summary of Known Security Issues in LibrePGP).

See A Critique on "A Critique on the OpenPGP Updates" for a more in-depth discussion of concerns with regard to the GnuPG-specific format changes and "Comparison of RFC 9580 and LibrePGP" for a detailed technical comparison.

Arch Linux's position is to prefer compatibility with the OpenPGP standard. To this end the patches from the FreePG project (jointly maintained by package maintainers from several Linux distributions) are applied to the gnupg package. This ensures the longterm compatibility with other OpenPGP implementations and avoids vendor lock-in by default.

Disable unsupported AEAD mechanism

With gnupg 2.4, gpg generates keys, which advertise support for a GnuPG specific AEAD encryption mechanism (based on OCB). However, this flavor of AEAD is not supported by other OpenPGP implementations!

Although many downstreams attempt to remove this new default by patching the GnuPG sources, when using --full-gen-key the OCB based custom AEAD encryption mechanism is nonetheless set for the new key.

Whether GnuPG's custom AEAD is set for a key can be inspected with the help of gpg itself: 

$ gpg --list-secret-keys --list-options=show-pref-verbose FINGERPRINT
...
uid           [ultimate] Archie <archie@archlinux.example>
              Cipher: AES256, AES192, AES, 3DES
              AEAD: OCB
              Digest: SHA512, SHA384, SHA256, SHA224, SHA1
              Compression: ZLIB, BZIP2, ZIP, Uncompressed
              Features: MDC, AEAD, Keyserver no-modify
...

This mechanism can be disabled: 

$ gpg --expert --edit-key FINGERPRINT
gpg> setpref AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP
Set preference list to:
    Cipher: AES256, AES192, AES, 3DES
    AEAD:
    Digest: SHA512, SHA384, SHA256, SHA224, SHA1
    Compression: ZLIB, BZIP2, ZIP, Uncompressed
    Features: MDC, Keyserver no-modify
Really update the preferences? (y/N) y

Tips and tricks

Different algorithm

You may want to use stronger algorithms: 

~/.gnupg/gpg.conf
...

personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES

In the latest version of GnuPG, the default algorithms used are SHA256 and AES, both of which are secure enough for most people. However, if you are using a version of GnuPG older than 2.1, or if you want an even higher level of security, then you should follow the above step.

Encrypt a password

It can be useful to encrypt some password, so it will not be written in clear on a configuration file. A good example is your email password.

First create a file with your password. You need to leave one empty line after the password, otherwise gpg will return an error message when evaluating the file.

Then run: 

$ gpg -e -a -r user-id your_password_file

-e is for encrypt, -a for armor (ASCII output), -r for recipient user ID.

You will be left with a new your_password_file.asc file.

Tip pass automates this process.

Change trust model

By default GnuPG uses the Web of Trust as the trust model. You can change this to Trust on first use by adding --trust-model=tofu when adding a key or adding this option to your GnuPG configuration file. More details are in this email to the GnuPG list.

Hide all recipient id's

By default the recipient's key ID is in the encrypted message. This can be removed at encryption time for a recipient by using hidden-recipient user-id. To remove it for all recipients add throw-keyids to your configuration file. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis (i.e. using a little social engineering, anyone who is able to decrypt the message can check whether one of the other recipients is the one they suspect). On the receiving side, it may slow down the decryption process because all available secret keys must be tried (e.g. with --try-secret-key user-id).

Using caff for keysigning parties

To allow users to validate keys on the keyservers and in their keyrings (i.e. make sure they are from whom they claim to be), PGP/GPG uses the Web of Trust. Keysigning parties allow users to get together at a physical location to validate keys. The Zimmermann-Sassaman key-signing protocol is a way of making these very effective. Here you will find a how-to article.

For an easier process of signing keys and sending signatures to the owners after a keysigning party, you can use the tool caff. It can be installed from the AUR with the package caff-gitAUR.

To send the signatures to their owners you need a working MTA. If you do not have already one, install msmtp.

Always show long ID's and fingerprints

To always show long key ID's add keyid-format 0xlong to your configuration file. To always show full fingerprints of keys, add with-fingerprint to your configuration file.

Custom capabilities

For further customization also possible to set custom capabilities to your keys. The following capabilities are available:

  • Certify (only for primary keys) - allows the key to create certifications that the User IDs on other keys are correct.
  • Sign - allows the key to create cryptographic signatures over data, that others can verify with the public key.
  • Encrypt - allows anyone to encrypt data with the public key, that only the private key can decrypt.
  • Authenticate - allows the key to authenticate with various non-GnuPG programs. The key can be used as e.g. an SSH key.

It is possible to specify the capabilities of the primary key, by running: 

$ gpg --full-generate-key --expert
Warning When using --full-generate-key the generated key will advertise an AEAD mechanism, which is not understood by other OpenPGP implementations. To disable this after key creation see #Disable unsupported AEAD mechanism.

And select an option that allows you to set your own capabilities.

Comparably, to specify custom capabilities for subkeys, add the --expert flag to gpg --edit-key, see #Edit your key for more information.

Troubleshooting

su

When using pinentry, you must have the proper permissions of the terminal device (e.g. /dev/tty1) in use. However, with su (or sudo), the ownership stays with the original user, not the new one. This means that pinentry will fail with a Permission denied error, even as root. If this happens when attempting to use ssh, an error like sign_and_send_pubkey: signing failed: agent refused operation will be returned. The fix is to change the permissions of the device at some point before the use of pinentry (i.e. using gpg with an agent). If doing gpg as root, simply change the ownership to root right before using gpg: 

# chown root $(tty)

and then change it back after su (or sudo) terminated.

Note The owner of tty must match with the user for which pinentry is running. Being part of the group tty is not enough.
Tip If you run gpg with script it will use a new tty with the correct ownership: 
# script -q -c "gpg --gen-key" /dev/null

Agent complains end of file

If the pinentry program is /usr/bin/pinentry-gnome3, it needs a DBus session bus to run properly. See General troubleshooting#Session permissions for details.

Alternatively, you can use a variety of different options described in #pinentry.

KGpg configuration permissions

There have been issues with kgpg being able to access the ~/.gnupg/ options. One issue might be a result of a deprecated options file, see the bug report.

GNOME on Wayland overrides SSH agent socket

For Wayland sessions, gnome-session sets SSH_AUTH_SOCK to the standard gnome-keyring socket, $XDG_RUNTIME_DIR/keyring/ssh. This overrides any value set elsewhere.

See GNOME/Keyring#Disabling on how to disable this behavior.

mutt

Mutt might not use gpg-agent correctly, you need to set an environment variable GPG_AGENT_INFO (the content does not matter) when running mutt. Be also sure to enable password caching correctly, see #Cache passwords.

See this forum thread.

"Lost" keys, upgrading to gnupg version 2.1

When gpg --list-keys fails to show keys that used to be there, and applications complain about missing or invalid keys, some keys may not have been migrated to the new format.

Please read GnuPG invalid packet workaround. Basically, it says that there is a bug with keys in the old pubring.gpg and secring.gpg files, which have now been superseded by the new pubring.kbx file and the private-keys-v1.d/ subdirectory and files. Your missing keys can be recovered with the following commands: 

$ cd
$ cp -r .gnupg gnupgOLD
$ gpg --export-ownertrust > otrust.txt
$ gpg --import .gnupg/pubring.gpg
$ gpg --import-ownertrust otrust.txt
$ gpg --list-keys

gpg hanged for all keyservers (when trying to receive keys)

If gpg hanged with a certain keyserver when trying to receive keys, you might need to kill dirmngr in order to get access to other keyservers which are actually working, otherwise it might keeping hanging for all of them.

Smartcard not detected

Your user might not have the permission to access the smartcard which results in a card error to be thrown, even though the card is correctly set up and inserted.

One possible solution is to add a new group scard including the users who need access to the smartcard.

Then use udev rules, similar to the following: 

/etc/udev/rules.d/71-gnupg-ccid.rules
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"

One needs to adapt VENDOR and MODEL according to the lsusb output, the above example is for a YubikeyNEO.

server 'gpg-agent' is older than us (x < y)

This warning appears if gnupg is upgraded and the old gpg-agent is still running. Restart the user's gpg-agent.socket (i.e., use the --user flag when restarting).

IPC connect call failed

Make sure gpg-agent and dirmngr are not running with killall gpg-agent dirmngr and the $GNUPGHOME/crls.d/ folder has permission set to 700.

By default, the gnupg package uses the directory /run/user/$UID/gnupg/ for sockets. GnuPG documentation states this is the preferred directory (not all file systems are supported for sockets). Validate that your agent-socket configuration specifies a path that has an appropriate file system. You can find your path settings for agent-socket by running gpgconf --list-dirs agent-socket.

Test that gpg-agent starts successfully with gpg-agent --daemon.

Mitigating Poisoned PGP Certificates

In June 2019, an unknown attacker spammed several high-profile PGP certificates with tens of thousands (or hundreds of thousands) of signatures (CVE-2019-13050) and uploaded these signatures to keyservers. The existence of these poisoned certificates in a keyring causes gpg to hang with the following message: 

gpg: removing stale lockfile (created by 7055)

Possible mitigation involves removing the poisoned certificate as per this blog post.

Invalid IPC response and Inappropriate ioctl for device

The default pinentry program is /usr/bin/pinentry-gtk-2. If gtk2AUR is unavailable, pinentry falls back to /usr/bin/pinentry-curses and causes signing to fail: 

gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

You need to set the GPG_TTY environment variable for the pinentry programs /usr/bin/pinentry-tty and /usr/bin/pinentry-curses. 

$ export GPG_TTY=$(tty)

Keyblock resource does not exist

If you get an error like this when trying to import keys 

gpg: keyblock resource 'gnupg_home/pubring.kbx': No such file or directory

it is because GnuPG will not create its home directory if it does not yet exist. Simply create it manually 

$ mkdir -m 700 gnupg_home

Subkey is created with Restricted capability

In some cases creating a subkey with a custom set of capabilities results in the subkey marked as "Restricted". This happens in the addkey command with option 7 or 8 ("set your own capabilities") when the capabilities are toggled in the interactive prompt. A workaround is to enter the desired capability set directly as a string instead of toggling individual capabilities, when prompted with the capability selection. For example, enter "=A" to create a subkey with only the Authentication capability.

See also