AES-CBC-HMAC: AL covers the protected header only, so the tag of a JWE with an "aad" member does not follow RFC 7518

Abierto
  • ¿Algo no está bien?
#759 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
58/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php
Área
cryptography, security

Línea de trabajo

Find AESCBCHS::calculateAuthenticationTag() and trace how it builds A and computes AL for JSON serialization with an aad member. Add the external known-answer test and cross-implementation vectors described in the issue. Done means AL covers the whole A, the tags interoperate with another JOSE implementation, and the regression tests pass; check the compatibility impact for existing tokens and the proposed upgrade note.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug
Version(s) affected

All released versions (3.4.x, 4.0.x, 4.1.x, 4.2.x), and the 4.3.x and 5.0.x branches. The computation dates from the initial import.

Description

AESCBCHS::calculateAuthenticationTag() builds the additional authenticated data A as BASE64URL(protected) || '.' || BASE64URL(aad) when the JWE has an aad member, but computes AL, the 64-bit length appended to the HMAC input, from the protected header alone. AL must be the length of the whole A, in bits.

This only concerns A128CBC-HS256, A192CBC-HS384 and A256CBC-HS512 JWEs that carry an aad member, which exists in the JSON serializations only. Compact tokens, tokens without aad, and AES-GCM are not affected.

Consequences:

  • Interoperability: the tag differs from the one conforming implementations compute. Tokens issued by this library are rejected by them (checked with panva/jose 6.2.2), and theirs are rejected by this library.
  • The tag does not commit to the length of the AAD, so the boundary between the AAD and the IV is not authenticated. A token whose aad is a strict prefix of the original one, or that has no aad at all, can be made to verify. The AAD content itself cannot be changed, and each such change prepends an unpredictable block to the decrypted payload, so JSON claims and nested tokens no longer parse.
How to reproduce

Encrypt a payload with A128KW and A128CBC-HS256 and an aad, serialize it with the JSON flattened serializer, and decrypt it with another JOSE implementation: the authentication tag is rejected. The other way round fails the same way. Without aad, both directions work.

Possible Solution

Compute AL over the whole A, and add a known-answer test whose expected tag is computed outside the library, plus vectors produced by another implementation.

CBC-HMAC tokens with aad issued by earlier versions stop decrypting after the change, and tokens from other implementations start decrypting. A fallback to the old computation would keep the weakness, so there should be none. Proposed for 4.3.0 with an upgrade note.

Additional Context

Found by the Anthropic OSS Scanner (ANT-2026-SO6XMWCE).

Lenguaje dominante
PHP
Estrellas
954
Forks
119
Merge medio
48 min
PR fusionados (30 d)
17

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de web-token/jwt-framework

Todos los issues de web-token/jwt-framework

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.