GnuPG (Español) - ArchWiki

Jump to content

# GnuPG (Español)

From ArchWiki

Related articles

- pacman/Package signing
- Data-at-rest encryption
- List of applications/Security#Encryption, signing, steganography
- OpenPGP

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:

- Establece la Variable de Entorno `$GNUPGHOME`.
- Usa el argumento `--homedir`, e.g. `$ gpg --homedir path/to/dir` [1].

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)

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 [6], 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

- Los programas pinentry `/usr/bin/pinentry-gnome3` (GNOME), `/usr/bin/pinentry-qt`, `/usr/bin/pinentry-qt5` y `/usr/bin/pinentry-gtk` (genérico) [7] apoyan el API de servicio secreto DBus, que permite recordar contraseñas mediante un manejador obediente como Anillo de claves GNOME, KeePassXC o Billetera KDE.
- Una alternativa a la Billetera KDE es `/usr/bin/pinentry-kwallet`, que requiere la isntalación del paquete kwalletcliAUR.

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. [8]

### 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 [9].

#### 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 [10]:

    ~/.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 `!` ([11]).

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 de 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 es la salida de `gpgconf --list-dir agent-socket` en el anfitrión remoto.
- local_agent_extra_socket es la salida de `gpgconf --list-dir agent-extra-socket` en el anfitrión local.

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

- remote_agent_ssh_socket es `gpgconf --list-dir agent-ssh-socket` en el anfitrión remoto.
- local_agent_ssh_socket es `gpgconf --list-dir agent-ssh-socket` en el anfitrión local.

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`. [12] 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` es el único cliente `pcscd` popular que usa la bandera `PCSC_SHARE_EXCLUSIVE` al conectarse a `pcscd`. Otros clientes como OpenSC PKCS#11, que son usados por buscadores y programas listados en Identificación Electrónica, usan `PCSC_SHARE_SHARED`, que permite acceso simultáneo a smartcard individual. `pcscd` no otorgará acceso exclusivo a smartcard mientras otros clientes estén conectados. Esto significa que para usar herramientas smartcard de GnuPG debe cerrar previamente todas sus ventanas de buscador abiertas, o realizar otras operaciones inconvenientes.

Comenzando con la versión LTS 2.2.28 y 2.3.0, usted puede habilitar el acceso compartido al modificar su archivo `scdaemon.conf`, agregando la línea `pcsc-shared` al final de aquel. Tenga en cuenta que scdaemon(1) § --pcsc-shared describe esta bandera como "una opción un cuánto peligrosa", debido a que "cierta información se almacena en caché desde la carta".

##### Smartcards de varios applet

Al usar YubiKeys u otros adaptadores USB de varios applet con OpenSC, PKCS#11 podría encontrarse con problemas, en donde OpenSC cambia su Yubikey de OpenPGP a applet PIV, rompiendo el `scdaemon`.

Usted puede resolver el problema obligando a OpenSC a usar también el applet OpenPGP. Abra el archivo `/etc/opensc.conf`, busque Yubikey y cambie la línea `driver = "PIV-II";` a `driver = "openpgp";`. Si no existe dicha línea, use `opensc-tool --atr`, otorgado por opensc. Busque "Answer to Reset" `ATR: 12 34 56 78 90 AB CD ...`. Luego cree un nuevo bloque `card_atr`, que referencie el ATR de su dispositivo dentro del bloque de aplicación (`app`)

    /etc/opensc.conf

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

Posteriormente, puede probar con `pkcs11-tool -O --login`, para verificar que el applet OpenPGP esté seleccionado por defecto. Otros clientes PKCS#11 como buscadores podrían necesitar ser reiniciados para que ese cambio se aplique.

#### Usando un smartcard en un cliente remoto

Si, por ejemplo, usted inicia sesión en una máquina via SSH o comparte un smartcard a WSL via usbipd-win e intenta usar un dispositivo conectado via pcscd, verá errores tales como:

    gpg: selecting card failed: No such device
    (gpg: fallo en la selección de carta: No existe el dispositivo)
    gpg: OpenPGP card not available: No such device
    (gpg: carta OpenPGP no disponible: No existe el dispositivo)

Esto se debe a que Polkit restringe el acceso a clientes locales. Para arreglar esto, puede añadir una regla que permite a ciertos usuarios en todos los casos. La siguiente regla permite a todos los usuarios en el grupo `wheel` acceder a dispositivos 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;
        }
    });

Después de crear el archivo, asegúrese de reiniciar `polkit.service`.

## Compatibilidad con OpenPGP

GnuPG comenzó como una implementación del formato OpenPGP. Actualmente, el proyecto se basa en RFC 4880, y no soporta a RFC 9580 (que sustituye a RFC 4880, el cual ya está obsoleto).

Sin embargo, comenzando con la versión 2.4.0 (desde Diciembre de 2022), GnuPG ha decidido realizar cambios y extensiones al formato fuera del proceso IETF (vea draft-koch-librepgp).

La mayoría ed los formatos propietarios a GnuPG (que divergen del estándar OpenPGP), contienen "version 5" o "packet type 20" (estos puntos de código no son usados en el estándar IETF OpenPGP) e introducen incompatibilidades:

- Las claves "version 5" de GnuPG usan huellas digitales distintas a v4 (más largas, debido al uso de SHA-256), pero también son visualmente indistinguibles de huellas digitales v6 (RFC 9580).
- Las firmas "version 5" de GnuPG usan un método de cálculo distinto con errores de diseño conocidos.
- El formato de paquetes de datos cifrados simétricamente "type 20" de GnuPG (OCB Paquete de Datos Cifrados) está incluido, sin embargo este también tiene errores de diseño conocidos. Apoyo para este formato se señala con una bandera "feature flag", que está incluida agresivamente por defecto. Vea Deshabilitar el mecanismo AEAD no apoyado.
- Los formatos de Criptografía Post-Cuántica de GnuPG nuevamente divergen de la próxima especificación IETF (vea draft-ietf-openpgp-pqc), en detalles arbitrarios que causan incompatibilidad.

Revisiones externas han generado preocupaciones sobre la seguridad de las extensiones de formato hechas por GnuPG (vea Un Resumen de Problemas de Seguridad Conocidos en LibrePGP).

Vea Una Crítica de "Una Crítica sobre las Actualizaciones de OpenPGP" para una discusión más profunda sobre preocupaciones en relación a los cambios en formato específicos a GnuPG, y "Comparación de RFC 9580 y LibrePGP" para una comparación técnica detallada.

La posición de Arch Linux es priorizar la compatibilidad con el estándar OpenPGP. Con este fin, los arreglos del FreePG project (mantenido en conjunto por mantenedores de paquete de varias distribuciones de Linux) son aplicados al paquete gnupg. Esto asegura la compatibilidad a largo plazo con otras implementaciones de OpenPGP y evita el bloqueo de proveedor por defecto.

### Deshabilitar el mecanismo AEAD no apoyado

Con gnupg 2.4, `gpg` genera claves que declaran apoyo para un mecanismo de cifrado AEAD específico a GnuPG (en base a OCB). Sin embargo, este tipo de AEAD no es compatible con otras implementaciones de OpenPGP!

Aunque muchos downstreams intentan remover esta configuración nueva parcheando las fuentes de GnuPG, al usar `--full-gen-key` el mecanismo de encripicón customizado de AEAD basado en OCB está configurado para la nueva clave de todos modos.

Con la ayuda el mismo `gpg` se puede determinar si el AEAD customizado de GnuPG está configurado para una clave:

    $ 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
    ...

Este mecanismo puede ser deshabilitado:

    $ 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

## Consejos y trucos

### Algoritmo distinto

Usted podría desear usar algoritmos más fuertes:

    ~/.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

En la versión más reciente de GnuPG, los algoritmos usados por defecto son SHA256 y AES, ambos son suficientemente seguros para la mayoría de los usuarios. Sin embargo, si usted usa una versión de GnuPG más antigua que 2.1, o si quiere un nivel más alto de seguridad, entonces debería cambiar la configuración detallada anteriormente.

### Cifrar una contraseña

Puede ser útil cifrar alguna contraseña, con tal de que no esté escrita claramente en un archivo de configuración. Un buen ejemplo es su contraseña de correo.

Primero, cree un archivo con su contraseña. Usted debe dejar una línea vacía después de la contraseña, sino gpg entregará un mensaje de error al evaluar el archivo.

Luego haga:

    $ gpg -e -a -r id-usuario archivo_de_contraseña

`-e` es para cifrar (encrypt en inglés), `-a` para armadura (ouput ASCII), `-r` para el ID del usuario receptor (recipient user ID en inglés)

Ahora tendrá un archivo nuevo con el nombre `archivo_de_contraseña.asc`

Tip pass automatiza este proceso.

### Cambiar modelo de confianza

Por defecto, GnuPG usa la Red de Confianza como el modelo de confianza. Usted puede cambiarlo a Confiar tras primer uso, agregando `--trust-model=tofu` al añadir una clave, o añadiendo esta opción a su archivo de configuración de GnuPG. Puede ver más detalles en este correo enviado a la lista GnuPG.

### Esconder todos los id de receptor

Por defecto, el ID de clave del receptor se encuentra en el mensaje cifrado. Este puede ser omitido al momento de cifrar para un receptor usando `hidden-recipient user-id`. Para omitirlo para todos los receptores, agregue `throw-keyids` a su archivo de configuración. Esto ayuda a esconder los recipientes del mensaje, y es una contramedida limitada para el análisis de tráfico (es decir, usando algo de ingeniería social, cualquier persona capaz de descifrar el mensaje puede revisar si uno de los otros receptores es a quien sospechan). Por el lado del receptor, esto puede ralentizar el proceso de descifrado, ya que todas las claves secretas disponibles deben ser probadas (por ejemplo, con `--try-secret-key user-id`).

### Using caff for keysigning parties

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

Notas: De acá en adelante (Discusión en Talk:GnuPG (Español)#)

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.

### Siempre mostrar huellas digitales e ID's largos

Para siempre mostrar ID's de clave largos agregue `keyid-format 0xlong` a su archivo de configuración. Para siempre mostrar las huellas digitales completas de las claves, agregue `with-fingerprint` a su archivo de configuración.

### 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

- GNU Privacy Guard Homepage
- Alan Eliasen's GPG Tutorial
- RFC 4880 — "OpenPGP Message Format"
- gpg.conf recommendations and best practices
- Fedora:Creating GPG Keys
- Debian:Subkeys
- Protecting code integrity with PGP
- A more comprehensive gpg Tutorial
- /r/GPGpractice - a subreddit to practice using GnuPG.
- A Summary of Known Security Issues in LibrePGP on blog.pgpkeys.eu

Categories:

- Encryption (Español)
- OpenPGP (Español)
- Email (Español)
- GNU (Español)

Hidden categories:

- Pages with broken package links
- Pages or sections flagged with Template:Translateme (Español)

GnuPG (Español)
Add topic