ADR-0003 — Ed25519 as the Sole Signing Algorithm for All Cryptographic Attestations
Status: ACCEPTED Date: 2026-02-28 Authors: Matthew Lynch matthew.lynch@helix-os.ai FR-Refs: FR-AUD-002, FR-VAL-001 Supersedes: None Superseded by: None
Context
HELIX OS requires cryptographic signatures in multiple critical subsystems:
- Electronic signatures — Operator actions, batch approvals, and reason-for-change records must be signed per 21 CFR Part 11 §11.50 and §11.70 (FR-AUD-002).
- Ledger attestations — Audit ledger checkpoints are signed to create non-repudiable integrity proofs.
- Validation reports — IQ/OQ/PQ PDF reports are cryptographically signed to prevent post-generation tampering (FR-VAL-001).
- Code signing — Release artifacts may be signed for supply chain integrity.
The signing algorithm must be:
- Fast — Signature generation and verification occur on the hot path during operator interactions and ledger checkpoints.
- Small — Signature size and key size affect ledger storage overhead. Every ledger entry that carries a signature pays this cost.
- Deterministic — Signing the same message with the same key must always produce the same signature. Non-deterministic signatures (e.g., ECDSA without RFC 6979) introduce audit reproducibility issues.
- Well-understood — The algorithm must have extensive, peer-reviewed cryptanalysis and wide deployment.
A single algorithm must be selected to avoid the complexity and validation burden of supporting multiple signature schemes.
Decision
The system shall use Ed25519 (Edwards-curve Digital Signature Algorithm over Curve25519) as the sole cryptographic signing algorithm for all attestations, electronic signatures, and integrity proofs within HELIX OS.
Key properties enforced:
- Exclusive use — No other signing algorithm (RSA, ECDSA, Ed448, etc.) shall be used for any HELIX OS attestation. Ed25519 is the only sanctioned algorithm.
- Deterministic signatures — Ed25519 is inherently deterministic. The same (message, key) pair always produces the same signature. No random nonce is required.
- 64-byte signatures, 32-byte public keys — Compact representation minimizes ledger storage overhead.
- Key storage — Private keys are stored in platform-native secure enclaves where available (e.g., TPM 2.0, macOS Keychain). Fallback to encrypted PKCS#8 on disk.
The implementation will use the ed25519-dalek Rust crate for key generation, signing, and verification.
Rationale
- Speed: Ed25519 signature generation takes ~50 µs and verification takes ~100 µs on commodity hardware. Both are fast enough for hot-path use without impacting the 2 ms P99 latency budget.
- Determinism: Unlike ECDSA (which requires a random nonce and fails catastrophically if the nonce is reused), Ed25519 is fully deterministic. This eliminates an entire class of implementation vulnerabilities and ensures that signing operations are reproducible for audit purposes.
- Compact: 64-byte signatures and 32-byte public keys are the smallest of any widely deployed signature scheme. This minimizes per-entry overhead in the audit ledger, which may accumulate millions of signed entries over a system's lifetime.
- Peer-reviewed: Ed25519 was designed by Daniel J. Bernstein et al. and has been extensively analyzed since 2011. It is deployed in SSH, TLS 1.3, Signal Protocol, and numerous blockchain systems. The cryptographic community considers it mature and well-understood.
- No patent encumbrance: Curve25519 and Ed25519 are explicitly placed in the public domain by their designers.
- Single algorithm simplicity: One signing algorithm means one key management system, one verification path, one set of tests. This dramatically reduces the validation burden under GMP.
Alternatives Considered
| Alternative | Reason for Rejection |
|---|---|
| RSA-2048/4096 | Signatures are 256-512 bytes (4-8x larger). Key generation is 1000x slower. Signing is ~10x slower. Excessive for high-frequency attestations. |
| ECDSA (P-256) | Non-deterministic without RFC 6979. Implementation complexity is higher. No security or performance advantage over Ed25519. Historical nonce-reuse vulnerabilities in deployed systems. |
| Ed448 | Larger keys and signatures (57-byte keys, 114-byte signatures) with minimal practical security gain over Ed25519. Slower. Less ecosystem support. |
| Configurable / pluggable signing | Adds key-management complexity, multiplies test surface, introduces algorithm-negotiation attack surface. Rejected. |
| Post-quantum (Dilithium/ML-DSA) | Signature sizes are 2-5 KB — unacceptable for per-entry ledger use. Performance is adequate but the standards are still maturing (FIPS 204 was only finalized in 2024). Premature for a production GMP system. A future ADR may add PQ signatures as a secondary layer if regulatory guidance evolves. |
Consequences
Positive
- Fast, deterministic signatures on the hot path with minimal latency impact.
- Compact 64-byte signatures keep ledger storage efficient at scale.
- Single algorithm simplifies key management, verification, and validation testing.
- Mature, widely deployed algorithm with strong cryptographic provenance.
- No patent concerns.
Negative
- Ed25519 is not NIST-approved as a standalone standard (though Curve25519 is recognized in SP 800-186). Similar regulatory considerations as ADR-0002. Mitigation: Ed25519 is accepted in FIPS 186-5 (2023) under EdDSA. A compliance mapping document will be prepared.
- No post-quantum resistance. If quantum computing advances threaten 128-bit security, signatures will need to be augmented. Mitigation: the ledger's hash chain (Blake3, ADR-0002) provides a secondary integrity layer. PQ migration is a future concern, not an immediate risk for pharmaceutical equipment with 15-year lifecycles starting in 2026.
Risks
- Regulatory scrutiny: An auditor unfamiliar with Ed25519 may question the choice. Mitigation: prepare a compliance whitepaper mapping Ed25519 to FIPS 186-5 EdDSA and to the "validated cryptographic techniques" language in 21 CFR Part 11.
- Key compromise: If a signing key is compromised, all signatures made with that key are suspect. Mitigation: key rotation policy, hardware-backed key storage, and short-lived signing keys for operator sessions. These are operational controls, not algorithm-level issues.
- Supply chain: Dependency on
ed25519-dalek. Mitigation: the crate is audited by third parties, has a strong maintenance track record, and can be vendored.
Compliance Notes
- FR-AUD-002: Electronic signature capture and reason-for-change enforcement. Ed25519 provides the cryptographic primitive for electronic signatures.
- FR-VAL-001: Automated generation of cryptographically signed IQ/OQ/PQ PDF reports. Ed25519 signs the generated reports.
- 21 CFR Part 11 §11.50: Requires signed electronic records to be attributable to the signer. Ed25519 key pairs bound to operator identities satisfy this requirement.
- 21 CFR Part 11 §11.70: Requires that electronic signatures be linked to their respective records to ensure signatures cannot be excised, copied, or transferred. The Ed25519 signature over the Blake3 hash of the record content provides this binding.
- FIPS 186-5 (2023): Recognizes EdDSA (including Ed25519) as an approved digital signature scheme.
- This ADR is permanent per
HELIX-VAL-STR-001. Superseding it requires a full re-validation cycle including IQ/OQ/PQ.
Revision History
| Date | Author | Change |
|---|---|---|
| 2026-02-28 | Matthew Lynch | Initial accepted decision |