Cryptographic backends and algorithm agility
Luvion separates authorization meaning from the cryptographic backend used to produce an authorization output. Policy, intent, roles, participant set, key epoch, execution permission, and evidence remain stable even when a deployment uses a different reviewed signing backend.
Logical backend boundary
A backend must define key generation or import, session creation, partial authorization, partial verification, aggregation, final verification, key lifecycle, and transcript evidence. Each backend must document its own security model and operational assumptions.
Backend status
| Backend | Role in Luvion | Current status |
|---|---|---|
| FROST Ed25519 | Current commercial threshold-authorization path | Implemented and demonstrated under controlled validation |
| Threshold ECDSA | Compatibility path for chain-native signing environments | Interface and future integration path |
| Hardware-protected remote signer | Compatibility path for HSM, KMS, TEE, or managed signing boundaries | Interface and production requirement |
| External custody authorization backend | Compatibility path for provider-controlled execution | Interface defined; provider mapping and acceptance required |
| Threshold ML-DSA-65 | Post-quantum research and migration path | Experimental research using synthetic keys |
ML-DSA boundary
FIPS 204 standardizes ML-DSA, not Luvion's threshold extension. The current 22-of-33 research path does not establish a production-secure threshold ML-DSA protocol. Distributed nonce handling, protected rejection evaluation, malicious security, identifiable abort, transcript safety, and external cryptographic review remain required before real keys or production assets can use that path.
Algorithm agility is a migration property, not a claim that every backend has equal maturity.