PGP Encryption: How It Actually Works

Concebido por Phil Zimmermann en 1991 como una herramienta de autodefensa digital y estandarizado posteriormente por el IETF bajo las especificaciones OpenPGP (RFC 4880 y el reciente RFC 9580), Pretty Good Privacy (PGP) continúa siendo el pilar fundamental para la confidencialidad, autenticidad e integridad de las comunicaciones asíncronas entre periodistas de investigación, defensores de derechos humanos y analistas de seguridad en entornos hostiles.

La arquitectura del cifrado híbrido: Simetría y asimetría combinadas

El núcleo operativo de PGP no descansa exclusivamente sobre un único algoritmo criptográfico, sino sobre un criptosistema híbrido. El cifrado puramente asimétrico (como RSA o el intercambio de claves sobre curvas elípticas como X25519) es computacionalmente costoso y estructuralmente ineficiente para procesar flujos masivos de datos o archivos adjuntos voluminosos. Por el contrario, los algoritmos simétricos destacan por su extrema velocidad y robustez matemática, pero introducen el dilema clásico de la distribución segura de la clave.

PGP resuelve esta tensión técnica dividiendo el problema operativo en dos fases complementarias:

• Cifrado de la carga útil: Para cada mensaje o archivo, la implementación de PGP (como GnuPG) genera aleatoriamente una clave simétrica temporal y descartable, denominada session key (clave de sesión). El cuerpo del mensaje se cifra utilizando esta clave mediante un algoritmo simétrico de alto rendimiento, típicamente AES-256 o ChaCha20-Poly1305 en las especificaciones más modernas.
• Encapsulamiento de la clave: La clave de sesión se cifra a su vez utilizando la clave pública del destinatario (por ejemplo, RSA de 4096 bits o X25519). Si el mensaje está destinado a múltiples receptores, la clave de sesión se cifra de forma independiente con la clave pública de cada uno de ellos, generándose múltiples paquetes de clave sin duplicar el cuerpo del mensaje cifrado.

Anatomía del flujo de cifrado y descifrado paso a paso

Cuando un usuario ejecuta una instrucción de cifrado mediante una herramienta compatible con OpenPGP, el motor criptográfico ejecuta una secuencia algorítmica determinista dividida en capas de empaquetado de datos.

El proceso de cifrado y empaquetado

1. Compresión previa: El mensaje original en texto claro se comprime habitualmente mediante algoritmos como ZIP, ZLIB o BZip2. Esto no solo reduce la cantidad de bytes que viajarán por la red, sino que debilita el criptoanálisis estadístico al reducir la entropía de los patrones lingüísticos y eliminar redundancias del texto en claro.
2. Generación de clave efímera: El generador de números pseudoaleatorios del sistema criptográfico (CSPRNG) genera la clave de sesión simétrica.
3. Cifrado simétrico: Se procesa la carga comprimida dentro de un paquete estructurado. Históricamente se utilizó el modo Cipher Feedback (CFB) con resincronización de OpenPGP, complementado por mecanismos de verificación de integridad.
4. Creación de paquetes PKESK: Se crea un paquete denominado PKESK (Public-Key Encrypted Session Key) que contiene la clave de sesión cifrada con la clave pública del destinatario y, opcionalmente, el identificador de dicha clave (Key ID).
5. Radix-64 (Armadura ASCII): De forma opcional, el flujo binario resultante puede codificarse en Base64 con una suma de comprobación CRC-24 (lo que genera los bloques reconocibles -----BEGIN PGP MESSAGE-----) para permitir su transmisión por canales pensados exclusivamente para texto, como clientes de correo electrónico tradicionales.

El proceso inverso de descifrado

En el extremo receptor, el proceso invierte cada una de las fases anteriores mediante un estricto control de acceso criptográfico:

Mensaje Cifrado -> Lectura de PKESK -> Desbloqueo de Clave Privada (S2K)
                 -> Extracción de Session Key -> Descifrado Simétrico 
                 -> Validación de Integridad (MDC/AEAD) -> Descompresión -> Texto Claro

Para desbloquear la clave privada requerida para descifrar el paquete PKESK, el software invoca una función de derivación de claves (KDF) denominada String-to-Key (S2K). El estándar moderno ha migrado de las versiones iteradas y con sal (Salted & Iterated S2K) basadas en hashes SHA-2 a funciones con resistencia activa al paralelismo en hardware como Argon2id (incorporado formalmente en RFC 9580), protegiendo la frase de paso del usuario contra ataques de fuerza bruta en matrices de GPU o circuitos ASIC.

Autenticación e Integridad: Firmas Digitales y Paquetes MDC

El cifrado garantiza estrictamente la confidencialidad, pero carece de utilidad operativa si el receptor no puede determinar con certeza matemática si el mensaje fue alterado durante el tránsito o generado por un impostor.

Firmas digitales con Ed25519 y RSA

Cuando un mensaje es firmado criptográficamente, PGP calcula un hash criptográfico unidireccional (generalmente de la familia SHA-2 o SHA-3) sobre el contenido. Posteriormente, este resumen criptográfico se cifra utilizando la clave privada del remitente. Al recibirlo, el destinatario descifra el hash utilizando la clave pública del remitente y lo compara con un nuevo hash calculado directamente sobre el mensaje recibido. Si ambos valores son idénticos, se cumplen dos garantías formales:

• Autenticidad de origen: Solo quien poseía la clave privada correspondiente pudo generar esa firma válida.
• No repudio: El firmante no puede negar técnicamente haber procesado ese contenido exacto mientras su clave privada permanezca bajo su control exclusivo.

Protección contra manipulación: Del MDC a los modos AEAD

En los esquemas OpenPGP tradicionales (RFC 4880), los ataques de oráculo y modificación de texto cifrado obligaron a implementar el paquete SEIPD (Symmetrically Encrypted and Integrity Protected Data), el cual incluía un Modification Detection Code (MDC) basado en SHA-1 al final de la carga cifrada. Si un adversario manipulaba un solo bit del mensaje cifrado en tránsito, la comprobación del MDC fallaba y el software advertía al usuario del compromiso.

En el estándar actualizado RFC 9580 (OpenPGP versión 6), este esquema evoluciona hacia el uso nativo de cifrado autenticado con datos asociados (AEAD), empleando modos como EAX u OCB junto a cifrados simétricos modernos. Esto mitiga por completo las debilidades asociadas a construcciones anteriores frente a ataques activos de inyección de texto cifrado (como la vulnerabilidad EFAIL de 2018).

Jerarquías de Claves: Claves Primarias y Subclaves Operativas

Un error conceptual común es asumir que una "clave PGP" es una entidad criptográfica única. En la práctica defensiva contemporánea, un certificado OpenPGP está constituido por una jerarquía estructurada de claves maestras y subclaves especializadas, identificadas mediante flags de capacidad:

• Clave Primaria (Capacidad [C] - Certify): Es la raíz de la identidad. Su única función debe ser firmar y revocar subclaves, así como emitir firmas de confianza sobre identidades de terceros. Nunca debe utilizarse para cifrar mensajes ni firmar correos cotidianos.
• Subclave de Firma (Capacidad [S] - Sign): Empleada exclusivamente para emitir firmas digitales sobre documentos y correos.
• Subclave de Cifrado (Capacidad [E] - Encrypt): Contiene el par asimétrico que recibe las claves de sesión encapsuladas en los mensajes dirigidos al usuario.
• Subclave de Autenticación (Capacidad [A] - Authenticate): Utilizada comúnmente para autenticación en servidores mediante protocolos SSH o sesiones TLS.

La mejor práctica de seguridad operacional consiste en generar la clave primaria en un entorno completamente aislado del exterior (air-gapped), exportar las subclaves de uso diario a un token criptográfico de hardware (como una YubiKey o Nitrokey mediante scdaemon) y almacenar la clave primaria en un soporte cifrado sin conexión. Si un endpoint resulta comprometido, el adversario únicamente captura subclaves que pueden ser revocadas de inmediato sin destruir la identidad digital primaria del usuario.

El Dilema de la Confianza: De la Web of Trust a la Verificación Directa

Para cifrar un mensaje hacia otra persona, es indispensable obtener su clave pública. Sin embargo, surge la interrogante criptográfica fundamental: ¿cómo comprobar que la clave pública que afirma pertenecer a una fuente pertenece realmente a ella y no a un intermediario malicioso (ataque Man-in-the-Middle)?

La Red de Confianza (Web of Trust - WoT)

A diferencia del modelo centralizado de las Autoridades de Certificación (CA) de X.509/TLS, PGP fue concebido con un modelo de confianza descentralizado denominado Web of Trust. En este sistema, los usuarios firman criptográficamente las claves públicas de otros tras verificar presencialmente sus identidades y la huella digital (fingerprint). Si el Usuario A confía en el Usuario B, y el Usuario B ha firmado la clave del Usuario C, el cliente PGP del Usuario A puede validar matemáticamente la autenticidad de la clave del Usuario C sin necesidad de una autoridad centralizada.

El colapso de los servidores de claves tradicionales y la realidad actual

La red histórica de servidores SKS (Synchronizing Key Servers) sufrió ataques severos de envenenamiento de certificados (keyserver poisoning), en los cuales actores maliciosos inundaban claves públicas con cientos de miles de firmas falsas que colapsaban las implementaciones locales de GnuPG al intentar procesarlas. Hoy en día, el paradigma defensivo ha cambiado:

• Servidores verificadores (VKS): Plataformas modernas como keys.openpgp.org validan el control de la dirección de correo electrónico mediante enlaces de confirmación y eliminan firmas no verificadas por defecto.
• Protocolo WKD (Web Key Directory): Permite obtener claves públicas directamente desde el servidor web del dominio del destinatario mediante HTTPS seguro (por ejemplo, consultando https://dominio.com/.well-known/openpgpkey/...), reduciendo drásticamente la superficie de suplantación.
• Verificación fuera de banda: La verificación manual del fingerprint criptográfico completo (un resumen SHA-256 o SHA-1 de la clave pública) a través de un canal seguro secundario (llamada de voz verificada, mensajería cifrada punto a punto como Signal o en persona) sigue siendo el único método totalmente fiable.

Límites Defensivos y Metadatos: Qué Protege y Qué No Protege PGP

Para investigadores y periodistas de seguridad, comprender los límites estructurales de PGP es tan vital como entender su criptografía. PGP protege con solvencia matemática el contenido de los mensajes, pero deja desprotegidos los metadatos de la capa de transporte.

En el contexto del correo electrónico (mediante PGP/MIME o Inline PGP):

• Las líneas de asunto (Subject), los remitentes, los destinatarios y las marcas temporales viajan en texto claro en los encabezados RFC 5322 del protocolo SMTP.
• Los observadores de la red pueden realizar análisis de tráfico correlacionando el tamaño de los paquetes cifrados, la frecuencia de comunicación y los identificadores de clave pública transmitidos en los paquetes PKESK (a menos que se active la directiva --throw-keyids en GnuPG, la cual oculta el ID del receptor a expensas de requerir que el software pruebe todas las claves secretas locales para intentar descifrar el mensaje).

El estándar OpenPGP no es un sistema de anonimato, sino un protocolo criptográfico de confidencialidad y autenticación. Su integración defensiva eficaz requiere combinarlo con redes de transporte anónimas (como Tor) o protocolos orientados a la minimización de metadatos cuando la ocultación de la relación comunicativa sea un requisito operativo crítico.