Citadel is unaudited software.

The implementation:

• Uses NIST-standardized primitives (ML-KEM-768, AES-256-GCM, HKDF-SHA256)
• Follows established hybrid construction patterns (X25519 + ML-KEM)
• Has comprehensive test coverage including fuzz testing
• Has NOT undergone independent security audit

Only the latest release receives security fixes.

Do not open public issues for security vulnerabilities.

1. Go to the repository's Security tab
2. Click "Report a vulnerability"
3. Provide details (see below)

Email: andre.cordero36@gmail.com

PGP key available at: [keyserver-link]

• Affected versions / commit hash
• Minimal reproduction case
• Expected vs. actual behavior
• Impact assessment
• Whether timing side-channels or DoS is involved

• Memory safety — parsing panics, buffer overflows, use-after-free
• Cryptographic correctness — wrong outputs, key leakage, nonce reuse
• Oracle behavior — distinguishable errors that leak information
• Misuse resistance failures — accepting malformed inputs, downgrade attacks
• Key handling bugs — missing zeroization, accidental exposure
• Wire format vulnerabilities — version confusion, suite downgrade

• Key management, access control, or compliance certification
• Platform-level compromise (OS, hardware)
• Side-channel attacks requiring physical access
• Denial of service via large inputs (documented limitation)
• Issues in dependencies (report upstream, notify us)

1. Hybrid security — if either X25519 or ML-KEM-768 remains secure, plaintext is protected
2. AAD/context binding — wrong AAD or context causes decryption failure
3. Tampering detection — any modification to ciphertext causes failure
4. Uniform errors — all decryption failures produce identical error type
5. Wire format stability — v1 format will always be decodable

1. Constant-time execution — inherited from dependencies, not verified
2. Side-channel resistance — not tested against power/EM/timing attacks
3. FIPS compliance — uses NIST primitives, not a certified module
4. Performance — optimized for correctness, not speed

Citadel depends on:

We track security advisories for all dependencies via cargo audit.

• Bug fixes and security patches
• No breaking API changes
• Wire format compatible
• Safe to upgrade immediately

• May include breaking changes
• Migration guide provided
• Old versions supported for 6 months
• Announce 30 days before release

• Semantic versioning strictly followed
• LTS versions designated annually
• Security fixes backported to LTS

1. Announcement — deprecated feature marked in docs
2. Warning — compile-time warning for 2 releases
3. Removal — removed in next major version

If a critical vulnerability is discovered:

1. Immediate — assess scope and impact
2. 24 hours — develop patch, prepare advisory
3. 48 hours — release patched version
4. 72 hours — publish security advisory
5. 1 week — post-mortem published

The wire format includes suite identifiers to support future algorithms:

• New KEM suites can be added (different suite_kem byte)
• New AEAD suites can be added (different suite_aead byte)
• Old suites remain decodable (no silent downgrades)

Migration path for algorithm updates:

1. New version supports both old and new suites
2. Encrypt with new suite, decrypt both
3. Re-encrypt legacy data during maintenance window
4. Eventually deprecate old suite

No independent audit has been conducted.

If you require audited cryptography, consider:

• AWS Encryption SDK
• Google Tink
• libsodium

• Security issues: andre.cordero36@gmail.com
• General questions: GitHub Discussions
• Commercial support: andre.cordero36@outlook.com