Associate classical keys with quantus keys

[illuzen]

Not sure if this makes sense but kind of interesting.

It's not hooked up to the runtime yet, just starting a conversation.

---

Note

Medium Risk
New on-chain identity/crypto surface with permanent bindings and signature verification, but it is isolated from the live runtime until integrated and benchmarked.

Overview
Adds a new pallet-key-association workspace crate (registered in root Cargo.toml / lockfile) that is not wired into quantus-runtime yet.

The pallet exposes associate: a signed ML-DSA account can link ECDSA (secp256k1) or Ed25519 public keys after the classical key signs a fixed challenge (Quantus Key Association + SCALE-encoded account/key + block hash). Replay protection checks the signed block hash against on-chain frame_system history and enforces a window from BlockHashCount.

On success it stores a per-account bounded list (MaxAssociations), a Blake2-128 reverse index (one classical key → one account, no unlink), emits KeyAssociated, and ships placeholder weights plus broad unit tests (valid paths, limits, and error cases).

^{Reviewed by Cursor Bugbot for commit d320fc2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d320fc2. Configure here.}

[cursor]

Future blocks pass validity check

High Severity

The associate extrinsic's expiry check fails when signed_block_number is greater than the current block. saturating_sub returns zero, bypassing the validity window. This allows using a future block number, for which frame_system::block_hash returns a predictable zero hash, undermining replay protection.

 

^{Reviewed by Cursor Bugbot for commit d320fc2. Configure here.}