FROST Ed25519 for threshold release signing

[kwsantiago]

Problem

Single-key release signing infrastructure is a single point of failure. If the signing key is lost or compromised, the project's release integrity is gone. FROST threshold signing distributes this risk.

Solution

Add Ed25519 FROST support to Keep for general-purpose threshold signing beyond Bitcoin. Primary use case: t-of-n release signing where no single person holds the full key.

Why Ed25519

• Covers minisign, SSH signatures, and signify (most common release signing tools)
• frost-ed25519 crate from ZF FROST suite shares the same Ciphersuite trait as frost-secp256k1
• Broader applicability than P-256 (sigstore) for open source projects

Architecture

• Generalize keep-core FROST layer behind the Ciphersuite trait (already designed this way in ZF crates)
• New feature flag or crate (keep-signing?) to avoid bloating the Bitcoin path
• DKG, share storage, encrypted backup/export, Nostr coordination all reuse existing infrastructure
• Output: detached .sig files compatible with minisign/signify verification

Reference

• igloo-desktop: GPG signing of SHA256SUMS, multi-platform CI workflow, verification instructions
• liana: reproducible builds + signed release tags
• bifrost: session binding pattern (reusable for signing sessions)

Scope

• frost-ed25519 integration behind Ciphersuite trait
• CLI: keep sign <file> / keep verify <file> <sig>
• Share management reuses existing import/export (bech32 encoding, QR)
• CI integration example for GitHub Actions

Non-goals (initially)

• P-256 / sigstore support (add later if needed)
• GPG compatibility (different signature format)
• macOS code signing (requires Apple certificates, orthogonal)