The write-up and sample files proving malleability of ML-DSA signatures of X.509 certificates with OpenSSL certificate verification is here: https://github.com/crypto-security-tools/on-composites-signatures
I paste the text here for convenience: Strongly unforgeable signatures do not lead to unique X.509 certificatesHere we provide counter evidence to the claim that the use of signature schemes that fulfill Strong Unforgeability under Chosen Message Attack (SUF-CMA) lead to X.509 certificates that are unique, i.e., even their signature cannot be modified. This argument has been used [3] to show that the lack of SUF-CMA in the composite signature scheme defined in draft-ietf-lamps-pq-composite-sigs [1] is a real-world weakness.
In particular we show that even in a certificate signed with ML-DSA, which achieves SUF-CMA, the signature can be modified while retaining its verifiability with OpenSSL.
The sample file |mldsa.der| is the original certificate. The sample file |mldsa.modified.der| has an extraneous zero octet in the length encoding of the signature. The |dumpasn1| tool detects this:
|<03 83 00 0C EE 00 0A C4 03 D3 21 1D 13 E6 7C E5 F8 A2 97 28 A8 C7 52 A5> 1577 3310: BIT STRING : 0A C4 03 D3 21 1D 13 E6 7C E5 F8 A2 97 28 A8 C7 : 52 A5 9D 2C 30 BD 29 A1 94 35 50 75 AD 84 1A C7 : 89 B1 DB 82 EC 5F 2B 9C A1 8E 6F 84 1C 25 79 98 : AE 97 B4 80 E7 86 C4 35 A1 64 39 6D 10 E7 59 AD : 83 F9 9A D3 12 F5 3E 52 74 05 89 B0 20 17 DB 6C : 8C BA 6A 78 9A 8D C1 69 15 B0 7A C4 2C 47 EE B3 : C1 28 A3 74 97 5C 11 D0 77 89 20 4D 46 FD A8 99 : 3A A2 B6 6D 46 90 5E 46 44 9E A2 DA 0C 12 77 AF : [ Another 3181 bytes skipped ] : Error: Length '83 00 0C EE' has non-canonical encoding. : } |
However, both sample certificates can be verified with OpenSSL [2] against the issuer certificate:
|$ openssl verify -CAfile dsa-ca.crt.pem mldsa.modified.der mldsa.modified.der: OK |
This shows that achieving unique binary encodings of signatures requires far more than SUF-CMA signature schemes. Besides a superfluous length octet, other subtle modifications are conceivable, such as playing with the number of unused bits in the bit string, or the encoding of NULL parameters in the algorithm identifier (instead of their absence) preceding the signature.
In the context of Bitcoin, for which malleable signatures lead to a critical vulnerability, the first attempt to solve the problem was BIP 62 <https://en.bitcoin.it/wiki/BIP_0062>, which tries to achieve unique binary encoding of the signature. It explicitly addresses strict DER encoding as a necessity. However, the long term solution was to remove the reliance on SUF-CMA and unique signature encodings in BIP 141 <https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki>. BIP 141 solves the problem in a robust way by separating out the signature from the transaction data.
------------------------------------------------------------------------ [1] https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/[2] We used OpenSSL 3.5.6 7 Apr 2026 (Library: OpenSSL 3.5.6 7 Apr 2026) on Debian 13
[3] https://mailarchive.ietf.org/arch/msg/tls/Wo9h9hhKZyqxkjYLDhjFpqvBaoU/ Am 06.06.26 um 18:45 schrieb John Mattsson:
An answer to your prvious mail can be found here: https://mailarchive.ietf.org/arch/msg/tls/SqcgdaAGom_8pjGWrEQ2oMbfWfs/I respectfully disagree with all of your arguments for why these technical aspects should not be discussed in the TLS WG. The TLS WG and TLS libraries are not required to support anything defined in the ITU-T X.509 ecosystem, including new cryptographic algorithms designed in LAMPS. Furthermore, draft-reddy-tls-composite-mldsa proposes registering new cryptographic algorithms for use with the signature_algorithms_cert extension, making their impact on TLS directly relevant to this discussion. Moreover, since a stated objective of draft-reddy-tls-composite-mldsa is to address implementation issues in ML-DSA, it is equally relevant to examine whether it may introduce implementation issues in TLS systems, which it clearly can.I believe my technical comments clearly explain why malleable signatures can create significant vulnerabilities in systems using TLS and why use of such signatures should be phased out, not expanded.Cheers, John Preuß Mattson *From: *Falko Strenzke <[email protected]> *Date: *Wednesday, 3 June 2026 at 12:28*To: *John Mattsson <[email protected]>; Loganaden Velvindron <[email protected]> *Cc: *Sophie Schmieg <[email protected]>; IETF TLS <[email protected]>; [email protected] <[email protected]> *Subject: *Re: [TLS] Re: [Last-Call] Re: Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFCAm 03.06.26 um 10:17 schrieb John Mattsson: Loganaden Velvindron wrote: >What are the security issues you see in this pr ? >_https://github.com/djmdjm/openssh-wip/pull/64_ <https://github.com/djmdjm/openssh-wip/pull/64> The PR is based on draft-ietf-lamps-pq-composite-sigs [1]. As I wrote previously: All modern signature schemes (RSA-PSS, EdDSA, LMS, XMSS, ML-DSA, SLH-DSA, FN-DSA) avoid trivial attacks on strong unforgeability and are widely believed to provide a high level of SUF-CMA security [2]. The transition to PQC provides an excellent opportunity to phase out signatures with trivial attacks on strong unforgeability. Malleable signatures have enabled serious attacks in the past [3] and will likely do so again if they continue to be used. Malleable signatures can undermine system integrity, auditability, and provenance, and, in the worst case, may even enable replay attacks, see [4]. This is also true for certificates. There is a significant gap between what people think a certificate fingerprint represents and what cryptography actually guarantees when a certificate is signed with a malleable signature algorithm. With such signature algorithms, a CA does not issue a single certificate; instead, it issues a set of valid certificates, each with its own fingerprint.As I pointed out before on this list, irrespectively of the correctness of this point, it is not relevant to the draft we are discussing here. ML-DSA-composite X.509 CA certificates are already standardised once draft-ietf-lamps-pq-composite-sigs becomes an RFC. The only relevant point in the discussion at hand can be whether TLS end-entity certificates with ML-DSA-composite keys introduce problems. Since EE certificates don't sign other certificates, I wonder what exactly you are referring to when you write about mismatching fingerprints. You should point out where in the TLS protocol such malleable fingerprints occur and why they are a problem, as this is the only point where the composite signatures performed by TLS EE certificates will occur.Falko This mismatch has practical consequences. Logging, SIEM, and threat intelligence systems often record events such as “Observed certificate fingerprint X connecting to service Y,” implicitly treating the fingerprint as a stable identifier. Similarly, some firewall blocklists operate on fingerprints (e.g., “Block fingerprint X”), see e.g., [5], and incident response workflows often rely on fingerprints as unique identifiers when searching for the attacker across datasets. In the presence of only EUF-CMA guarantees, these assumptions break down, as the same underlying certificate can appear under many fingerprints. Nation-state attackers are known to deliberately confuse logging systems, evade signature-based detection, and introduce ambiguity into forensic analysis, and they can be expected to exploit signature malleability for these purposes as well. Some poorly designed composite signature constructions such as [1] not only significantly reduce the security properties of ML‑DSA by inheriting the malleability of ECDSA, but also introduce additional malleability weaknesses. The composites in [1] also significantly weaken the security of ML-DSA by failing to preserve its beyond-unforgeability (BUFF) properties [6–7]. As shown in [8], existential unforgeability alone does not capture the guarantees required by real-world protocols, and the lack of beyond unforgeability (BUFF) properties in traditional signature schemes has enabled concrete attacks on deployed systems; see [6–7]. We note that there exist signature combiners that preserve both SUF-CMA and BUFF properties [9]. [1] Composite ML-DSA for use in X.509 Public Key Infrastructure _https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs_ <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs> [2] Digital signature schemes with strong existential unforgeability _https://pmc.ncbi.nlm.nih.gov/articles/PMC9925878/_ <https://pmc.ncbi.nlm.nih.gov/articles/PMC9925878/> [3] Bitcoin Transaction Malleability and MtGox _https://link.springer.com/chapter/10.1007/978-3-319-11212-1_18_ <https://link.springer.com/chapter/10.1007/978-3-319-11212-1_18> [4] OWASP, Signature Malleability _https://scs.owasp.org/SCWE/SCSVS-CRYPTO/SCWE-054/_ <https://scs.owasp.org/SCWE/SCSVS-CRYPTO/SCWE-054/> [5] Secure Firewall - Blacklisted SSL Certificate Fingerprint _https://research.splunk.com/network/c43f7b49-2dab-4e76-892e-7f971c2f20f1/_ <https://research.splunk.com/network/c43f7b49-2dab-4e76-892e-7f971c2f20f1/> [6] BUFFing signature schemes beyond unforgeability and the case of post-quantum signatures _https://ieeexplore.ieee.org/document/9519420_ <https://ieeexplore.ieee.org/document/9519420> [7] A Framework for Advanced Signature Notions _https://eprint.iacr.org/2025/960.pdf_ <https://eprint.iacr.org/2025/960.pdf> [8] Seems Legit: Automated Analysis of Subtle Attacks on Protocols that Use Signatures _https://eprint.iacr.org/2019/779.pdf_ <https://eprint.iacr.org/2019/779.pdf> [9] Bird of Prey: Practical Signature Combiners Preserving Strong Unforgeability _https://eprint.iacr.org/2025/1844.pdf_ <https://eprint.iacr.org/2025/1844.pdf> --- Some comments on the PR conversation >Non-canonical S is also accepted 1. This implies that the Ed25519 implementation is based on old code not compliant with RFC 8032 and retains known vulnerabilities. Contrary to claims made on the TLS list, Ed25519 has not been "stable since 2010." The original Ed25519 specification was vulnerable to malleability attacks, and this vulnerability were addressed by CFRG in RFC 8032 in 2017. The 2010 version should not be used. 2. Simply fixing this bug and bringing the implementation into conformance with RFC 8032 does not address the malleability issues. The new signature algorithms defined in draft-ietf-lamps-pq-composite-sigs introduce a new malleability vulnerability. >I don't think this matters for OpenSSH's use case since you aren't building a cryptocurrency >yeah, we haven't cared about SUF-CMA previously because (like you said) it's totally irrelevant to SSH That is incorrect. SSH signatures are general-purpose and are used in a wide range of contexts outside of the SSH protocol. The new algorithms defined in draft-ietf-lamps-pq-composite-sigs introduce a malleability attack that is not present in EdDSA or ML-DSA, and they eliminate the BUFF properties provided by ML-DSA. Both signature malleability and the absence of BUFF properties have been the root cause of serious attacks in the past. > but that crowd does incredibly dumb things with cryptography so I can't entirely rule out downstream impact to them. I find this quite arrogant. Signatures should not be malleable, and no standardized signature schemes are, except ECDSA, which was designed by the NSA. Stating that people who do not except signatures to be malleable are "incredibly dumb" is like saying that Bernstein is incredibly dumb for not understanding how to use SHA-2 securely in SPHINCS+. If anything is incredibly dumb, it is to standardize, implement, and deploy new malleable signatures. --- I find the idea that ML-DSA is an NSA backdoor to be absurd, but if that conspiracy theory is in any way a driving factor for this PR, it is illogical to use Ed25519, whose security ultimately depends on SHA-2, a hash function designed by the NSA. ML-DSA and SHA-3 were primarily designed by European cryptographers. --- I am starting to think that /draft-ietf-lamps-pq-composite-sigs/ [1] is one of the worst things to come out of the IETF in a very long time: - It is very poorly designed. It removes the BUFF properties of ML-DSA and introduces a new malleability weakness. One would think the reason to wait for FIPS 204 was to ensure that all security properties of ML-DSA were preserved, but this is not the case. Composite signatures are new cryptographic constructions and should be designed within CFRG. - The design goals were not security. The goal is shady business practices of selling FIPS-validated RSA and ECDSA as “quantum-resistant.” You can slap on ML-DSA reference code from 2017 and suddenly you have a “FIPS-validated” ML-DSA hybrid. - It is now the biggest obstacle to the urgent migration of roots of trust in PKI and long-lived devices. If standalone ML-DSA is not trusted, standalone SLH-DSA by Bernstein and others is an excellent alternative for roots of trust. - It is a Trojan horse for well-designed composite and non-composite hybrid schemes that could actually be deployed. It is consuming time that could be spent on other approaches, while being so poorly designed that it cannot be deployed. Ericsson will not support [1] in any of our libraries, products, or services. We will use non-composite hybrids signatures. Cheers, John Preuß Mattsson _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected] -- *MTG AG* Dr. Falko Strenzke Phone: +49 6151 8000 24 E-Mail: [email protected] Web: mtg.de <https://www.mtg.de> ------------------------------------------------------------------------ MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany Commercial register: HRB 8901 Register Court: Amtsgericht Darmstadt Management Board: Jürgen Ruf (CEO), Tamer Kemeröz Chairman of the Supervisory Board: Dr. Thomas MildeThis email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error, please inform the sender immediately and delete this email.Unauthorised copying or distribution of this email is not permitted.Data protection information: Privacy policy <https://www.mtg.de/en/privacy-policy>
-- *MTG AG* Dr. Falko Strenzke Phone: +49 6151 8000 24 E-Mail: [email protected] Web: mtg.de <https://www.mtg.de> ------------------------------------------------------------------------ MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany Commercial register: HRB 8901 Register Court: Amtsgericht Darmstadt Management Board: Jürgen Ruf (CEO), Tamer Kemeröz Chairman of the Supervisory Board: Dr. Thomas MildeThis email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error, please inform the sender immediately and delete this email.Unauthorised copying or distribution of this email is not permitted.
Data protection information: Privacy policy <https://www.mtg.de/en/privacy-policy>
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
