Algoritmos JOSE: valores alg y enc para JWS y JWE

EdDSA

El identificador polimórfico EdDSA del RFC 8037, declarado obsoleto por el RFC 9864 en favor de Ed25519 y Ed448.

Con «EdDSA», la curva sale de la clave (crv: Ed25519 o Ed448), así que una parte no puede anunciar qué curva admite. El RFC 9864 registra los nombres totalmente especificados Ed25519 y Ed448 y marca «EdDSA» como obsoleto (Deprecated).

ES256

ECDSA en P-256 con SHA-256, el algoritmo JWS más usado en los JWT firmados con claves asimétricas.

Una firma JWS con ES256 es la concatenación de 64 bytes de r y s, cada uno rellenado hasta 32 bytes (RFC 7518 §3.4), y no la estructura DER que producen OpenSSL y Java; la conversión entre ambas es una fuente habitual de errores «invalid signature»: consulta el conversor DER ⇄ en bruto.

El RFC 9864 declara obsoleto el identificador COSE polimórfico ES256 (−7) en favor de ESP256 (−9), totalmente especificado; en JOSE, el nombre ES256 ya fija la curva, así que no le afecta.

HS256

HMAC con SHA-256, un algoritmo JWS simétrico: quien puede verificar un token también puede falsificarlo.

HS256 es el único algoritmo que el RFC 7518 hace obligatorio. Como el mismo secreto firma y verifica, es adecuado para un único servicio que emite y comprueba sus propios tokens. Un secreto corto o fácil de adivinar se puede obtener por fuerza bruta sin conexión a partir de cualquier token; el RFC 7518 §3.2 exige una clave al menos tan larga como la salida del hash —256 bits para HS256—, y debe ser aleatoria.

ML-DSA-65

ML-DSA-65 (FIPS 204) para JWS, registrado por el RFC 9964 junto con el nuevo tipo de clave AKP.

Las claves JWS poscuánticas usan el tipo de clave Algorithm Key Pair («par de claves de algoritmo», kty «AKP»), cuyo miembro «pub» contiene la clave pública ML-DSA en bruto y cuyo «alg» la vincula a un único conjunto de parámetros. Las firmas ocupan 3309 bytes, así que los tokens llegan a medir varios kilobytes.

none

alg «none» marca un JWS sin protección, es decir, un token sin ninguna firma.

El RFC 7518 §3.6 define «none» para contextos en los que la integridad se garantiza por otros medios. Las bibliotecas que dejan que el propio encabezado del token elija el algoritmo han aceptado tokens falsificados con alg «none», la vulnerabilidad de JWT más conocida (RFC 8725 §2.1); los verificadores deben rechazarlo salvo que la aplicación espere explícitamente tokens sin protección.

RS256

RSASSA-PKCS1-v1_5 con SHA-256, el algoritmo JWS de la mayoría de los tokens de ID de OpenID Connect.

OpenID Connect Core §15.1 exige que los proveedores admitan la firma de tokens de ID con RS256, y por eso la mayoría de los tokens de ID y de los endpoints JWKS usan claves RSA. Su error clásico es la confusión de algoritmos: a un verificador que acepta HS256 para una clave destinada a RS256 se le puede engañar para que use la clave pública como secreto HMAC (RFC 8725 §2.1). Fija el algoritmo esperado para cada clave, como exige el RFC 8725 §3.1.

RSA1_5

Cifrado de claves RSAES-PKCS1-v1_5 para JWE, expuesto a ataques de oráculo de relleno del tipo Bleichenbacher.

Un servidor que revela de cualquier forma —un mensaje de error, el tiempo de respuesta— si el relleno de una clave RSA1_5 descifrada era válido permite a un atacante descifrar las claves de contenido consulta a consulta. El RFC 7518 marca RSA1_5 como «Recommended-», es decir, que probablemente bajará de categoría; usa en su lugar RSA-OAEP-256 o ECDH-ES.