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

未关闭
  • 哪里不对？
#770 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
php
领域
backend-api-design, security

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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).

主要语言
PHP
星标
954
派生
119
平均合并
48 分钟
30 天内合并 PR
17

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

web-token/jwt-framework 的其他 Issue

查看 web-token/jwt-framework 的全部 Issue

相似的 Issue

更多 PHP Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。