feat: add ML-DSA post-quantum signature type to SLIP-0010 standard

[manel1874]

This PR updates SLIP-0010 standard by adding the NIST standardized ML-DSA post-quantum signature (FIPS204) to the universal hierarchical derivation.

Approach summary

• Similarly to the ed25519 and X25519 variants, ml-dsa only supports hardened derivations.
• In summary, the derivation is equivalent to ed25519 and X25519 variants but it uses the usual private key as the seed to a key generation procedure.

Test vectors

• I am using bedrock-python lib as cryptography libs currently does not support ML-DSA.
• bedrock-python supports keypair generation from seed and passes the official NIST KATs tests from NIST ACVP Server (RELEASE/v1.1.0.40).

Let me know what you think or what can be improved.

[andrewkozlik]

Thanks for your contribution. I haven't had time to look into this yet, but want to mention two things:

1. There is some research into the topic of post quantum BIP32 schemes we should look at when evaluating this PR: https://eprint.iacr.org/2026/380/. It's mainly about how the Raccoon signature scheme can be adapted for BIP32, but there is also something about ML-DSA.
2. My first impression is that we should be using SLIP-21 for curves and signature schemes that only allow hardened derivation, and that adding x25519 and ed25519 to SLIP-10 the way it was added was a mistake. It would have been better to use https://input-output-hk.github.io/adrestia/static/Ed25519_BIP.pdf in SLIP-10, or something like SLIP-21 (which didn't exist at the time) with hardened-only derivation.

[shemnon]

1. Raccoon is a separate algorithm in the lattice family and would warrant a separate seed. (the K and R curves are different, for example) The paper justifies why non-hardened keys for ML-DSA are a bad idea and makes an argument as to why raccoon keys are safe to use in non-hardened derivations. The need for test vectors makes it difficult to simply add it in.

2. SLIP-21 is about symmetric key derivations, not hardened only derivations. Those are fairly orthagonal interests.

Perhaps making a new SLIP that creates a mechanical naming convention for crypto algorithms from NIST and other standards bodies would be more appropriate if there is a concern about overloading SLIP-0010. However each algorithm would need it's own hardened-only or non-hardened capable decision. In addition each algorithm would need to specify it's deterministic seed process. This can be problematic because some algos do not define a fixed deterministic derivation in their specification and rely on community code.

[manel1874]

@andrewkozlik thanks for your comments!

1. ML-DSA approach described in 2026/380, Fig. 3 is the same as QIP0002: they both use a deterministic seed-based key generation, where the seed comes from the standard BIP32 derivation. In essence, they both follow a similar approach as SLIP10 with (e.g.) ed25519 but, instead of taking $I_L$ as the key, they run a KeyGenFromSeed with $I_L$ as the seed. This PR basically puts these things together with a standardized "Key" to generate the master node for each of the ML-DSA variants and provides test vectors.
2. I agree with @shemnon. One thing though is that SLIP10 is more focused on curves (understandable because everything used to be all around EC) rather than a generic asymmetric key derivation mechanisms.