Add ML-DSA Signing Implementation

[bbug96-crkim]

Description
This PR implements ML-DSA (Module Lattice Digital Signature Algorithm) post-quantum cryptographic signatures for model signing, providing quantum-resistant security standardized as NIST FIPS 204. Additionally, it includes documentation cleanup to fix broken links and remove redundant files.

Motivation
As quantum computing advances, traditional cryptographic signatures (like ECDSA) will become vulnerable to attacks. ML-DSA provides quantum-resistant security for long-term model integrity protection (10+ years). This implementation ensures that models signed today will remain verifiable even in a post-quantum era.

Problems Solved

1. Quantum Vulnerability: Existing ECDSA signatures are vulnerable to quantum computer attacks
2. Long-term Security: Models requiring extended verification periods need quantum-resistant signatures
3. Standards Compliance: NIST FIPS 204 standardization provides industry-accepted post-quantum security
4. Key Security: Password-protected private keys using AES-256-GCM encryption
5. Documentation Issues: Fixed broken NIST FIPS 204 links and incorrect file paths

Changes Made
Core Features (Commit 4caedff)

• ML-DSA Signing Implementation: Complete support for all three security levels (ML-DSA-44, ML-DSA-65, ML-DSA-87)
• CLI Integration: New sign ml-dsa and verify ml-dsa commands with password protection
• Key Encryption: AES-256-GCM encryption for private keys with PBKDF2 key derivation (100,000 iterations)
• Key Management Tool: ml_dsa_key_tool.py for encrypting/decrypting/verifying keys
• Python API: use_ml_dsa_signer() and use_ml_dsa_verifier() methods in Config classes
• Comprehensive Testing:
• • 7 integration tests in api_test.py
• • 8 CLI tests in cli_ml_dsa_test.py
• • Shell test scripts for version compatibility
• • 100% test pass rate
• Documentation:
• Extensive examples in [ml_dsa_examples.md]
• README updates with post-quantum cryptography section

Documentation Cleanup (Commit 0023a82)

• Fixed broken NIST FIPS 204 URL (/publications/detail/ → /pubs/)
• Fixed ML-DSA implementation documentation link in README
• Fixed [ml_dsa_key_tool.py] source path resolution
• Removed redundant documentation files ([ml_dsa_implementation.md, ml_dsa_testing.md)
• Updated Quantum-Safe column in signature size comparison table
• Fixed relative paths in documentation links

Breaking Changes
None - this is a purely additive feature. Existing ECDSA and Sigstore signing methods remain unchanged.

Performance Notes

• Signature Size: ML-DSA signatures are ~50x larger than ECDSA (acceptable tradeoff for quantum resistance)
• Signing Speed: Slightly slower than ECDSA but still sub-second
• Verification Speed: Comparable to traditional methods

Checklist

• [v] All commits are signed-off, using DCO
• [v] All new code has docstrings and type annotations
• [v] All new code is covered by tests. Aim for at least 90% coverage. CI is configured to highlight lines not covered by tests.
• [v] Public facing changes are paired with documentation changes
• [v] Release note has been added to CHANGELOG.md if needed

Added

• ML-DSA Post-Quantum Signatures: Added support for NIST FIPS 204 ML-DSA (Module Lattice Digital Signature Algorithm) quantum-resistant signatures with three security levels (ML-DSA-44, ML-DSA-65, ML-DSA-87).
• CLI Commands: Added model_signing sign ml-dsa and model_signing verify ml-dsa commands with password protection support.
• Key Encryption: Added AES-256-GCM encryption for ML-DSA private keys with PBKDF2 key derivation (100,000 iterations).
• Key Management Utility: Added scripts/ml_dsa_key_tool.py for encrypting, decrypting, and verifying ML-DSA keys.
• Python API: Added use_ml_dsa_signer() and use_ml_dsa_verifier() methods to signing.Config and verifying.Config classes.
• Dependencies: Added optional [pqc] extra for post-quantum cryptography support (dilithium-py).

Fixed

• Fixed broken NIST FIPS 204 documentation links (updated from /publications/detail/ to /pubs/ URL structure).
• Fixed ML-DSA implementation documentation link in README.md.
• Fixed ml_dsa_key_tool.py source path resolution for correct module imports.
• Updated Quantum-Safe column values in ML-DSA signature size comparison table.

Changed

• Removed redundant documentation files (ml_dsa_implementation.md, ml_dsa_testing.md) to streamline documentation.

Documentation

• Added comprehensive ML-DSA examples guide (docs/ml_dsa_examples.md) with 750+ lines covering all use cases.
• Updated README.md with Post-Quantum Cryptography section including key generation, signing, verification, and password-protected keys.

Dependencies:

• dilithium-py: ML-DSA implementation (install with pip install model-signing[pqc])
• cryptography: Already in dependencies, used for AES-GCM encryption

• Model signature changes (additions, deletions, updates)
• API additions: new functions, new arguments, new supported signing methods, etc.
• Anything noteworthy to an administrator using model-signing package (err on the side of over-communicating)
• New features and improvements, including behavioural changes, UI changes and CLI changes
• Bug fixes and fixes of previous known issues
• Deprecation warnings, breaking changes, or compatibility notes

[bbug96-crkim]

I reviewed

[bbug96-crkim]

@sigstore/model-transparency-codeowners
I'd like to request your review of this change. If I'm mishandling the review process, please let me know so I can correct it.

[mihaimaruseac]

Sorry for coming late to these.

You need to add a "Signed-off-by" line to each commit to pass the DCO check. Will review once the commits are amended and squashed

[Hayden-IO]

Hey, thanks for the PR. I'm not going to chime in on the code itself, but rather PQC in the Sigstore ecosystem and more generally adoption of it in tooling.

When it comes to PQC adoption, we have to take a step back and ask why now. Quantum confidentiality, where data that is encrypted now can be decrypted later (e.g. save-now-decrypt-later attacks on TLS), is a critical use case, and one that's solved by the adoption of ML-KEM. This isn't something that affects digital signing applications though. Quantum integrity/authenticity, e.g. forging a signature, is what ML-DSA supports, but ecosystems can more quickly mitigate this threat simply by rejecting classical crypto algorithms. With quantum integrity, cryptographic algorithm agility, being able to adopt new algorithms on a short timeline, is what's more important than actually adopting the new algorithm. If you're selling software to the gov't or you have a signature that can never be updated (e.g. firmware), then a more tight timeline for adoption makes sense, but we're still talking by 2030, not immediately.

For Sigstore, we've published a blog post that discusses the community's thoughts on how we should go about adopting PQC algorithms. The short answer is we'd like to follow NIST guidance and avoid making decisions now (as in, not baking in algorithm choices into clients that we'll have to support indefinitely), while also still encouraging experimentation. Sigstore also needs to figure out how to support PQC in the infrastructure, not just the clients. We can't just replace ECDSA with ML-DSA as the infrastructure storage costs would balloon.

It looks like this PR is meant to simply add an alternative rather than integrate ML-DSA into existing parts of the codebase. For what it's worth, I think this is the right way to do it at the moment, but I don't see a reason this should be added to the codebase as that suggests that this is the community's recommended approach to PQC. As the Sigstore ecosystem begins to adopt PQC, then this library can adopt PQC as well, likely indirectly through sigstore-python. For now, experimenting in a fork seems reasonable.

This PR also requires installing https://github.com/GiacomoPope/dilithium-py, which has a giant red warning: "⚠️ Under no circumstances should this be used for cryptographic applications. ⚠️". This is another issue with PQC adoption, that there are not a lot of great implementations besides ones in pure C. We cannot encourage users to install a prototype implementation of a cryptographic algorithm.

[mihaimaruseac]

Going to close this, based on Hayden's comments and waiting for Sigstore support first, rather than getting a separate library