Skip to content

Weak Key Acceptance and Curve Mismatch in ECDSA (ES256/ES384/ES512) Signature Validation #377

@JWTSecAPI

Description

@JWTSecAPI

Hi,
We are a research group dedicated to helping developers build secure and standards-compliant cryptographic software. As part of an ongoing study on JWT security, we developed an automated detector for identifying cryptographic misuse and insecure API design patterns in JWT libraries.
While analyzing your impressive public repository, our system identified several security issues that may impact the robustness of your JSON Web Signature (JWS) implementation:
1. Insecure Key Length Acceptance
Your implementation allows the use of weak cryptographic keys in JWS:
HMAC: The system permits HMAC keys shorter than the recommended 112 bits (e.g., keys of 16 or 32 bytes). This violates CWE-326: Inadequate Encryption Strength and opens the door to brute-force attacks.
RSA: The library accepts RSA signing keys shorter than 2048 bits, which no longer provide adequate security per NIST SP 800-131A.
We recommend enforcing stronger key length validation for both HMAC and RSA in your signing API to prevent cryptographic downgrade risks.
**2. Incorrect Curve Handling in ECDSA **
We also discovered that your library permits keys generated over the P-256 curve to be used for signature generation , even when the JWT header explicitly specifies "alg": "ES512". This is a standards violation and introduces a dangerous algorithm downgrade scenario.
According to RFC 7518, Section 3.4, ES512 must use the secp256r1 (P-521) curve. Allowing weaker curves can be exploited to mount signature confusion or cryptographic downgrade attacks.
3. Recommendation and Responsible Disclosure
We strongly encourage:
Strict enforcement of key length requirements for all supported algorithms.
Curve parameter validation to ensure alignment with the declared JWT algorithm.
Rejecting any JWTs where the key type or curve does not strictly match the
alg header.
All issues have been confirmed via automated and manual validation using test vectors. We are submitting this disclosure privately in accordance with responsible disclosure practices, and we are happy to collaborate or provide PoC scripts upon request.
Thank you for your attention to these issues and for your work in supporting the open-source security ecosystem.
Best regards.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions