ECDH-SS reads the "epk" header parameter when the key being tried is a private key

Open
  • Is something wrong?
#770 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
php
Domain
backend-api-design, security

Research direction

Read ECDHSS::getAgreementKey() and the parent AbstractECDH::getAgreementKey() to trace how recipient and sender keys are selected. Check the decrypt method docblocks named in the issue and existing ECDH-SS tests; add coverage for private recipient keys, sender key validation, and curve matching. Done means ECDH-SS uses the two static keys and the decrypt parameter descriptions match the supported key layout.

Written by the indexing model from the issue text.

Description

bug
Version(s) affected

Every release since 3.1.0 (3.4.x, 4.0.x, 4.1.x, 4.2.x), and the 4.3.x and 5.0.x branches.

Description

ECDHSS::getAgreementKey() checks that a sender key is given, then delegates to AbstractECDH::getAgreementKey(), which was written for ECDH-ES. When the key passed as recipient key has a private part (d), the parent takes the other public key from the epk header parameter and ignores the sender key. A static-static agreement must only be computed from the two static keys: ECDHSS never writes epk and should never read it. ECDH-SS+A128KW, ECDH-SS+A192KW and ECDH-SS+A256KW delegate to ECDHSS and behave the same.

Consequences:

  • With the argument order the JWEDecrypter::decrypt() docblock suggests (own private key as key, the partner's public key as $senderKey), every genuine ECDH-SS token is rejected with The header parameter "epk" is missing.
  • When the key set holds the recipient's own private key next to the partners' public keys (for instance one key set shared by ECDH-ES and ECDH-SS) and a sender key is passed, a token labelled ECDH-SS that carries an epk is decrypted with the recipient's private key alone. Such a token needs no partner key, so "alg": "ECDH-SS" no longer proves that the sender holds one of the static keys. DecryptionResult::getKey() then returns the recipient's own key.

Not affected: the documented layout (the sender's public key in the key set, the recipient's private key as $senderKey), JWELoader and NestedTokenLoader (they never pass a sender key), and private keys whose alg member names another algorithm.

Possible Solution
  • In ECDHSS, never take the ephemeral path. When the recipient key is private, use it as the private key and the public part of the sender key as the public key (the agreement is symmetric). Validate both static keys and require the same curve.
  • Correct the $keys/$senderKey descriptions of JWEDecrypter::decrypt(), decryptUsingKeySet() and JWEDecrypterInterface::decrypt().
  • Until then, applications using ECDH-SS should check DecryptionResult::getKey() against the expected sender key.
Additional Context

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

Dominant language
PHP
Stars
954
Forks
119
Avg merge
48m
Merged PRs (30d)
17

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from web-token/jwt-framework

All issues in web-token/jwt-framework

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.