Loganaden Velvindron wrote: >What are the security issues you see in this pr ?
>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. 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 [2] Digital signature schemes with strong existential unforgeability 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 [4] OWASP, Signature Malleability 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/ [6] BUFFing signature schemes beyond unforgeability and the case of post-quantum signatures https://ieeexplore.ieee.org/document/9519420 [7] A Framework for Advanced Signature Notions 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 [9] Bird of Prey: Practical Signature Combiners Preserving Strong Unforgeability 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]
