Алгоритмы JOSE: значения alg и enc для JWS и JWE

EdDSA

Полиморфный идентификатор EdDSA из RFC 8037; RFC 9864 объявил его устаревшим в пользу Ed25519 и Ed448.

С «EdDSA» кривая определяется ключом (crv: Ed25519 или Ed448), поэтому сторона не может объявить, какую кривую она поддерживает. RFC 9864 регистрирует полностью определённые имена Ed25519 и Ed448 и помечает «EdDSA» как устаревший (Deprecated).

ES256

ECDSA на P-256 с SHA-256 — алгоритм JWS, который чаще всего используют для подписанных JWT с асимметричными ключами.

Подпись JWS с ES256 — это 64-байтовая конкатенация r и s, каждое из которых дополнено до 32 байт (RFC 7518, § 3.4), а не структура DER, которую создают OpenSSL и Java; преобразование между ними — частый источник ошибок «invalid signature», см. конвертер DER ⇄ raw.

RFC 9864 объявляет устаревшим полиморфный идентификатор COSE ES256 (−7) в пользу полностью определённого ESP256 (−9); в JOSE имя ES256 уже фиксирует кривую, поэтому изменение его не затрагивает.

HS256

HMAC с SHA-256, симметричный алгоритм JWS: тот, кто может проверить токен, может и подделать его.

HS256 — единственный алгоритм, который RFC 7518 делает обязательным. Один и тот же секрет и подписывает, и проверяет, поэтому такой алгоритм подходит для одного сервиса, который сам выпускает и проверяет свои токены. Короткий или угадываемый секрет можно подобрать перебором офлайн по любому токену; RFC 7518, § 3.2 требует ключ не короче выхода хеш-функции (256 бит для HS256), и этот ключ должен быть случайным.

ML-DSA-65

ML-DSA-65 (FIPS 204) для JWS, зарегистрирован в RFC 9964 вместе с новым типом ключа AKP.

Постквантовые ключи JWS используют тип ключа Algorithm Key Pair (kty «AKP»): его параметр «pub» содержит открытый ключ ML-DSA в формате raw, а «alg» привязывает ключ к одному набору параметров. Подписи занимают 3 309 байт, поэтому токены вырастают до нескольких килобайт.

none

alg «none» обозначает незащищённый JWS — токен вообще без подписи.

RFC 7518, § 3.6 определяет «none» для контекстов, где целостность обеспечивается другими средствами. Библиотеки, которые позволяют заголовку самого токена выбирать алгоритм, принимали поддельные токены с alg «none» — это самая известная уязвимость JWT (RFC 8725, § 2.1); проверяющие стороны должны отклонять такой алгоритм, если приложение явно не ожидает незащищённых токенов.

RS256

RSASSA-PKCS1-v1_5 с SHA-256 — алгоритм JWS большинства ID-токенов OpenID Connect.

OpenID Connect Core, § 15.1 требует от поставщиков OpenID поддерживать подпись ID-токенов алгоритмом RS256, поэтому большинство ID-токенов и эндпоинтов JWKS используют ключи RSA. Классическая ловушка RS256 — подмена алгоритма: проверяющую сторону, которая принимает HS256 для ключа, предназначенного для RS256, можно заставить использовать открытый ключ как секрет HMAC (RFC 8725, § 2.1). Закрепляйте ожидаемый алгоритм за каждым ключом, как требует RFC 8725, § 3.1.

RSA1_5

RSAES-PKCS1-v1_5 — шифрование ключа для JWE, уязвимое к атакам на оракул дополнения вроде атаки Блейхенбахера.

Если сервер любым способом (сообщением об ошибке, временем ответа) раскрывает, было ли корректным дополнение расшифрованного ключа RSA1_5, злоумышленник может расшифровывать ключи содержимого запрос за запросом. RFC 7518 помечает RSA1_5 как «Recommended-», то есть его статус, вероятно, будет понижен; предпочтительнее RSA-OAEP-256 или ECDH-ES.