Referencia

Glosario

302 términos de firmas digitales, certificados, tokens, protocolos y criptografía poscuántica, cada uno definido en pocas frases y vinculado a los estándares que lo especifican.

Visibles: 302 de 302

De la A a la Z

A

AAGUID (GUID de atestación del autenticador): El identificador de 16 bytes de los datos de credencial atestada de WebAuthn que nombra el modelo del autenticador —por ejemplo, una llave de seguridad concreta o un gestor de contraseñas— y sirve para buscar sus metadatos e iconos.
ACME (gestión automática de certificados): El protocolo del RFC 8555, creado para Let's Encrypt, en el que un cliente demuestra el control de sus identificadores mediante desafíos y obtiene certificados de una CA sin intervención humana.
AEAD (cifrado autenticado con datos asociados): Un modo de cifrado simétrico que ofrece confidencialidad e integridad en una sola operación y además autentica datos asociados sin cifrar, como los encabezados; el RFC 5116 lo define de forma genérica.
AES-GCM: AES en modo Galois/Counter (NIST SP 800-38D), el AEAD más extendido: cifrado en modo contador más un autenticador GHASH, normalmente con un nonce de 96 bits y una etiqueta de 128 bits.
age (cifrado de archivos): Una herramienta y un formato pequeños y modernos para el cifrado de archivos (age-encryption.org/v1), de Filippo Valsorda, que cifran para destinatarios X25519, SSH o híbridos poscuánticos o con una frase de contraseña, sin firmas y sin configuración.
Agilidad criptográfica (crypto-agility): La capacidad de un sistema para cambiar de algoritmos criptográficos, tamaños de clave y parámetros sin rediseñarlo —mediante la negociación, la configuración y el inventario—, algo que la transición poscuántica convierte de buena práctica en necesidad.
alg (encabezado JOSE del algoritmo): El parámetro del encabezado JOSE que indica el algoritmo de firma o de MAC de un JWS (por ejemplo, ES256) o el algoritmo de gestión de claves de un JWE (por ejemplo, RSA-OAEP-256), registrado por el RFC 7518 y RFC posteriores.
alg none (JWS sin protección): El valor de algoritmo none de JWS (RFC 7518 §3.6), que denota un token sin firmar con la parte de la firma vacía y que un verificador nunca debe aceptar salvo que espere explícitamente contenido sin protección.
Algoritmo de Grover: El algoritmo cuántico de búsqueda de Lov Grover (1996), que encuentra un elemento marcado entre N en unos √N pasos y, por tanto, como mucho reduce a la mitad la seguridad efectiva en bits de las claves simétricas y de las preimágenes de hash.
Algoritmo de Shor: El algoritmo cuántico de Peter Shor (1994) que factoriza enteros y calcula logaritmos discretos en tiempo polinómico, y que en una computadora cuántica grande y tolerante a fallos rompería RSA, Diffie–Hellman, ECDSA, EdDSA y ECDH.
Alineación de identificadores DMARC: El requisito de DMARC de que el dominio autenticado por SPF (el remitente del sobre) o por DKIM (el dominio d=) coincida con el dominio del encabezado From, ya sea de forma exacta (alineación estricta) o dentro del mismo dominio organizativo (alineación relajada).
Almacén raíz (almacén de confianza): El conjunto de certificados de CA raíz en los que un sistema operativo, un navegador o un entorno de ejecución confía como anclas para la validación de la ruta de certificación, seleccionado por un programa raíz con su propia política.
ALPN (negociación de protocolo de aplicación): La extensión de TLS del RFC 7301 con la que el cliente ofrece protocolos de aplicación como h2 y http/1.1 y el servidor elige uno dentro del handshake, sin un viaje de ida y vuelta adicional.
ARC (cadena recibida autenticada): El protocolo experimental del RFC 8617 (2019) en el que cada intermediario que maneja un mensaje registra los resultados de autenticación que vio y los sella, para que el receptor final pueda fiarse de unos resultados que el reenvío o las listas de correo rompieron después.
Armadura ASCII: La codificación de texto de OpenPGP que representa paquetes binarios en base64 entre líneas como -----BEGIN PGP PUBLIC KEY BLOCK----- y -----END PGP PUBLIC KEY BLOCK----- (RFC 9580 §6.2).
ASN.1 (notación sintáctica abstracta uno): El lenguaje ITU-T X.680 para describir estructuras de datos con independencia de su codificación, que se usa para definir certificados X.509, CMS, claves PKCS #8, OCSP, LDAP y protocolos de telecomunicaciones.
Ataque de canal lateral: Un ataque que obtiene secretos a partir del comportamiento físico o temporal de un cálculo —su tiempo de ejecución, sus accesos a la caché, su consumo de energía, sus emisiones electromagnéticas o su reacción a fallos inducidos— y no a partir de sus entradas y salidas.
Ataque de curva no válida: Un ataque en el que un interlocutor envía un punto que no está en la curva acordada, de modo que una implementación que omite la validación del punto calcula sobre una curva más débil y filtra su clave privada poco a poco.
Ataque de extensión de longitud: Un ataque contra hashes de Merkle–Damgård como MD5, SHA-1, SHA-256 y SHA-512 que calcula H(secreto ‖ m ‖ relleno ‖ m′) a partir de H(secreto ‖ m) y de la longitud de secreto ‖ m, sin conocer el secreto.
Atestación (WebAuthn): Una declaración, firmada con la clave de atestación del autenticador durante el registro, que indica a la relying party qué tipo de autenticador creó una credencial, para que pueda aplicar políticas de dispositivos.
aud (claim de audiencia): El claim registrado de JWT (RFC 7519 §4.1.3) que indica los destinatarios a los que va dirigido un token, como cadena o como array de cadenas, y en el que cada destinatario debe comprobar que figura su propio identificador.
Autenticador (FIDO/WebAuthn): El componente que guarda las credenciales de WebAuthn y genera las firmas: un autenticador de plataforma integrado en un dispositivo, una llave de seguridad itinerante o un gestor de credenciales que sincroniza llaves de acceso.
Authenticode: El formato de firma de código de Microsoft para ejecutables, controladores, instaladores y scripts de Windows: un SignedData de PKCS #7 sobre un hash del archivo, incrustado en la tabla de certificados del PE y normalmente con sello de tiempo.

Á

Árbol de Merkle: Un árbol de hashes binario en el que cada nodo interno calcula el hash de sus dos hijos, de modo que un solo hash raíz fija el contenido de todas las hojas y la pertenencia o el crecimiento de solo anexión pueden demostrarse con pruebas de tamaño logarítmico.

B

Base64url: El alfabeto base64 seguro para URL y nombres de archivo del RFC 4648 §5, que sustituye + y / por - y _ y, en JOSE, prescinde del relleno =; todas las partes de un JWT se codifican en base64url.
Baseline Requirements (requisitos básicos, BR): Las normas del CA/Browser Forum para emitir y gestionar certificados de servidor TLS de confianza pública, que abarcan los métodos de validación, los perfiles de certificado, la vida útil, la revocación y el funcionamiento de las CA.
Billetera de hardware: Un dispositivo dedicado que guarda las claves de la billetera en un elemento seguro o un microcontrolador aislado, muestra los detalles de la transacción en su propia pantalla y solo firma tras una confirmación física.
BIMI (indicadores de marca en el correo): Un esquema de registro DNS y certificado, todavía en fase de Internet-Draft del IETF, que permite a un dominio con una política DMARC restrictiva mostrar su logo junto a los mensajes en los buzones de correo compatibles, como Gmail, Yahoo y Apple Mail.
BIP-32 (billeteras deterministas jerárquicas): El estándar de Bitcoin para derivar un árbol de claves a partir de una sola semilla con HMAC-SHA512 y códigos de cadena, de modo que una única copia de seguridad cubre todas las direcciones y las claves públicas extendidas pueden derivar direcciones de recepción sin claves privadas.
BIP-39 (frases semilla mnemotécnicas): El estándar que codifica la entropía de una billetera como una secuencia de 12 a 24 palabras de una lista de 2048 y convierte la frase, con PBKDF2-HMAC-SHA512 (2048 iteraciones), en la semilla de 64 bytes que usa BIP-32.
BIP-137 (formato de mensajes firmados): El formato de firma de mensajes de Bitcoin que usa una firma ECDSA recuperable de 65 bytes cuyo byte de encabezado codifica tanto el ID de recuperación como el tipo de dirección: 27–30 P2PKH sin comprimir, 31–34 P2PKH comprimido, 35–38 P2SH-P2WPKH, 39–42 P2WPKH.
BIP-322 (firma genérica de mensajes): El estándar de Bitcoin para firmar mensajes que demuestra el control de cualquier tipo de dirección, incluidas SegWit, Taproot y multisig, firmando una transacción virtual que gasta desde la dirección.
BIP-340 (firmas Schnorr para secp256k1): La especificación de Bitcoin de firmas Schnorr de 64 bytes en secp256k1 con claves públicas x-only de 32 bytes y hashes etiquetados, usada por Taproot y Nostr.
BLAKE2: Una familia de funciones hash rápidas (BLAKE2b para plataformas de 64 bits, con resúmenes de hasta 64 bytes, y BLAKE2s para las de 32 bits, con hasta 32 bytes), especificada en el RFC 7693 y usada en Argon2, WireGuard, PASETO y libsodium.

C

C2PA (credenciales de contenido): El estándar de la Coalición para la Procedencia y Autenticidad del Contenido (C2PA) que define manifiestos de procedencia firmados, incrustados en imágenes, video, audio y documentos, que registran quién creó o editó el contenido y con qué herramientas, incluida la generación por IA.
CA (autoridad de certificación): Una organización o servicio que emite y firma certificados tras comprobar que el solicitante controla los nombres o la identidad que el certificado acreditará.
CA intermedia: Un certificado de CA, firmado por una raíz u otra intermedia, cuya clave emite certificados de entidad final; así la clave raíz puede quedar sin conexión.
CA raíz (certificado raíz): Un certificado de CA autofirmado y de confianza directa por estar en el almacén raíz del verificador: el ancla en la que debe acabar toda ruta de certificación.
CA/Browser Forum: El organismo voluntario de autoridades de certificación y fabricantes de navegadores y sistemas operativos que redacta los Baseline Requirements y otras normas para los certificados TLS, S/MIME y de firma de código de confianza pública.
CAA (autorización de autoridad certificadora): Un tipo de registro DNS (RFC 8659) con el que el propietario de un dominio enumera las CA autorizadas para emitir certificados para sus nombres, y que toda CA pública debe consultar antes de emitir.
Cadena de certificados: La secuencia ordenada de certificados que va desde un certificado hoja (de entidad final), a través de uno o varios certificados de CA intermedia, hasta una raíz de confianza, cada uno firmado por el siguiente.
Canonicalización: Transformación de los datos en una única representación de bytes acordada antes de calcular el hash o firmar, para que entradas semánticamente iguales (con distintos espacios en blanco, orden de claves, prefijos de espacios de nombres o plegado de encabezados) produzcan la misma entrada de firma.
Canonicalización DKIM: Los dos algoritmos, simple y relaxed (RFC 6376 §3.4), que normalizan los encabezados y el cuerpo de un mensaje antes de calcular el hash DKIM, y que se eligen por separado para los encabezados y el cuerpo con la etiqueta c=.
Categoría de seguridad poscuántica del NIST: Uno de los cinco niveles de robustez que el NIST define para los conjuntos de parámetros poscuánticos por comparación con romper AES o SHA-2/SHA-3: categoría 1 ≈ búsqueda de clave de AES-128, 3 ≈ AES-192, 5 ≈ AES-256, y la 2 y la 4 ligadas a colisiones de SHA-256 y SHA3-384.
CBOM (lista de materiales criptográficos): Un inventario legible por máquina de los activos criptográficos de un sistema —algoritmos, claves, certificados, protocolos y bibliotecas con sus parámetros— que se usa para planificar y seguir migraciones como el paso a la criptografía poscuántica.
Certificado (certificado de clave pública): Una declaración firmada por un emisor de que una clave pública determinada pertenece a un sujeto con nombre, válida durante un tiempo limitado y para unos fines concretos, casi siempre en formato X.509.
Certificado autofirmado: Un certificado cuyo emisor y sujeto coinciden y cuya firma se hizo con su propia clave privada, por lo que solo es de confianza allí donde se ha instalado como ancla de confianza.
Certificado comodín (wildcard): Un certificado con un nombre alternativo del sujeto como *.example.com, que coincide con una sola etiqueta cualquiera en esa posición, por ejemplo www.example.com, pero no con example.com ni con a.b.example.com.
Certificado de corta duración: Un certificado con una validez tan breve —como máximo 7 días para los certificados TLS públicos emitidos desde el 15 de marzo de 2026— que simplemente caduca en lugar de depender de las comprobaciones de revocación.
Certificado SSH: Una declaración firmada propia de OpenSSH (no X.509) en la que la clave de una autoridad de certificación vincula una clave pública de usuario o de host a unos principals, una ventana de validez y unas opciones, lo que elimina la necesidad de distribuir claves individuales.
Certificados de árbol de Merkle (MTC): Un diseño de certificados en proceso de estandarización en el IETF en el que una CA registra cada emisión en un árbol de Merkle y los clientes comprueban una prueba de inclusión breve en lugar de grandes firmas poscuánticas.
Certificate Transparency (CT): El sistema de registros públicos de solo anexión basados en árboles de Merkle (RFC 6962) al que las CA envían cada certificado TLS de confianza pública, para que los propietarios de dominios y los monitores puedan detectar certificados emitidos indebidamente.
ChaCha20-Poly1305: El AEAD que combina el cifrado de flujo ChaCha20 con el autenticador Poly1305 (RFC 8439): claves de 256 bits, nonces de 96 bits y etiquetas de 128 bits, rápido en software sin hardware de AES.
Clave de host SSH: El par de claves de larga duración con el que un servidor SSH firma cada intercambio de claves, y así demuestra su identidad ante los clientes que tienen registrada la clave pública en known_hosts o confían en una CA que la certificó.
Clave débil: Una clave más fácil de romper de lo que sugiere su tamaño, por un generador defectuoso, poca entropía, un defecto estructural o la reutilización entre equipos.
Clave OpenPGP v6: El formato de clave introducido por el RFC 9580, con huellas digitales SHA-256 de 32 bytes, algoritmos Ed25519/X25519/Ed448/X448 nativos y firmas v6 con sal, que sustituye a las claves v4 del RFC 4880, basadas en SHA-1.
Clave privada: La mitad secreta de un par de claves asimétrico, que se usa para firmar, descifrar o acordar claves; quien la posee puede actuar como su propietario, por lo que nunca debe salir sin protección de su límite de confianza.
Clave pública: La mitad de un par de claves asimétrico que puede compartirse libremente y que sirve para verificar firmas, cifrar datos para el titular de la clave privada correspondiente o acordar claves con él.
ClientHello: El primer mensaje del handshake TLS, enviado en claro, en el que el cliente enumera las versiones, los conjuntos de cifrado, los grupos, los algoritmos de firma y los key shares que admite, además de extensiones como la del nombre del servidor.
CMS (sintaxis de mensajes criptográficos): El sucesor de PKCS #7 en el IETF (RFC 5652) para datos firmados, ensobrados (enveloped) y autenticados, que usan S/MIME, Authenticode, las firmas PDF, los sellos de tiempo RFC 3161 y muchos formatos de firmware.
CNSA 2.0: La Commercial National Security Algorithm Suite 2.0 (conjunto de algoritmos comerciales de seguridad nacional) de la NSA (septiembre de 2022), que exige ML-KEM-1024, ML-DSA-87, LMS o XMSS, AES-256 y SHA-384 o SHA-512 en los sistemas de seguridad nacional de EE. UU. entre 2030 y 2035.
Cofactor: El cociente h = #E / n entre el número de puntos de una curva elíptica y el orden primo n del subgrupo que se usa en criptografía: 1 para las curvas P de NIST y secp256k1, 8 para Curve25519 y 4 para Curve448.
Compartición de secretos de Shamir: El esquema de Adi Shamir (1979) que divide un secreto en n fragmentos con un polinomio aleatorio: k cualesquiera lo reconstruyen y k − 1 no revelan nada.
Compresión de certificados TLS: La extensión de TLS 1.3 del RFC 8879 (compress_certificate, 27) que permite al servidor comprimir su cadena de certificados con zlib, brotli o zstd, lo que normalmente la reduce en un tercio o más.
Compresión de puntos: Codificar un punto de curva elíptica con su coordenada x más un bit de y en lugar de las dos coordenadas, lo que reduce aproximadamente a la mitad el tamaño de la clave pública a costa de una raíz cuadrada al decodificar.
Confusión de algoritmos (confusión de claves): Un fallo de verificación en el que una biblioteca deja que el encabezado alg del token elija el algoritmo, de modo que una clave destinada a un algoritmo se usa con otro; el caso clásico es una clave pública RSA usada como secreto HS256.
Conjunto de cifrado (cipher suite): Una combinación con nombre de algoritmos criptográficos que usa una conexión TLS; en TLS 1.3 solo nombra el AEAD y el hash del handshake (por ejemplo, TLS_AES_128_GCM_SHA256), mientras que los nombres de TLS 1.2 también fijaban el intercambio de claves y la autenticación.
Contraseña: Una cadena secreta que el usuario memoriza y un servidor comprueba; es el autenticador más común y el más expuesto al phishing, y NIST SP 800-63B-4 la regula con reglas de longitud, listas de bloqueo y almacenamiento, no de complejidad.
COSE (firma y cifrado de objetos CBOR): El equivalente CBOR de JOSE (RFC 9052 y RFC 9053) para firmas, MAC, cifrado y claves, usado por WebAuthn, los permisos de conducir mdoc, los CWT y C2PA.
Cosechar ahora, descifrar después: La estrategia de grabar hoy tráfico cifrado para descifrarlo cuando una computadora cuántica pueda romper su intercambio de claves; es la razón por la que el intercambio de claves poscuántico se despliega antes de que existan las computadoras cuánticas.
cosign: La herramienta de línea de comandos de Sigstore para firmar y verificar imágenes de contenedor, blobs y atestaciones, ya sea con claves o, en modo sin claves (keyless), con identidades OIDC y certificados de corta duración.
Credencial detectable (clave residente): Una credencial de WebAuthn cuyo autenticador guarda la clave privada y el identificador de usuario (user handle), de modo que puede encontrarse sin que el servidor envíe antes un ID de credencial; esto permite iniciar sesión con una llave de acceso sin nombre de usuario.
Credencial verificable: Un conjunto de claims sobre un sujeto, firmado por un emisor de forma que cualquier manipulación es detectable y guardado por el sujeto en una billetera, que un verificador puede comprobar sin consultar al emisor; está estandarizado en varios formatos (W3C VC, SD-JWT VC, mdoc).
Criptografía basada en retículos: Criptografía construida sobre problemas difíciles en retículos de alta dimensión, como el aprendizaje con errores (Learning With Errors) y el problema de la solución entera corta (Short Integer Solution), base de ML-KEM, ML-DSA y FN-DSA.
Criptografía poscuántica (PQC): Algoritmos de clave pública diseñados para seguir siendo seguros frente a computadoras cuánticas grandes, como ML-KEM, ML-DSA y SLH-DSA (FIPS 203–205, 2024), que sustituyen a RSA, Diffie–Hellman y los esquemas de curva elíptica.
CRL (lista de revocación de certificados): Una lista de números de serie de certificados revocados, firmada y publicada periódicamente por una CA (RFC 5280 §5), que los verificadores descargan para comprobar la revocación sin consultar a la CA por cada certificado.
CRLite: El mecanismo de revocación de Firefox que comprime el estado de revocación de todos los certificados registrados en Certificate Transparency en filtros compactos que se descargan en el navegador y se consultan en local.
CSPRNG (generador aleatorio criptográficamente seguro): Un generador de números aleatorios cuya salida no se puede predecir ni distinguir de la aleatoriedad real, ni siquiera por un atacante que haya visto salidas anteriores; es imprescindible para claves, nonces, sales y tokens.
CSR (solicitud de firma de certificado): Un mensaje PKCS #10 (RFC 2986) que contiene un nombre de sujeto, una clave pública y los atributos solicitados, firmado con la clave privada correspondiente para demostrar su posesión, y que una CA convierte en un certificado.
CTAP (protocolo de cliente a autenticador): El protocolo de la FIDO Alliance entre un cliente (navegador o sistema operativo) y un autenticador externo a través de USB HID, NFC, Bluetooth o el transporte híbrido con el teléfono, con comandos codificados en CBOR como authenticatorMakeCredential.
Curva elíptica: El conjunto de puntos que satisfacen una ecuación cúbica como y² = x³ + ax + b sobre un cuerpo finito, con una ley de suma de puntos que forma el grupo que usan ECDSA, EdDSA y ECDH.
Curvas Brainpool: Una familia de curvas elípticas con parámetros pseudoaleatorios verificables (RFC 5639, 2010), preferida por los perfiles gubernamentales de Alemania y de otros países europeos como alternativa a las curvas NIST.
Curve25519: La curva de Montgomery y² = x³ + 486662x² + x sobre el primo 2²⁵⁵ − 19, propuesta por Daniel J. Bernstein en 2005, base del intercambio de claves X25519 y, en forma de Edwards, de las firmas Ed25519.
CWT (CBOR Web Token): El equivalente CBOR del JWT (RFC 8392): un conjunto de claims codificado como mapa CBOR con enteros como claves y protegido con firma, MAC o cifrado COSE.

D

DANE (autenticación de entidades con nombre basada en DNS): El uso de registros TLSA firmados con DNSSEC (RFC 6698, RFC 7671) para declarar qué certificado o clave pública debe presentar un servicio TLS, ya sea junto a las CA públicas o en su lugar.
Datos del autenticador: La estructura binaria que lleva toda respuesta de WebAuthn: el SHA-256 de 32 bytes del RP ID, un byte de indicadores, un contador de firmas de 4 bytes y, de forma opcional, los datos de credencial atestada y las salidas de extensiones en CBOR.
DER (reglas de codificación distinguidas): La codificación binaria canónica de ASN.1, definida en ITU-T X.690, que da a cada valor exactamente una representación en bytes; por eso los certificados, las CSR, las CRL, las claves y muchas firmas se codifican en DER.
Desafío dns-01 de ACME: El método de validación de dominio de ACME en el que el cliente publica en _acme-challenge.domain un registro TXT con base64url(SHA-256(autorización de clave)), el único método de ACME que puede validar nombres comodín.
Desafío http-01 de ACME: El método de validación de dominio de ACME en el que el cliente sirve la autorización de clave en http://domain/.well-known/acme-challenge/token por el puerto 80 y la CA la descarga desde varios puntos de observación de la red.
DID (identificador descentralizado): Un URI de la forma did:method:identifier (W3C DID Core 1.0, 2022) que se resuelve en un documento DID con claves públicas y endpoints de servicio, controlado por su sujeto y no por un registro central.
Dirección de Bitcoin: Una codificación legible por humanos de un script de salida de Bitcoin: P2PKH (1…) y P2SH (3…) heredados en Base58Check, SegWit v0 (bc1q…) en bech32 y Taproot (bc1p…) en bech32m.
Dirección de Ethereum: Un identificador de cuenta de 20 bytes: en las cuentas de propiedad externa, los últimos 20 bytes del hash Keccak-256 de la clave pública sin comprimir de 64 bytes (secp256k1), sin su prefijo 0x04, escrito como 0x seguido de 40 dígitos hexadecimales.
DKIM (DomainKeys Identified Mail): El estándar de autenticación del correo electrónico del RFC 6376 en el que el dominio remitente firma algunos encabezados y el cuerpo de un mensaje y publica la clave pública en el DNS, para que los receptores puedan verificar que el mensaje procede de ese dominio y no se alteró.
DKIM replay (repetición de mensajes firmados): El reenvío, sin cambios, de un mensaje con una firma DKIM legítima a muchos destinatarios nuevos para que llegue con la reputación del dominio firmante, algo que DKIM no puede impedir porque la firma no cubre el sobre SMTP.
DMARC: Autenticación, informes y conformidad de mensajes basados en dominios (RFC 9989, mayo de 2026): una política DNS que exige que SPF o DKIM pasen con alineación respecto al dominio From visible e indica a los receptores qué hacer con el correo que no lo logra.
DNSSEC: Las extensiones de seguridad del DNS (RFC 4033–4035), que firman los conjuntos de registros DNS para que los resolvedores que validan puedan comprobar que las respuestas llegan sin modificar desde el propietario de la zona, en una cadena que parte de la clave de la zona raíz.
DoH (DNS sobre HTTPS): El protocolo del RFC 8484 que transporta consultas y respuestas DNS en solicitudes HTTPS (tipo de medio application/dns-message), lo que las oculta a los observadores en la ruta y permite a las aplicaciones web resolver nombres directamente.
DPoP (demostración de prueba de posesión): El mecanismo de OAuth del RFC 9449 que vincula los tokens de acceso y los tokens de actualización a una clave que guarda el cliente: cada solicitud lleva un JWT de prueba DPoP nuevo y firmado, así que un token robado no sirve por sí solo.
DSA (algoritmo de firma digital): El algoritmo de firma de FIPS 186 (1994) basado en el logaritmo discreto en campos finitos, que FIPS 186-5 retiró en 2023 para firmas nuevas y que solo se mantiene para verificar las existentes.

E

ECDH (Diffie–Hellman de curva elíptica): El acuerdo de claves en el que cada parte combina su propia clave privada de curva elíptica con la clave pública de la otra para calcular el mismo secreto compartido, la coordenada x de d_A·d_B·G.
ECDH-ES (acuerdo de claves en JWE): La familia de gestión de claves de JWE del RFC 7518 §4.6 en la que el remitente genera una clave EC efímera, acuerda un secreto con la clave estática del destinatario y deriva la clave de contenido con Concat KDF.
ECDHE (Diffie–Hellman efímero de curva elíptica): Diffie–Hellman de curva elíptica con pares de claves nuevos en cada handshake, el intercambio de claves que da forward secrecy a TLS; en TLS 1.3 funciona sobre x25519, secp256r1 y grupos similares.
ECDLP (logaritmo discreto en curvas elípticas): El problema de hallar el escalar d a partir de los puntos G y Q = d·G de una curva elíptica, cuya dificultad es la hipótesis de seguridad en la que se basan ECDSA, EdDSA, ECDH y las firmas Schnorr.
ECDSA (algoritmo de firma digital de curva elíptica): La variante de DSA sobre curvas elípticas, especificada en FIPS 186-5 y SEC 1, cuya firma es un par de enteros (r, s) calculado con un escalar privado y un nonce secreto nuevo.
ECH (Encrypted Client Hello): La extensión de TLS 1.3 del RFC 9849 que cifra el ClientHello real, incluido el nombre del servidor, con una clave publicada en el DNS, de modo que la red solo ve un nombre público compartido.
ECPrivateKey de SEC 1: La estructura de clave privada de curva elíptica de SEC 1 y el RFC 5915, que OpenSSL escribe como -----BEGIN EC PRIVATE KEY----- y que guarda el escalar junto con los parámetros de la curva y el punto público, ambos opcionales.
ecrecover: El contrato precompilado de Ethereum en la dirección 0x01 (y la función ecrecover de Solidity) que recupera la dirección del firmante a partir de un hash de 32 bytes y una firma ECDSA (v, r, s) sobre secp256k1.
Ed448: EdDSA sobre la curva Edwards448 «Goldilocks» con SHAKE256 (RFC 8032 §5.2): unos 224 bits de seguridad, con claves públicas de 57 bytes y firmas de 114 bytes.
Ed25519: EdDSA sobre Curve25519 en forma de Edwards con SHA-512 (RFC 8032 §5.1): clave pública de 32 bytes, firma determinista de 64 bytes y unos 128 bits de seguridad.
EdDSA (algoritmo de firma de curva de Edwards): Un esquema de firma de tipo Schnorr sobre curvas de Edwards torcidas, definido en el RFC 8032 y aprobado en FIPS 186-5, cuyas dos instancias estándar son Ed25519 y Ed448.
eIDAS: El reglamento de la UE relativo a la identificación electrónica y los servicios de confianza (n.º 910/2014, modificado por el 2024/1183), según el cual las firmas electrónicas cualificadas tienen el mismo efecto jurídico que las manuscritas.
EIP-155 (protección contra repetición): El cambio de Ethereum de 2016 (Spurious Dragon, bloque 2.675.000) que incluye el ID de cadena en el hash de firma de la transacción y en el valor v (v = chainId × 2 + 35 o 36), de modo que una transacción de una cadena no es válida en otras.
EIP-191 (estándar de datos firmados): La convención de Ethereum según la cual los mensajes firmados empiezan con el byte 0x19 y un byte de versión, de modo que nunca pueden ser transacciones válidas; la versión 0x45 es el formato personal_sign que usan la mayoría de las billeteras.
EIP-712 (firma de datos estructurados tipados): El estándar de Ethereum para calcular el hash de datos estructurados tipados y firmarlos con un separador de dominio, de modo que las billeteras puedan mostrar los campos a los usuarios y las firmas no puedan repetirse entre contratos ni cadenas.
EIP-7702 (asignar código a las EOA): La actualización de Ethereum, activa desde el hard fork Pectra del 7 de mayo de 2025, que permite a una cuenta de propiedad externa delegar su código en un contrato mediante una autorización firmada en una transacción de tipo 0x04.
Encabezado DKIM-Signature: El campo de encabezado (RFC 6376 §3.5) que lleva una firma DKIM en pares etiqueta=valor: v, a, c, d, s, h, bh, b y las etiquetas opcionales i, l, t y x.
Envoltura de firmas XML (XSW): Una clase de ataques contra mensajes con firma XML en los que un atacante mueve el elemento firmado e inserta uno falsificado, de modo que la firma sigue siendo válida para el original mientras la aplicación procesa la falsificación.
ERC-1271 (validación de firmas por contratos): El estándar de Ethereum con el que las cuentas de contrato inteligente validan firmas: un verificador llama a isValidSignature(bytes32 hash, bytes signature) y considera válido el valor de retorno 0x1626ba7e.
ES256: El algoritmo JWS de ECDSA en la curva P-256 con SHA-256 (RFC 7518 §3.4), cuya firma son exactamente 64 bytes de r‖s en bruto, no DER; en COSE, el algoritmo −7.
Esquemas de firma APK (v1–v4): Los formatos de firma de aplicaciones de Android: v1, firma JAR; v2 (Android 7.0) y v3 (Android 9, rotación de claves), firmas del archivo completo en el bloque de firma de APK (APK Signing Block); v3.1 (Android 13), rotación dirigida, y v4 (Android 11), para instalaciones incrementales.
EUDI Wallet (cartera de identidad digital): La cartera de identidad que cada Estado miembro de la UE debe ofrecer a sus ciudadanos según el Reglamento (UE) 2024/1183 (eIDAS 2), con los datos de identificación de la persona y las declaraciones de atributos en los formatos SD-JWT VC y mdoc.
exp (claim de fecha de caducidad): El claim registrado de JWT (RFC 7519 §4.1.4) que indica el momento, en segundos desde la época Unix, a partir del cual no debe aceptarse el token.
Extensión de uso de clave (key usage): La extensión de X.509 (OID 2.5.29.15) cuyos bits restringen lo que puede hacer una clave certificada: digitalSignature, contentCommitment, keyEncipherment, keyAgreement, keyCertSign, cRLSign y otros.
Extensión key_share: La extensión de TLS 1.3 (51) que transporta los valores públicos efímeros del cliente para uno o más grupos y el único valor con el que responde el servidor, lo que permite completar el intercambio de claves en el primer viaje de ida y vuelta.
Extensión signature_algorithms: La extensión de TLS (13) en la que un cliente o un servidor enumera los esquemas de firma que acepta, como ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256 y ed25519, mientras que signature_algorithms_cert (50) cubre por separado las firmas de los certificados.

F

Falcon (FN-DSA): Un esquema de firma compacto basado en retículos NTRU, seleccionado por el NIST en 2022 y en proceso de estandarización como FN-DSA en FIPS 206, que en octubre de 2026 seguía siendo un borrador.
FIDO2: El nombre general que da la FIDO Alliance a la autenticación sin contraseña con clave pública, que se compone de la API WebAuthn del W3C y el protocolo de cliente a autenticador de FIDO (CTAP 2.x).
Fijación de certificados o claves públicas: Restringir a un conjunto fijo los certificados o claves públicas que un cliente acepta para un host, más allá de la validación de la cadena habitual, comparando hashes de una clave de CA, de un certificado intermedio o de la propia clave del servidor.
FIPS 140-3: La norma de Estados Unidos y Canadá para módulos criptográficos (2019, alineada con ISO/IEC 19790), conforme a la cual el CMVP valida módulos de hardware y software en los niveles de seguridad 1 a 4.
Firma a ciegas (blind signing): Aprobar una transacción o un mensaje cuyo significado no puede mostrar el dispositivo de firma, que suele enseñar solo un hash o el calldata en bruto, de modo que el firmante tiene que confiar en el equipo que lo preparó, que puede estar comprometido.
Firma con pre-hash (HashEdDSA, HashML-DSA): Firmar un resumen del mensaje en lugar del propio mensaje, ya sea de forma implícita (ECDSA, RSA) o mediante variantes explícitas y distintas, con separación de dominios, como Ed25519ph y HashML-DSA.
Firma de código: La firma de ejecutables, paquetes, scripts o firmware para que los sistemas operativos, las tiendas y los usuarios puedan verificar al editor y detectar manipulaciones, con certificados X.509, claves de plataforma, OpenPGP o Sigstore.
Firma de commits de Git: La firma de commits y etiquetas de Git con claves OpenPGP, SSH (desde Git 2.34) o X.509 para que las plataformas de alojamiento y los revisores puedan verificar quién los creó; se configura con gpg.format y user.signingkey.
Firma digital: Un valor calculado a partir de un mensaje con una clave privada, que cualquiera que tenga la clave pública correspondiente puede comprobar, y que demuestra que el mensaje no ha cambiado y que lo firmó el titular de la clave.
Firma PDF: Una firma digital incrustada en un archivo PDF (ISO 32000-2) cuyo /ByteRange cubre todo excepto el valor de la firma; normalmente es una firma CMS o CAdES separada, con la cadena de certificados y un sello de tiempo.
Firma Schnorr: Un esquema de firma basado en el logaritmo discreto (Claus Schnorr, 1989) cuya respuesta s = r + e·x es lineal en la clave, lo que permite demostraciones de seguridad sencillas, verificación por lotes y multifirmas nativas.
Firma separada: Una firma que se guarda aparte de los datos que firma —como un archivo .sig o .asc de OpenPGP, un archivo SSHSIG o una firma CMS sin contenido encapsulado—, de modo que el archivo original queda intacto.
Firma sin claves (keyless signing): El modelo de firma de Sigstore en el que el firmante se autentica con una identidad OIDC, obtiene un certificado válido durante minutos para una clave efímera y se apoya en un registro de transparencia en lugar de proteger una clave privada de larga duración.
Firma XML (XML-DSig): El estándar del W3C para firmar XML (XML Signature Syntax and Processing 1.1, 2013), en el que un elemento ds:Signature hace referencia a los datos firmados mediante un URI, los canonicaliza y firma un bloque SignedInfo de resúmenes.
Firmas basadas en hash: Esquemas de firma cuya seguridad depende solo de propiedades de una función hash, construidos a partir de firmas de un solo uso y árboles de Merkle: LMS y XMSS, con estado (SP 800-208), y SLH-DSA, sin estado (FIPS 205).
Firmas BLS: Firmas basadas en emparejamientos (Boneh, Lynn y Shacham, 2001), cortas, deterministas y agregables de forma nativa, cuyo uso más destacado es el consenso de prueba de participación de Ethereum sobre la curva BLS12-381.
Firmas compuestas: Firmas que combinan un algoritmo poscuántico y uno clásico bajo una sola clave y un solo identificador de algoritmo —por ejemplo, ML-DSA-65 con ECDSA P-256—, de modo que una firma solo es válida si se verifican los dos componentes.
Firmas de mensajes HTTP: El estándar del IETF (RFC 9421, febrero de 2024) para firmar componentes seleccionados de una solicitud o respuesta HTTP, con la firma transmitida en los campos de encabezado Signature-Input y Signature.
Firmas de umbral: Esquemas en los que una clave privada se reparte entre n partes de modo que t cualesquiera de ellas pueden producir conjuntamente una única firma de aspecto ordinario, mientras que cualquier grupo más pequeño no obtiene ninguna información sobre la clave.
Firmas hedged (reforzadas con aleatoriedad): Firma en la que el nonce de cada firma se deriva de la clave privada y el mensaje junto con aleatoriedad nueva, de modo que el esquema sigue siendo seguro si se ataca uno de los dos: el generador de números aleatorios o la derivación determinista.
Formato de clave PKCS #1: Las estructuras ASN.1 RSAPublicKey y RSAPrivateKey del apéndice A del RFC 8017, exclusivas de RSA, guardadas en PEM como -----BEGIN RSA PUBLIC KEY----- y -----BEGIN RSA PRIVATE KEY-----.
Formato de clave privada de OpenSSH: El contenedor openssh-key-v1 que ssh-keygen escribe por defecto desde OpenSSH 7.8 (2018), guardado como -----BEGIN OPENSSH PRIVATE KEY----- y cifrado con una KDF basada en bcrypt cuando se establece una frase de contraseña.
Formato de firma r‖s en bruto (IEEE P1363): La codificación de longitud fija de una firma ECDSA o DSA como r y s concatenados, cada uno rellenado por la izquierda hasta la longitud en bytes del orden del grupo, que usan JOSE, COSE, WebCrypto y muchas API de HSM.
Forward secrecy (secreto hacia adelante): La propiedad por la que el compromiso de las claves de larga duración, como la clave del certificado de un servidor, no expone las sesiones pasadas; se consigue derivando las claves de cada sesión de un intercambio de claves efímero cuyos valores se descartan después.
Función hash criptográfica: Una función que transforma una entrada de cualquier longitud en un resumen de longitud fija de modo que encontrar una preimagen, una segunda preimagen o cualquier colisión sea computacionalmente inviable.

G

Grapado OCSP (OCSP stapling): Una función de TLS en la que el servidor obtiene una respuesta OCSP reciente para su propio certificado y la envía en el handshake, lo que ahorra a los clientes una consulta a la CA que perjudica su privacidad.

H

Handshake TLS: El intercambio inicial de una conexión TLS, en el que el cliente y el servidor acuerdan los parámetros, realizan un intercambio de claves, se autentican (normalmente solo el servidor, mediante su certificado) y derivan las claves de tráfico.
Hash de contraseñas: Guardar una contraseña como la salida de una función deliberadamente lenta, con sal y, preferiblemente, de memoria intensiva (memory-hard), como Argon2id, scrypt, bcrypt o PBKDF2, para que una base de datos robada resista los intentos de adivinación sin conexión.
HKDF: La función de derivación de claves de extracción y expansión basada en HMAC del RFC 5869, que convierte un secreto compartido, como la salida de ECDH, en una o varias claves uniformemente aleatorias vinculadas a una cadena de contexto.
HMAC: El código de autenticación de mensajes basado en hash con clave del RFC 2104 y FIPS 198-1, calculado como H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)), que demuestra la integridad y el origen ante cualquiera que comparta la clave secreta.
HQC (Hamming cuasicíclico): Un mecanismo de encapsulación de claves basado en códigos que el NIST seleccionó el 11 de marzo de 2025 como respaldo de ML-KEM, previsto como FIPS 207; su borrador de norma aún no se había publicado en octubre de 2026.
HS256: El algoritmo JWS HMAC con SHA-256 (RFC 7518 §3.2), en el que el emisor y el verificador comparten una clave secreta de al menos 256 bits, así que cualquiera que pueda verificar un token también puede emitir uno.
HSM (módulo de seguridad de hardware): Un dispositivo o servicio en la nube resistente a manipulaciones que genera y almacena claves y realiza operaciones criptográficas dentro de su perímetro, de modo que las claves privadas no se pueden exportar en texto en claro.
HSTS (seguridad estricta de transporte HTTP): El encabezado de respuesta HTTP del RFC 6797 que indica a los navegadores que usen solo HTTPS con un host durante un tiempo determinado, que impidan continuar ante un error de certificado y que cambien automáticamente cualquier enlace http:// a HTTPS.
Huella digital de clave o certificado: Un hash corto de una clave pública o de un certificado con el que se identifican y comparan a simple vista o en la configuración, como SHA256:… en las claves SSH o el SHA-256 de los bytes DER de un certificado.
Huella digital de JWK (JWK thumbprint): Un hash de los miembros obligatorios de una JWK en una forma canónica de JSON (RFC 7638), normalmente SHA-256 codificado en base64url, que sirve como identificador de clave estable para valores kid, vinculaciones DPoP y ACME.

I

in-toto: Un marco graduado en la CNCF para declaraciones firmadas de la cadena de suministro, cuyo formato de atestación (un Statement que vincula los resúmenes de los artefactos con un predicado tipado) transporta atestaciones de procedencia SLSA y de SBOM.
Indicadores SIGHASH: El byte que se añade a una firma de Bitcoin para seleccionar qué partes de la transacción cubre: ALL (0x01), NONE (0x02), SINGLE (0x03), que pueden combinarse con ANYONECANPAY (0x80), además del valor predeterminado de Taproot, 0x00.
Información de renovación de ACME (ARI): La extensión de ACME del RFC 9773 (junio de 2025) con la que una CA indica a los clientes la ventana en la que debería renovarse cada certificado, de modo que la CA pueda repartir la carga y pedir una renovación anticipada antes de revocaciones masivas.
Intercambio de claves (key establishment): Paso de un protocolo con el que dos partes obtienen un secreto compartido a través de un canal inseguro, mediante acuerdo de claves Diffie–Hellman o encapsulación de claves, y del que se derivan las claves de sesión.
Intercambio de claves híbrido: Un intercambio de claves que combina un algoritmo clásico como X25519 con un KEM poscuántico como ML-KEM, de modo que la sesión sigue siendo secreta mientras cualquiera de los dos componentes siga sin romperse.
iss (claim de emisor): El claim registrado de JWT (RFC 7519 §4.1.1) que identifica quién emitió un token y que el verificador debe comparar de forma exacta con el emisor cuyas claves usó para verificar la firma.

J

JA4 (huella digital de cliente TLS): El método de FoxIO de 2023 para obtener la huella digital de clientes TLS a partir de su ClientHello —protocolo, versión, SNI, recuentos y hashes ordenados de los conjuntos de cifrado y las extensiones—, diseñado para mantenerse estable cuando los navegadores aleatorizan el orden de las extensiones.
JOSE (firma y cifrado de objetos JSON): La familia de formatos del IETF basados en JSON para firmar, cifrar y representar claves —JWS, JWE, JWK, JWA y JWT (RFC 7515–7519)— y el grupo de trabajo que los mantiene.
JWA (JSON Web Algorithms): El RFC 7518, que define los identificadores y parámetros de algoritmo que usan JWS, JWE y JWK, como HS256, RS256, ES256, PS256, RSA-OAEP, ECDH-ES y A256GCM.
JWE (JSON Web Encryption): El formato JOSE del RFC 7516 para contenido cifrado, cuya forma compacta tiene cinco partes —encabezado, clave cifrada, IV, texto cifrado y etiqueta— y que separa la gestión de claves (alg) del cifrado del contenido (enc).
JWK (JSON Web Key): La representación JSON de una clave criptográfica (RFC 7517), con miembros como kty, crv, x, y, n, e para las claves públicas y d para la parte privada.
JWKS (conjunto de claves JSON Web Key): Objeto JSON con JWK públicas en su array keys, a menudo en el jwks_uri del emisor, para que las relying parties verifiquen tokens y sigan la rotación de claves.
JWS (JSON Web Signature): El formato JOSE del RFC 7515 para contenido firmado o protegido con un MAC mediante parámetros descritos en JSON, serializado de forma compacta como header.payload.signature o como JSON con varias firmas.
JWT (JSON Web Token): Un token compacto y apto para URL (RFC 7519) que transporta un objeto JSON de claims, firmado como JWS o cifrado como JWE, y que se usa para tokens de ID, tokens de acceso y muchas sesiones de API.

K

Keccak-256: El hash Keccak original, con salida de 256 bits y el relleno anterior a la estandarización, que Ethereum usa para direcciones, selectores de función y hashes de firma; no es la misma función que SHA3-256 de FIPS 202.
KEM (mecanismo de encapsulación de claves): Una primitiva de clave pública en la que Encaps convierte una clave pública en un secreto compartido aleatorio más un texto cifrado y Decaps recupera el secreto con la clave privada; sustituye a Diffie–Hellman en el intercambio de claves poscuántico.
Key binding (vinculación al titular): Prueba de que quien presenta una credencial controla una clave privada indicada en ella, para que otra persona no pueda volver a presentar una copia de la credencial; la implementan el JWT de key binding de SD-JWT y la autenticación del dispositivo de mdoc.
kid (ID de clave): Parámetro de encabezado JOSE y miembro de JWK que indica qué clave firmó o cifró un token, para que el verificador elija la correcta del JWKS en una rotación.
Kyber (CRYSTALS-Kyber): La propuesta de la ronda 3 del NIST de la que deriva ML-KEM; se desplegó pronto en TLS híbrido (X25519Kyber768Draft00) y no interopera con ML-KEM estándar.

L

LibrePGP: Una especificación de OpenPGP mantenida por el autor de GnuPG (draft-koch-librepgp) que continúa la línea de RFC 4880bis con claves v5 y su propio cifrado compuesto con Kyber, incompatible con las claves v6 del RFC 9580.
Límite de 10 consultas DNS de SPF: La regla del RFC 7208 según la cual la evaluación de un registro SPF puede desencadenar como máximo 10 mecanismos y modificadores que consultan el DNS (include, a, mx, ptr, exists, redirect); si se supera, el resultado es permerror.
Llave de acceso (passkey): Una credencial detectable de FIDO2/WebAuthn —un par de claves vinculado a un sitio web o una aplicación y desbloqueado con la biometría, el PIN o la contraseña del dispositivo— que sustituye la contraseña por una firma resistente al phishing.
LMS y HSS (firmas de Leighton–Micali): El esquema de firma basada en hash con estado del RFC 8554 y de NIST SP 800-208, en el que un árbol de Merkle de claves de un solo uso de Winternitz firma un número fijo de mensajes y HSS apila árboles para firmar más.

M

Maleabilidad de la firma: La propiedad de un esquema de firma o de su codificación que permite a cualquiera convertir una firma válida en otra firma válida distinta para el mismo mensaje y la misma clave sin conocer la clave privada.
MD5: La función hash de 128 bits de Ron Rivest, de 1991 (RFC 1321), rota frente a colisiones desde 2004 y frente a colisiones de prefijo elegido desde 2007, e insegura para cualquier uso de seguridad en el que un atacante pueda influir en la entrada.
mDL (permiso de conducir móvil): Un permiso de conducir o documento de identidad estatal guardado en el teléfono como mdoc ISO/IEC 18013-5, que se presenta en persona por NFC o Bluetooth, o en línea, con cada elemento de datos revelado por separado y firmado por la autoridad emisora.
mdoc (documento móvil ISO/IEC 18013-5): El formato de credenciales basado en CBOR de ISO/IEC 18013-5, creado para los permisos de conducir móviles, en el que un emisor firma los resúmenes de cada elemento en un objeto de seguridad móvil y el dispositivo demuestra la posesión con su propia clave.
ML-DSA (FIPS 204): El algoritmo de firma digital basado en retículos de módulos (Module-Lattice-Based Digital Signature Algorithm) de FIPS 204 (agosto de 2024), derivado de CRYSTALS-Dilithium: la principal firma poscuántica del NIST, con los conjuntos de parámetros ML-DSA-44, ML-DSA-65 y ML-DSA-87.
ML-KEM (FIPS 203): El mecanismo de encapsulación de claves basado en retículos de módulos (Module-Lattice-Based Key-Encapsulation Mechanism) de FIPS 203 (agosto de 2024), derivado de CRYSTALS-Kyber: el intercambio de claves poscuántico estándar, con los conjuntos de parámetros ML-KEM-512, ML-KEM-768 y ML-KEM-1024.
mlkem768x25519-sha256: Intercambio de claves híbrido de SSH con ML-KEM-768, X25519 y SHA-256, estandarizado en el RFC 10042 y predeterminado en OpenSSH desde la 10.0 (abril de 2025).
MTA-STS (seguridad de transporte SMTP): El mecanismo del RFC 8461 con el que un dominio de correo publica por HTTPS una política que exige a los remitentes entregar solo por TLS, con un certificado válido, a los hosts MX indicados.
mTLS (TLS mutuo): TLS en el que el cliente también se autentica con un certificado y una firma CertificateVerify, de modo que ambos extremos demuestran la posesión de claves privadas; es habitual en el tráfico entre servicios, en los dispositivos y en los tokens vinculados al remitente de OAuth.
Multifirma Safe (cuenta inteligente Safe): La billetera de contrato inteligente más usada de Ethereum, que ejecuta una transacción solo cuando un umbral de propietarios ha firmado su hash SafeTx EIP-712; las firmas pueden ser ECDSA, firmas de contrato (ERC-1271) o aprobaciones en la cadena.
MuSig2: El esquema de multifirma de dos rondas de BIP-327 en el que n firmantes producen conjuntamente una única firma Schnorr BIP-340 válida bajo una sola clave pública agregada, indistinguible en la cadena de un gasto de un solo firmante.

N

NIST IR 8547: El documento del NIST «Transition to Post-Quantum Cryptography Standards» (transición a los estándares de criptografía poscuántica), un borrador público inicial de noviembre de 2024 que propone declarar en desuso después de 2030 los algoritmos vulnerables a la computación cuántica con seguridad de 112 bits y no permitir ningún algoritmo vulnerable después de 2035.
Nivel de seguridad (bits de seguridad): Una medida de la robustez criptográfica en la que s bits significa que el mejor ataque conocido necesita unas 2ˢ operaciones; sirve para comparar tamaños de clave entre algoritmos como AES-128, P-256 y RSA-3072.
Nombre alternativo del sujeto (SAN): La extensión X.509 (OID 2.5.29.17) que enumera los nombres DNS, las direcciones IP, las direcciones de correo electrónico o los URI para los que es válido un certificado, y el único campo que usan los navegadores para comprobar el nombre de host de un servidor.
Nombre distintivo (DN): El nombre jerárquico X.500 que se usa para el sujeto y el emisor de un certificado, formado por pares atributo–valor como CN, O, OU, L, ST y C.
Nonce (k de ECDSA): Número que se usa una sola vez; en las firmas ECDSA, DSA y Schnorr es el secreto k de cada firma, que además debe ser impredecible y uniformemente distribuido.
Normalización low-S: La regla según la cual el valor s de una firma ECDSA debe estar en la mitad inferior del intervalo (s ≤ n/2), que Bitcoin y Ethereum adoptaron para eliminar la maleabilidad de firma inherente a ECDSA.
Nostr: Un protocolo descentralizado de redes sociales y mensajería en el que los usuarios son pares de claves secp256k1 y cada evento es un objeto JSON identificado por su hash SHA-256 y firmado con una firma Schnorr BIP-340.
Notarización de Apple: El análisis automatizado de malware de Apple para el software de Mac firmado con Developer ID: los desarrolladores envían las compilaciones con notarytool, Apple devuelve un ticket que Gatekeeper comprueba, y ese ticket puede graparse a la app o al instalador.
Número de serie del certificado: El entero positivo, único por emisor y de hasta 20 octetos, que identifica un certificado en las CRL, las solicitudes OCSP y los informes de incidentes.

O

OAuth 2.0: El marco de autorización del RFC 6749 (2012) en el que un servidor de autorización emite tokens de acceso a los clientes para que llamen a las API con permisos delegados y acotados, en lugar de con las contraseñas de los usuarios.
OCSP (protocolo de estado de certificados): El protocolo del RFC 6960 con el que un cliente pregunta al respondedor de una CA si un certificado concreto está revocado y recibe una respuesta firmada (good, revoked o unknown) con un periodo de validez.
OID (identificador de objeto): Una secuencia de enteros separados por puntos, única en todo el mundo, como 1.2.840.10045.2.1, que se asigna mediante un árbol de registro delegado y se usa en ASN.1 para nombrar algoritmos, curvas, extensiones y políticas.
OIDC (OpenID Connect): La capa de identidad sobre OAuth 2.0 (OpenID Connect Core 1.0, 2014) que permite a un cliente verificar quién es un usuario mediante un token de ID firmado y obtener claims de perfil desde un endpoint UserInfo.
OpenID4VP (presentaciones verificables): El protocolo de la OpenID Foundation (versión 1.0 final, julio de 2025) con el que un verificador solicita credenciales a una cartera y recibe una presentación; se basa en OAuth 2.0 y lo usa la cartera europea de identidad digital (EUDI Wallet).
OpenPGP: El estándar del IETF para el cifrado de clave pública y la firma de mensajes y archivos con claves gestionadas por el usuario (RFC 9580, julio de 2024), implementado por GnuPG, Sequoia, OpenPGP.js y otros.

P

P-256 (secp256r1): La curva elíptica del NIST sobre un cuerpo primo de 256 bits, también llamada secp256r1 y prime256v1, que ofrece unos 128 bits de seguridad y es la curva más desplegada para ECDSA y ECDH.
P-384 (secp384r1): La curva elíptica del NIST sobre un cuerpo primo, con un orden de 384 bits y unos 192 bits de seguridad, obligatoria en la suite CNSA 1.0 de la NSA y habitual en el ámbito gubernamental y en las jerarquías de CA.
P-521 (secp521r1): La mayor curva prima del NIST, definida sobre el primo de Mersenne 2⁵²¹ − 1, con unos 256 bits de seguridad; ES512 de JOSE significa ECDSA en P-521 con SHA-512, no una curva de 512 bits.
PAdES: El perfil de ETSI para firmas PDF (EN 319 142) destinado a las firmas electrónicas avanzadas según eIDAS, con los niveles de base B-B, B-T (con sello de tiempo), B-LT (con datos de validación incrustados) y B-LTA (con sellos de tiempo de archivo).
Par de claves: Clave privada y clave pública ligadas matemáticamente, creadas juntas para un algoritmo asimétrico e, idealmente, un solo fin, como firma o acuerdo de claves.
PASETO (tokens de seguridad multiplataforma): Un formato de token concebido como alternativa más sencilla a JOSE, con protocolos versionados en lugar de algoritmos negociables: los tokens v4.public se firman con Ed25519 y los v4.local se cifran con XChaCha20 y se autentican con BLAKE2b con clave.
PEM: La envoltura en texto de datos DER como base64 entre las líneas -----BEGIN etiqueta----- y -----END etiqueta-----, estandarizada para los objetos PKIX en el RFC 7468 y usada por la mayoría de las herramientas para guardar certificados y claves.
permit (EIP-2612 y Permit2): Aprobaciones de tokens mediante firma: una firma EIP-712 fuera de la cadena autoriza a un spender a mover tokens y sustituye a una transacción approve en la cadena, ya sea por token (EIP-2612) o mediante el contrato compartido Permit2 de Uniswap.
personal_sign: El método de billetera de JSON-RPC de Ethereum que firma un mensaje con el prefijo EIP-191 de versión 0x45 y devuelve una firma r‖s‖v de 65 bytes; es el método predeterminado para el inicio de sesión y la firma de mensajes sencillos.
PIV (verificación de identidad personal): El estándar federal de EE. UU. para tarjetas inteligentes (FIPS 201-3, 2022) y su interfaz de tarjeta (SP 800-73), cuyas ranuras 9A, 9C, 9D y 9E guardan las claves de autenticación, de firma, de gestión de claves y de autenticación de la tarjeta; las YubiKey y otros tokens lo implementan.
PKCE (clave de prueba para el canje de código): La extensión de OAuth del RFC 7636 en la que el cliente envía un hash de un code_verifier aleatorio con la solicitud de autorización y el propio code_verifier con la solicitud de token, de modo que un código de autorización interceptado no sirve de nada.
PKCS #8: El contenedor de clave privada independiente del algoritmo (PrivateKeyInfo, RFC 5208; OneAsymmetricKey, RFC 5958) que se guarda en PEM como -----BEGIN PRIVATE KEY----- o, si está protegido con contraseña, como -----BEGIN ENCRYPTED PRIVATE KEY-----.
PKCS #12 (PFX): El formato de archivo protegido con contraseña del RFC 7292, normalmente guardado como .p12 o .pfx, que agrupa una clave privada con su cadena de certificados para importarla en navegadores, Windows, macOS, Java y Android.
Problema del número oculto: El problema de retículos que consiste en recuperar un secreto a partir de muchas relaciones lineales con ruido que revelan unos pocos de sus bits, y que convierte pequeños sesgos o fugas en los nonces de ECDSA y DSA en la recuperación completa de la clave privada.
Procedencia de compilación (build provenance): Un registro firmado y verificable de cómo se produjo un artefacto —repositorio de origen y commit, plataforma de compilación, flujo de trabajo y entradas— que permite a los consumidores comprobar que un paquete proviene del origen y del pipeline esperados.
Procedencia de npm (npm provenance): Procedencia SLSA firmada que se adjunta a los paquetes npm publicados desde un CI compatible (disponible de forma general desde el 26 de septiembre de 2023) y que vincula cada versión del paquete con su repositorio de origen, su commit y su flujo de trabajo de compilación.
Protección contra la degradación (downgrade): Los mecanismos que impiden que un atacante obligue a dos partes que admiten una versión del protocolo o un algoritmo robusto a pasar a uno más débil, como el centinela de TLS 1.3 en ServerHello.random.
PS256: El algoritmo JWS RSASSA-PSS con SHA-256 y MGF1-SHA-256 (RFC 7518 §3.5), que usa las mismas claves RSA que RS256 con el relleno PSS, aleatorizado y de seguridad demostrable.
PSBT (transacción parcialmente firmada): El formato de intercambio de BIP-174 (versión 0) y BIP-370 (versión 2) que transporta una transacción sin firmar junto con todos los datos que necesitan los firmantes, para que las billeteras, los dispositivos de hardware y los coordinadores puedan firmar en pasos separados.
Publicación de confianza (trusted publishing): La publicación de paquetes en un registro desde CI con una credencial de corta duración basada en OIDC en lugar de un token de API de larga duración; la introdujo PyPI en abril de 2023 y la ofrecen npm (disponible de forma general desde julio de 2025), RubyGems, crates.io y otros.

Q

QUIC: El protocolo de transporte sobre UDP (RFC 9000) que integra el handshake de TLS 1.3 (RFC 9001), cifra casi todos los metadatos de transporte y lleva HTTP/3.

R

Reanudación de sesión TLS: El restablecimiento de una sesión TLS a partir de los secretos de una conexión anterior, que omite la autenticación con certificado, ahorra cálculo y, en TLS 1.3, puede llevar datos 0-RTT.
Recuperación de la clave pública ECDSA: El cálculo de la clave pública del firmante a partir de una firma ECDSA y el hash del mensaje (SEC 1 §4.1.6), que la firma de mensajes de Ethereum y Bitcoin usa en lugar de transmitir la clave.
Red de confianza (web of trust): El modelo de confianza descentralizado de OpenPGP en el que los usuarios certifican las claves de los demás y cada usuario decide cuánto confía en quienes certifican, en lugar de depender de autoridades de certificación.
Requisitos para remitentes masivos: Las reglas que Gmail y Yahoo (desde febrero de 2024) y Microsoft (desde mayo de 2025) aplican a los remitentes de más de unos 5000 mensajes al día: SPF, DKIM, un registro DMARC alineado y la baja con un clic.
Resistencia al phishing: La propiedad de un método de autenticación por la que un sitio que imita al real no puede capturar ni reutilizar las credenciales; se logra cuando el autenticador vincula criptográficamente su respuesta al origen real, como hacen WebAuthn y TLS con certificado de cliente.
Restricciones básicas (basicConstraints): La extensión X.509 (OID 2.5.29.19) cuyo indicador cA dice si un certificado pertenece a una CA autorizada a firmar otros certificados, con un pathLenConstraint opcional que limita cuántas CA pueden seguirla en la ruta.
Restricciones de nombres (nameConstraints): La extensión X.509 (OID 2.5.29.30), permitida solo en certificados de CA, que limita los nombres que pueden contener los certificados subordinados mediante subárboles permitidos y excluidos de nombres DNS, rangos IP, dominios de correo electrónico y nombres de directorio.
Resumen del mensaje (digest): La salida de longitud fija de una función hash criptográfica aplicada a unos datos, que sirve como identificador compacto y resistente a colisiones de esos datos y como la entrada que, en realidad, firman la mayoría de los esquemas de firma.
RFC 6979 (ECDSA determinista): La especificación de 2013 de Thomas Pornin que deriva el nonce k de DSA o ECDSA a partir de la clave privada y el hash del mensaje con HMAC-DRBG, de modo que firmar no requiere un generador de números aleatorios.
Rotación de claves: Sustitución de una clave criptográfica por otra nueva de forma periódica o tras un incidente sin que la verificación deje de funcionar durante el cambio; lo habitual es publicar la clave antigua y la nueva a la vez.
RS256: El algoritmo JWS RSASSA-PKCS1-v1_5 con SHA-256 (RFC 7518 §3.3), el predeterminado histórico de los proveedores de OpenID Connect, cuyas firmas son tan largas como el módulo RSA (256 bytes con claves de 2048 bits).
RSA: El criptosistema de clave pública de Rivest, Shamir y Adleman (1977), cuya seguridad se basa en la dificultad de factorizar un módulo grande n = p·q y que se usa para firmas y, históricamente, para el transporte de claves.
RSA-OAEP: El cifrado RSA con relleno óptimo de cifrado asimétrico (OAEP, RFC 8017 §7.1), que JWE usa como RSA-OAEP (SHA-1) y RSA-OAEP-256 (SHA-256) para envolver claves de contenido, en sustitución del cifrado PKCS #1 v1.5, vulnerable a ataques.
RSASSA-PKCS1-v1_5: El relleno determinista de firma RSA de PKCS #1 v1.5 (RFC 8017 §8.2), que envuelve el hash en un DigestInfo ASN.1 completado con bytes 0xFF; es el RS256 de JWT y la firma RSA más común en X.509.
RSASSA-PSS: El esquema de firma RSA aleatorizado de PKCS #1 v2.1 y posteriores (RFC 8017 §8.1), que codifica el hash con una sal aleatoria y la función de máscara MGF1 y tiene una prueba de seguridad ajustada de la que carece PKCS #1 v1.5.

S

S/MIME: El estándar para firmar y cifrar correo electrónico con certificados X.509 y CMS (RFC 8551, S/MIME 4.0), integrado en Outlook, Apple Mail y Thunderbird y regulado, para los certificados públicos, por los S/MIME Baseline Requirements del CA/Browser Forum.
SAML 2.0: El estándar XML de OASIS (marzo de 2005) para intercambiar aserciones firmadas de autenticación y de atributos entre un proveedor de identidad y proveedores de servicios, que sigue siendo la columna vertebral del inicio de sesión único empresarial.
SBOM (lista de materiales de software): Un inventario legible por máquina de los componentes, versiones, licencias y relaciones de dependencia de un software, expresado sobre todo en SPDX o CycloneDX, que se usa para gestionar vulnerabilidades y para el cumplimiento normativo.
SCT (marca de tiempo de certificado firmada): La promesa firmada de un registro CT de incluir un certificado o un precertificado en su registro público, que llega a los clientes incrustada en el certificado, en una extensión TLS o en una respuesta OCSP grapada.
SD-JWT (divulgación selectiva para JWT): El formato del RFC 9901 (noviembre de 2025) en el que un emisor firma resúmenes con sal de los claims, y el titular revela solo los claims que elige enviando las divulgaciones (disclosures) correspondientes, opcionalmente con un JWT de key binding.
SD-JWT VC: El Internet-Draft del IETF que define un perfil de SD-JWT para credenciales digitales verificables, con typ dc+sd-jwt, un claim vct de tipo de credencial, estado y descubrimiento de las claves del emisor; es uno de los dos formatos de credencial de la cartera de identidad digital de la UE.
secp256k1: La curva elíptica de Koblitz de 256 bits y² = x³ + 7 de SEC 2, elegida por Bitcoin y usada también por Ethereum y Nostr, con unos 128 bits de seguridad.
Secure Enclave: El coprocesador de seguridad aislado de Apple en los chips de iPhone, iPad, Mac y Apple Watch, que crea claves no exportables y firma o descifra dentro del chip, opcionalmente tras Face ID, Touch ID o el código de acceso.
security.txt: Un archivo de texto en /.well-known/security.txt (RFC 9116) que indica a los investigadores de seguridad cómo notificar vulnerabilidades al dueño del sitio.
Sellado de tiempo de confianza (RFC 3161): Obtención de un token firmado, emitido por una autoridad de sellado de tiempo (TSA), que vincula el hash de unos datos a una hora de confianza, de modo que puede demostrarse que una firma es anterior a la caducidad o la revocación de un certificado.
Servicio de metadatos de FIDO (MDS): La lista firmada de la FIDO Alliance con las declaraciones de metadatos de los autenticadores certificados —AAGUID, certificados raíz de atestación, capacidades y estado de certificación—, que sirve para verificar la atestación.
SHA-1: La función hash de 160 bits de FIPS 180-1 (1995), hoy rota en la práctica frente a colisiones y que el NIST está retirando de toda protección criptográfica a más tardar el 31 de diciembre de 2030.
SHA-2: La familia de funciones hash de FIPS 180-4 —SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 y SHA-512/256—, diseñada por la NSA y publicada en 2001; hoy sus hashes son los predeterminados casi en todas partes.
SHA-3: La familia de hashes basada en Keccak y estandarizada en FIPS 202 (2015) —SHA3-224, SHA3-256, SHA3-384, SHA3-512 y las funciones de salida extensible SHAKE128 y SHAKE256—, construida sobre una esponja en lugar de Merkle–Damgård.
SHA-256: El miembro de 256 bits de la familia SHA-2 (FIPS 180-4), el hash por defecto de TLS, JWT, X.509, Bitcoin y la mayoría de las herramientas de integridad de archivos, con una resistencia de 128 bits a colisiones y de 256 bits a preimágenes.
SHAKE128 y SHAKE256: Las funciones de salida extensible (XOF) de FIPS 202, que producen una salida de la longitud que se pida a partir de la esponja Keccak, con una seguridad de 128 y 256 bits respectivamente si la salida es lo bastante larga.
Sigstore: Un servicio de firma de código abierto que certifica claves efímeras para identidades OIDC (Fulcio) y registra las firmas públicamente (Rekor), de modo que los artefactos pueden firmarse y verificarse sin claves de larga duración.
SIWE (Sign-In with Ethereum): El formato de mensaje de ERC-4361 para iniciar sesión con una cuenta de Ethereum: un texto legible con dominio, dirección, URI, versión, ID de cadena, nonce y fecha de emisión, firmado con personal_sign.
SLH-DSA (FIPS 205): El algoritmo de firma digital sin estado basado en hash (Stateless Hash-Based Digital Signature Algorithm) de FIPS 205 (agosto de 2024), derivado de SPHINCS+, cuya seguridad se basa solo en funciones hash, a costa de firmas de 7,8–50 KB y de una operación de firma lenta.
SLSA (niveles de la cadena de suministro): Un marco de OpenSSF de niveles incrementales de integridad de la compilación y del código fuente —por ejemplo, Build L3 significa una procedencia generada por una plataforma de compilación reforzada y aislada—, cuya especificación actual es la v1.2 (noviembre de 2025).
SNI (indicación del nombre del servidor): La extensión de TLS (RFC 6066 §3, extensión 0) en la que el cliente nombra el host al que quiere conectarse, de modo que una sola dirección IP puede servir muchos certificados; se envía en claro salvo que se use Encrypted Client Hello.
sntrup761x25519-sha512: El intercambio de claves de SSH que combina Streamlined NTRU Prime sntrup761 con X25519 y calcula el hash con SHA-512; fue el predeterminado de OpenSSH desde la versión 9.0 (2022) hasta que mlkem768x25519-sha256 lo sustituyó en la 10.0.
SPF (marco de políticas del remitente): La política publicada en el DNS que define el RFC 7208 y que enumera qué hosts pueden enviar correo usando un dominio en el sobre SMTP (MAIL FROM o HELO); los receptores la comprueban con la dirección IP que se conecta.
SSH (Secure Shell): El protocolo de los RFC 4251–4254 para el inicio de sesión remoto autenticado y cifrado, la ejecución de comandos, la transferencia de archivos y el reenvío de puertos, en el que el servidor demuestra su identidad con una clave de host y los usuarios se autentican con claves, certificados o contraseñas.
SSHSIG (firmas SSH): El formato de OpenSSH para firmar datos arbitrarios con claves SSH (ssh-keygen -Y sign), que vincula un espacio de nombres a cada firma y es la base de los commits de Git firmados con SSH y de la verificación con firmantes permitidos (allowed signers).
STARTTLS: Un comando de protocolo que pasa a TLS una conexión ya abierta en texto plano —en SMTP (RFC 3207), IMAP, POP3, LDAP y XMPP— y que queda expuesto a la degradación salvo que una política exija TLS.
SubjectPublicKeyInfo (SPKI): La estructura ASN.1 del RFC 5280 que empareja un identificador de algoritmo con los bits de la clave pública; se usa dentro de cada certificado X.509 y como formato estándar de archivo de clave pública (-----BEGIN PUBLIC KEY-----).

T

Taproot: La bifurcación suave (soft fork) de Bitcoin definida en los BIP 340, 341 y 342, activada en el bloque 709.632 el 14 de noviembre de 2021, que añadió las firmas Schnorr y las salidas P2TR, que se comprometen con una clave y con un árbol opcional de scripts.
TLS (seguridad de la capa de transporte): El protocolo del IETF que autentica a un servidor (y, opcionalmente, a un cliente) y cifra un flujo de bytes entre ambos; lo usan HTTPS, el correo, las API y la mayoría de los demás protocolos de Internet, y su versión actual es la 1.3.
TLS 1.2: La versión de TLS de 2008 (RFC 5246), todavía ampliamente admitida, que introdujo los conjuntos de cifrado AEAD y SHA-256, pero que necesita dos viajes de ida y vuelta y permite opciones débiles que TLS 1.3 eliminó.
TLS 1.3: La versión actual de TLS, publicada como RFC 8446 en 2018 y revisada como RFC 9846 en 2026, con un handshake de un solo viaje de ida y vuelta, forward secrecy obligatorio, conjuntos de cifrado exclusivamente AEAD y un handshake cifrado.
Token de acceso: La credencial que un cliente OAuth presenta a un servidor de recursos para llamar a una API en nombre de un usuario o en el suyo propio: una cadena opaca que se comprueba por introspección o un JWT autocontenido.
Token de ID: El JWT que un proveedor de OpenID Connect emite para un cliente con el fin de acreditar la autenticación de un usuario, con al menos los claims iss, sub, aud, exp e iat y firmado por el proveedor.
Token de portador (bearer token): Un token de acceso que concede acceso a quien lo presente, sin prueba de posesión de ninguna clave (RFC 6750); normalmente se envía en el encabezado de autorización, como Authorization: Bearer seguido del token.
TUF (The Update Framework): Una especificación para actualizaciones de software seguras, graduada en la CNCF en 2019, que separa la firma en los roles root, targets, snapshot y timestamp, con umbrales y caducidad, para resistir el compromiso de claves.
typ (encabezado JOSE del tipo): El parámetro del encabezado JOSE que declara el tipo de medio del token completo, como JWT, at+jwt, dpop+jwt o kb+jwt, y que se usa para el tipado explícito, de modo que un tipo de token no pueda sustituirse por otro.

U

Uso extendido de clave (EKU): La extensión de X.509 (OID 2.5.29.37) que enumera los propósitos de aplicación para los que puede usarse la clave de un certificado, como id-kp-serverAuth, id-kp-clientAuth, id-kp-codeSigning o id-kp-emailProtection.

V

Validación de dominio (DV): El nivel de validación de certificados en el que una CA verifica solo que el solicitante controla los nombres de dominio del certificado, mediante desafíos DNS, HTTP o TLS-ALPN, y nada sobre la organización.
Validación de la ruta de certificación: El algoritmo del RFC 5280 §6 que decide si una cadena desde un ancla de confianza hasta un certificado de entidad final es válida; comprueba firmas, períodos de validez, nombres, restricciones, políticas y revocación.
Validación de organización (OV): El nivel de validación de certificados en el que la CA verifica, además del control del dominio, la existencia legal, el nombre y la dirección de la organización solicitante, y los incluye en el sujeto del certificado.
Validación extendida (EV): El nivel de validación de certificados TLS más estricto, definido en las EV Guidelines del CA/Browser Forum, en el que la CA verifica la existencia legal, física y operativa de la organización y anota en el certificado los detalles de su registro.
Verificación de firmas: La comprobación, mediante criptografía de clave pública, de que una firma se generó exactamente sobre este mensaje con la clave privada que corresponde a una clave pública dada, con un algoritmo que el verificador eligió de antemano.
Verificación del usuario (UV): La comprobación local que hace el autenticador de que el usuario autorizado está presente y queda identificado —mediante biometría, PIN o la contraseña del dispositivo—, señalada por el indicador UV en los datos del autenticador de WebAuthn.
Vida útil del certificado (período de validez): El intervalo desde el notBefore de un certificado hasta su notAfter, ambos incluidos; para los certificados TLS de confianza pública, el máximo es de 200 días desde el 15 de marzo de 2026, y baja a 100 días en 2027 y a 47 días en 2029.
VMC (certificado de marca verificada): Un certificado X.509 que vincula un dominio con el logotipo de una marca registrada para BIMI; se emite tras validar la marca y la identidad, y lleva el logotipo SVG en una extensión de logotipo (logotype).

W

Web Bot Auth: Una iniciativa del IETF, basada en las firmas de mensajes HTTP (HTTP Message Signatures), para que los clientes automatizados, como los rastreadores y los agentes de IA, firmen sus solicitudes con una clave publicada y los sitios web puedan identificarlos de forma fiable en lugar de fiarse de las cadenas de user-agent o de los rangos de IP.
WebAuthn (autenticación web): La API de navegador del W3C (navigator.credentials.create y get con opciones publicKey) con la que los sitios web registran y usan credenciales de clave pública en autenticadores; WebAuthn Level 3 pasó a ser Recomendación del W3C el 25 de agosto de 2026.
WKD (directorio web de claves): Un método para publicar claves OpenPGP en tu propio dominio, bajo /.well-known/openpgpkey/, de modo que los clientes de correo puedan obtener por HTTPS la clave de una dirección de correo electrónico (draft-koch-openpgp-webkey-service).

X

X.509: El formato de certificado de la UIT-T, perfilado para Internet por el RFC 5280, que vincula una clave pública a un nombre de sujeto y a unas extensiones bajo la firma de una autoridad de certificación emisora.
x5c (cabecera de cadena de certificados X.509): El parámetro del encabezado JOSE y miembro de JWK que lleva una cadena de certificados X.509 como un array de certificados DER codificados en base64 (no base64url), el primero de los cuales contiene la clave de firma.
X25519: La función Diffie–Hellman sobre Curve25519 definida en el RFC 7748, con claves de 32 bytes y un secreto compartido de 32 bytes, que se usa para el intercambio de claves en TLS 1.3, SSH, WireGuard, Signal y age.
X25519MLKEM768: El grupo 0x11EC de TLS 1.3 (RFC 10024): intercambio de claves híbrido de ML-KEM-768 y X25519, la opción poscuántica por defecto en navegadores, OpenSSL y Go.
XAdES: El formato de ETSI para firmas electrónicas avanzadas sobre XML (EN 319 132), que amplía XML-DSig con propiedades firmadas, como la hora de firma y el resumen del certificado, y con los niveles de largo plazo B-T, B-LT y B-LTA.
XMSS y XMSS^MT: El esquema de firma de Merkle extendido (eXtended Merkle Signature Scheme) del RFC 8391 y de NIST SP 800-208: una firma basada en hash con estado construida sobre claves de un solo uso WOTS+, con una variante multiárbol para una mayor capacidad de firma.
xpub (clave pública extendida): Una clave pública extendida de BIP-32 —clave pública más código de cadena— que puede derivar todas las claves públicas hijas no endurecidas y las direcciones que hay por debajo de ella; la usan las billeteras de solo lectura (watch-only) y los servidores de pago.

#

0-RTT (datos tempranos de TLS): La función de TLS 1.3 que permite a un cliente que reanuda una sesión incluir datos de aplicación ya en su primer envío, cifrados con una clave de una sesión anterior, a costa de perder, para esos datos, la protección contra repetición y la forward secrecy.

Glosario

De la A a la Z

A

Á

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

Q

R

S

T

U

V

W

X

#

Por tema

Firmas · 52 términos

JOSE y JWT · 39 términos

PKI y certificados · 69 términos

TLS · 65 términos

Correo electrónico · 18 términos

Web3 · 33 términos

Criptografía poscuántica · 34 términos

Identidad y WebAuthn · 53 términos

Cadena de suministro · 30 términos

OpenPGP · 9 términos

Matemáticas · 48 términos