Algoritmos JOSE: valores alg e enc para JWS e JWE

EdDSA

O identificador polimórfico EdDSA da RFC 8037, descontinuado pela RFC 9864 em favor de Ed25519 e Ed448.

Com “EdDSA”, a curva vem da chave (crv: Ed25519 ou Ed448), então uma parte não consegue anunciar qual curva aceita. A RFC 9864 registra os nomes totalmente especificados Ed25519 e Ed448 e marca “EdDSA” como descontinuado (Deprecated).

ES256

ECDSA na P-256 com SHA-256, o algoritmo JWS mais usado em JWTs assinados com chaves assimétricas.

Uma assinatura JWS com ES256 é a concatenação de 64 bytes de r e s, cada um preenchido até 32 bytes (RFC 7518 §3.4), e não a estrutura DER que o OpenSSL e o Java produzem; a conversão entre as duas é uma fonte comum de erros “invalid signature” — veja o conversor DER ⇄ bruto.

A RFC 9864 descontinua o identificador COSE polimórfico ES256 (−7) em favor do ESP256 (−9), totalmente especificado; no JOSE, o nome ES256 já fixa a curva, então ele não é afetado.

HS256

HMAC com SHA-256, um algoritmo JWS simétrico: quem consegue verificar um token também consegue forjar um.

O HS256 é o único algoritmo que a RFC 7518 torna obrigatório. Como o mesmo segredo assina e verifica, ele serve para um único serviço que emite e verifica os próprios tokens. Um segredo curto ou fácil de adivinhar pode ser descoberto por força bruta, offline, a partir de qualquer token; a RFC 7518 §3.2 exige uma chave pelo menos do tamanho da saída do hash — 256 bits para o HS256 — e ela precisa ser aleatória.

ML-DSA-65

ML-DSA-65 (FIPS 204) para JWS, registrado pela RFC 9964 junto com o novo tipo de chave AKP.

As chaves JWS pós-quânticas usam o tipo de chave Algorithm Key Pair (par de chaves de algoritmo, kty “AKP”), cujo membro “pub” contém a chave pública ML-DSA bruta e cujo “alg” a vincula a um único conjunto de parâmetros. As assinaturas têm 3.309 bytes, então os tokens passam a ter vários kilobytes.

none

O alg “none” identifica um JWS não protegido — um token sem nenhuma assinatura.

A RFC 7518 §3.6 define “none” para contextos em que a integridade é garantida por outros meios. Bibliotecas que deixam o próprio cabeçalho do token escolher o algoritmo já aceitaram tokens forjados com alg “none”, a vulnerabilidade de JWT mais conhecida (RFC 8725 §2.1); os verificadores precisam rejeitá-lo, a menos que a aplicação espere explicitamente tokens não protegidos.

RS256

RSASSA-PKCS1-v1_5 com SHA-256, o algoritmo JWS da maioria dos tokens de ID do OpenID Connect.

O OpenID Connect Core §15.1 exige que os provedores ofereçam suporte à assinatura de tokens de ID com RS256, e é por isso que a maioria dos tokens de ID e dos endpoints JWKS usa chaves RSA. A armadilha clássica dele é a confusão de algoritmo: um verificador que aceita HS256 para uma chave destinada ao RS256 pode ser induzido a usar a chave pública como segredo HMAC (RFC 8725 §2.1). Fixe o algoritmo esperado para cada chave, como exige a RFC 8725 §3.1.

RSA1_5

Criptografia de chave RSAES-PKCS1-v1_5 para JWE, exposta a ataques de padding oracle no estilo Bleichenbacher.

Um servidor que revela de qualquer forma — por uma mensagem de erro, pelo tempo de resposta — se o padding de uma chave RSA1_5 descriptografada era válido permite que um atacante descriptografe chaves de conteúdo uma consulta por vez. A RFC 7518 classifica o RSA1_5 como “Recommended-” (recomendado, mas provavelmente será rebaixado); prefira RSA-OAEP-256 ou ECDH-ES.