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

Đang mở
  • Có gì không ổn?
#770 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
php
Lĩnh vực
backend-api-design, security

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
PHP
Star
954
Fork
119
Merge trung bình
48 phút
Pull request đã merge (30 ngày)
17

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của web-token/jwt-framework

Tất cả issue của web-token/jwt-framework

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.