Research seriesL3algorithms
FIPS 204 calls ML-DSA strongly unforgeable, hedges its signing randomness, offers three ways to sign, and the IETF has now fixed how its keys and signatures travel in certificates, messages and tokens. This paper series reads each of those decisions at the level of its evidence: what the quantum random-oracle proof actually assumes and where it was repaired, why a byte-exact signature matters for logs, tokens and ledgers, which fault attacks the rnd input stops and which it does not, what moves out of a hardware module when signing is split at the message representative, and what RFC 9881, RFC 9882, RFC 9964 and the composite draft settle or leave to the deployer. Every topic is tied to the signatures AI agents now depend on: signed tool calls, agent identities and model provenance.
FIPS 204 calls ML-DSA strongly unforgeable. Behind that sentence sits a bound with three assumptions, one of them non-standard, and a proof repaired in 2023.
Many systems treat a signature as an identifier. ML-DSA is designed to make that safe, but only if verifiers enforce every encoding check and applications know its limits.
FIPS 204 makes ML-DSA signing hedged by default. That single 32-byte input defeats one published class of fault attack and leaves several others standing.
FIPS 204 offers three ways to sign a large message with a key in hardware. They differ in what the hardware can still see, and the IETF has already chosen one.
Three RFCs and an approved draft now fix how ML-DSA keys and signatures travel. Their small decisions, about seeds, contexts and composites, shape every agent identity built on them.