AMA Cryptography is a quantum-resistant cryptographic protection system released under the Apache License 2.0 as free and open-source software. As of v2.0, all production cryptographic primitives are implemented natively in C with zero runtime cryptographic dependencies. Security is our highest priority. We take all vulnerabilities seriously and appreciate responsible disclosure from the security research community.

We actively maintain and provide security updates for the following versions:

AMA Cryptography implements defense-in-depth with multiple independent security layers — four core cryptographic operations supported by key derivation and timestamping:

1. SHA3-256 Content Hashing (NIST FIPS 202)
2. HMAC-SHA3-256 Authentication (RFC 2104)
3. Ed25519 Digital Signatures (RFC 8032, C11 atomics hardened)
4. ML-DSA-65 Quantum-Resistant Signatures (NIST FIPS 204)
5. HKDF-SHA3-256 Key Derivation (RFC 5869, NIST SP 800-108)
6. RFC 3161 Trusted Timestamps

• AES-256-GCM Authenticated Encryption (NIST SP 800-38D)
• ML-KEM-1024 Key Encapsulation (NIST FIPS 203)
• SLH-DSA-SHA2-256f and SLH-DSA-SHAKE-128s Hash-Based Signatures (NIST FIPS 205)
• Adaptive Cryptographic Posture System (runtime threat-level response)
• Hybrid KEM Combiner (IND-CCA2 binding construction per Bindel et al.)

Throughput is a continuously-improving axis, not a ceiling. On x86-64 AVX2 AMA's checked-in benchmark artifacts and generated reports provide the only supported throughput claims; avoid quoting relative speedups unless the source artifact and host class are named. Recent work (see CHANGELOG.md from v2.1 onward) added 4-way Keccak batching, Ed25519 signed-window combs, merged-layer ML-DSA NTT, and Ed25519 verify via Shamir/Straus joint scalar multiplication with a width-5 wNAF — roughly doubling verify throughput.

Ed25519 verify dominates wall-clock time in three protocol families that AMA consumers run at scale:

• X.509 certificate-chain validation (TLS handshake, code-signing). A typical chain is 3–4 certificates deep; each certificate signature is one Ed25519 verify. Doubling per-verify throughput halves the CPU budget per chain validation, which on a busy gateway is the difference between handling N and 2N concurrent handshakes per core.
• Noise Protocol Framework handshakes (WireGuard, Lightning, Nym). The XX, IK and IKpsk2 patterns each do at least one Ed25519 verify of the responder's static key per handshake; mixed-PQ patterns (e.g. Noise_XXhfs_25519+ML-KEM-1024_*) keep the same verify on the classical leg. Faster verify shortens the Diffie-Hellman-bound handshake critical path.
• MLS (RFC 9420) group operations. Each Welcome / Commit message carries one or more Ed25519 signatures over the GroupContext and KeyPackages. In a 1000-member group an Add/Remove can require verifying O(log N) signatures along the ratchet-tree path; verify speed sets the floor on group-rekey latency.

The change is purely algorithmic — same group-element math, no new external dependency, no new dispatch slot — and is gated behind AMA_ED25519_VERIFY_SHAMIR (default ON) and AMA_ED25519_VERIFY_WINDOW (default 5) so a single recompile reverts to the prior layout if a consumer needs the old throughput envelope for deterministic regression purposes.

The deliberate choices that constitute AMA's security posture — zero external cryptographic dependencies, in-tree constant-time implementations audited under INVARIANT-12, and a vendored build-from-source supply chain — auto-bound peak ops/sec against libraries that lean on AVX-512 or hand-tuned assembly across 500 k+ LoC of audit surface. Readers who value raw speed over supply-chain minimalism are unlikely to be the target audience for this library; readers who need auditable, small-surface post-quantum primitives with headroom to keep improving should find the trade-off acceptable. Measured ops/sec numbers are in benchmark-report.md and benchmarks/README.md — any claim to the contrary elsewhere in the repository should be treated as aspirational and reported as a documentation bug.

If you discover a security vulnerability in AMA Cryptography, please report it responsibly:

DO NOT open a public GitHub issue for security vulnerabilities.

Instead, please use one of the following private channels:

1. Preferred — GitHub Private Vulnerability Reporting: Open a private advisory. GitHub encrypts the report in transit and storage; no PGP key management is required on either side.
2. Email fallback: steel.sa.llc@gmail.com with subject [SECURITY] AMA Cryptography Vulnerability Report.

Include in your report:

• Detailed description of the vulnerability
• Steps to reproduce the issue
• Potential impact assessment
• Proof-of-concept code (if applicable)
• Suggested remediation (if available)
• Your contact information for follow-up

We consider the following to be security vulnerabilities worthy of immediate attention:

Critical:

• Cryptographic primitive failures (hash collision, signature forgery)
• Key extraction or recovery attacks
• Authentication bypass
• Arbitrary code execution
• Privilege escalation
• Cryptographic oracle attacks

High:

• Side-channel attacks (timing, power analysis)
• Denial of service affecting cryptographic operations
• Information disclosure of sensitive cryptographic material
• Dependency vulnerabilities in cryptographic libraries

Medium:

• Input validation issues leading to unexpected behavior
• Insufficient entropy in key generation
• Weak random number generation
• Implementation deviations from cryptographic standards

Low:

• Documentation inconsistencies affecting security
• Missing security headers or best practices
• Informational security improvements

The following are generally not considered security vulnerabilities:

• Theoretical attacks requiring impractical computational resources (e.g., 2^128 operations)
• Issues in third-party dependencies (report to upstream maintainers)
• Social engineering attacks
• Physical access attacks on user systems
• Issues requiring user misconfiguration or ignoring documentation
• Performance or availability issues without security impact
• Missing features (use GitHub Issues instead)

We are committed to responding to security reports promptly:

Initial Response: Acknowledgment of receipt and initial severity assessment Status Update: Progress reports and estimated resolution timeline Resolution Target: Expected timeframe for patch release (may vary based on complexity)

We follow coordinated disclosure principles:

1. Report Received: We acknowledge receipt within the timeframes above
2. Validation: We validate the vulnerability and assess severity
3. Fix Development: We develop and test a security patch
4. Advisory Preparation: We prepare a security advisory with CVE (if applicable)
5. Coordinated Release: We coordinate disclosure timing with the reporter
6. Public Disclosure: We publish the advisory and release the patch

Typical disclosure timeline: 90 days from initial report, or earlier if:

• A fix is available and tested
• The vulnerability is being actively exploited
• Other parties have independently discovered the issue
• The reporter and maintainers mutually agree

Security updates are released as follows:

• Critical vulnerabilities: Emergency patch release within 7 days
• High vulnerabilities: Patch in next minor version (within 30 days)
• Medium vulnerabilities: Patch in next scheduled release
• Low vulnerabilities: Addressed in regular development cycle

Security advisories are published:

• GitHub Security Advisories (https://github.com/Steel-SecAdv-LLC/AMA-Cryptography/security/advisories)
• Release notes with [SECURITY] tag
• Email notification to users who have starred the repository (when critical)

We deeply appreciate security researchers who help keep AMA Cryptography secure. Reporters who follow responsible disclosure will be:

• Credited in the security advisory (unless anonymity is requested)
• Acknowledged in the CHANGELOG and release notes
• Thanked publicly on our GitHub repository
• Recognized in our Hall of Fame for significant contributions

We do not currently offer a bug bounty program but may consider recognition rewards for exceptional discoveries.

Users deploying AMA Cryptography in production should:

• REQUIRED: Store master secrets in FIPS 140-2 Level 3+ HSMs for production
• REQUIRED: Implement key rotation every 90 days
• REQUIRED: Use hardware security modules (AWS CloudHSM, YubiKey, etc.)
• NEVER: Store private keys in plain text or version control
• NEVER: Reuse keys across different Omni-Code packages

• REQUIRED: Build native C library (cmake -B build -DAMA_USE_NATIVE_PQC=ON && cmake --build build)
• All production cryptographic primitives (SHA3, HKDF, Ed25519, AES-256-GCM, ML-DSA-65, ML-KEM-1024, SLH-DSA, X25519, ChaCha20-Poly1305, Argon2id, secp256k1) are native C — no external cryptographic dependencies required
• Optional: numpy/scipy for 3R monitoring, PyKCS11 for HSM

• REQUIRED: Build native PQC C library (cmake -B build -DAMA_USE_NATIVE_PQC=ON && cmake --build build)
• REQUIRED: Enable all cryptographic layers (no fallbacks in production)
• REQUIRED: Use RFC 3161 trusted timestamp authorities
• RECOMMENDED: Use multiple TSAs for redundancy
• RECOMMENDED: Verify all signatures before trusting package contents

• NOTE: v2.0 has zero core cryptographic dependencies — all primitives are native C
• REQUIRED: Keep optional dependencies up to date (numpy, scipy, pynacl if used)
• REQUIRED: Enable Dependabot for automated security updates
• RECOMMENDED: Pin dependency versions for reproducible builds
• RECOMMENDED: Verify package signatures from PyPI

• REQUIRED: Log all cryptographic operations for audit trails
• REQUIRED: Monitor for signature verification failures
• REQUIRED: Alert on quantum library unavailability
• RECOMMENDED: Implement rate limiting for signature operations
• RECOMMENDED: Regular security audits of deployment configuration

The integrity check verifies that an installed wheel's .py files have not been tampered with after build. It is not a supply-chain identity check (PyPI's existing PGP / sigstore mechanisms cover that) and it does not prove anything about a malicious build pipeline — both the digest and the signing key are produced by the same build that produced the code being signed. The contract is:

1. The wheel build computes SHA3-256 over the package's .py files, generates an ephemeral, per-build Ed25519 key by default (or uses AMA_INTEGRITY_SIGNING_SEED_HEX in release CI), signs the digest, embeds the signature + the public verification key as a Python literal in ama_cryptography/_integrity_signature.py, then discards the private key before publishing the wheel.
2. At import, _self_test._verify_integrity() re-hashes the .py files, loads the embedded (pubkey, signature) pair, and calls ama_ed25519_verify from the in-tree C kernel (via ctypes — INVARIANT-1 forbids a PyCA dependency). Mismatch transitions the module to the ERROR state and refuses every cryptographic operation.

There is no long-lived signing key in developer builds. Each default build generates, signs once, and discards. Release CI may compile the expected public key into the native library with CMake's AMA_INTEGRITY_TRUST_ANCHOR_PUBKEY_HEX option and set AMA_INTEGRITY_REQUIRE_TRUST_ANCHOR=1; then the build signer refuses to emit an artefact whose derived public key does not match the native anchor, and the import-time verifier fails closed if the embedded public key is not that anchor. This gives release packaging a stable trust-anchor gate without adding any external crypto dependency or trusting mutable Python source for the anchor.

python -m ama_cryptography.integrity --update is gated behind AMA_BUILD_PIPELINE=1. Users who modify .py files after install must rebuild the wheel — running --update locally would silently re-bless tampered code and defeat the tamper-detection contract.

Both halves ship together in the AArch64-completeness PR (2026-05):

1. --update gate — python -m ama_cryptography.integrity --update requires AMA_BUILD_PIPELINE=1 in the environment. Outside that gate the command exits 2 with a remediation message. See ama_cryptography/integrity.py.
2. Signing pipeline — python -m ama_cryptography._build_sign (invoked by the build pipeline, e.g. setup.py post-build hook / CMake post-install step / wheel CI workflow) generates an ephemeral Ed25519 keypair (or uses AMA_INTEGRITY_SIGNING_SEED_HEX in release CI) via the in-tree ama_ed25519_keypair C symbol (INVARIANT-1: no PyCA dependency), checks the resulting public key against the C-compiled trust anchor when one is present, signs the SHA3-256 digest with ama_ed25519_sign, writes ama_cryptography/_integrity_signature.py with the embedded pubkey
   • signature + digest, and discards the private key before exit. See ama_cryptography/_build_sign.py.
3. Import-time verifier — _self_test._verify_integrity() calls _verify_signed_integrity() first. When the signature artefact is present (the normal post-wheel-build state), it recomputes the digest, reads any native trust anchor via ama_integrity_trust_anchor_pubkey_hex(), calls ama_ed25519_verify via ctypes with the embedded pubkey and signature, and accepts only on a positive verify plus trust-anchor match when configured. When the artefact is absent (editable installs, source checkouts, wheels built without AMA_BUILD_PIPELINE=1), the behaviour depends on AMA_INTEGRITY_REQUIRE_TRUST_ANCHOR:
   • Unset (developer / editable / source-checkout path): the module falls back to digest-only verification against _integrity_digest.txt with a logged WARNING. Developer ergonomics do not require a full wheel build on every edit; packagers still see the missing signature in CI logs.
   • =1 (release path): the module refuses to fall back and transitions to ERROR state — release wheels MUST ship the Ed25519-signed artefact or every crypto call is rejected. This makes a forgotten AMA_BUILD_PIPELINE=1 in the release pipeline a hard failure instead of a silent posture downgrade.

End-to-end smoke test (from the AArch64-completeness PR's CI):

AMA_BUILD_PIPELINE=1 python -m ama_cryptography.integrity --update --sign
python -m ama_cryptography.integrity --verify   # → "OK (signed integrity verified, ...)"
# Now edit a .py file and re-import:
python -c "import ama_cryptography; ama_cryptography._self_test._run_self_tests()"
# → ERROR state, all crypto operations refused

Release-anchor smoke test:

export AMA_BUILD_PIPELINE=1
export AMA_INTEGRITY_REQUIRE_TRUST_ANCHOR=1
export AMA_INTEGRITY_TRUST_ANCHOR_PUBKEY_HEX=<32-byte expected Ed25519 pubkey hex>
export AMA_INTEGRITY_SIGNING_SEED_HEX=<32-byte release signing seed hex>
python -m ama_cryptography.integrity --update --sign
AMA_INTEGRITY_REQUIRE_TRUST_ANCHOR=1 python -m ama_cryptography.integrity --verify

The release job normally supplies the trust anchor via the compiled AMA_INTEGRITY_TRUST_ANCHOR_PUBKEY_HEX CMake option; the environment form above is a reproducible local equivalent used by tests to prove the strict path rejects unanchored artefacts.

Released wheels and FIPS-validated deployments should set AMA_FIPS_STRICT=1 so a missing backend cannot silently degrade the approved-algorithm self-test set:

• Unset (default, developer / docs / CI matrix builds): when a KAT cannot run because its backend is unavailable (e.g. SPHINCS+ was not built into the C library), the POST runner logs a WARNING, records the skip with passed=None in module_self_test_results(), and continues. Skip is NOT a pass — consumers filtering for "everything passed" must compare passed is True.
• =1 (release / FIPS-validated path): a skipped KAT is escalated to a hard POST failure. The module enters ERROR state and refuses every cryptographic operation until the missing backend is built and the process restarted. This makes a forgotten cmake -DAMA_USE_NATIVE_PQC=ON in the release build a visible failure rather than a silent posture downgrade.

The strict-mode flag applies uniformly to every KAT (SHA3-256, HMAC-SHA3-256, AES-256-GCM, ML-KEM-1024, ML-DSA-65, SLH-DSA, SLH-DSA-SHAKE-128s, Ed25519) and the constant-time timing oracle.

secure_memzero refuses to operate when the native C zero-on-erase backend is unavailable; the Python multi-pass loop is opt-in via AMA_ALLOW_PYTHON_MEMZERO=1 (development / test) or AMA_SPHINX_BUILD=1 / SPHINX_BUILD=1 (docs builds). Production deployments should never need the opt-in because INVARIANT-7 already refuses to import the library without the native HMAC/HKDF backend, so the native memzero is also present. The gate is defence-in-depth against a partial-build state where the constant-time primitives are linked but the secure-memzero symbol is not.

AESGCMProvider.encrypt() reserves its per-key counter slot atomically via an inter-process file lock before any nonce is generated or AEAD is invoked. Concurrent processes sharing the same AES-GCM key reserve disjoint slots — a previous race window where two processes could load the same baseline and write back max(N+a, N+b) instead of N+a+b is closed. Ephemeral mode (configure_ephemeral(True) or ephemeral=True in the constructor) bypasses disk I/O for hermetic test runs; in that mode the multi-process race surface is the same as the historical single-process design and callers MUST partition keys per-process. If the host cannot provide a working fcntl.flock (POSIX) or msvcrt.locking (Windows) primitive, encryption fails closed instead of logging and continuing with degraded nonce safety.

The persisted counter path no longer keeps a dirty counter or batching interval: every successful reservation writes the slot+1 high-water mark atomically, so there is no deferred flush state to lose on crash.

*Ed25519 and X25519 are vulnerable to sufficiently large quantum computers, but ML-DSA-65 provides quantum-resistant backup.

We will deprecate cryptographic algorithms when:

• Practical attacks reduce security below 112-bit classical security
• NIST or other authoritative bodies recommend deprecation
• Quantum computers pose imminent threat to classical algorithms
• More efficient quantum-resistant alternatives become available

30 days notice will be provided before deprecating any algorithm, with migration guides and backwards compatibility support.

The library ships an optional VAES + VPCLMULQDQ AES-256-GCM kernel (PR A, 2026-04) behind runtime CPUID + XCR0 gating (ama_cpuid_has_vaes_aesgcm()). The VAES + VPCLMULQDQ AES-GCM path targets YMM (256-bit), not ZMM: Zen 3+ / Ice Lake+ CPUs execute these without the AVX-512 ZMM frequency penalty documented for Skylake-SP / Cascade Lake. Cloud VM variance on shared hosts is still the dominant noise source; published throughput numbers are from bare-metal runs, not CI. Hosts without VAES — or any non-x86-64 host — automatically route through the AVX2 AES-NI + PCLMULQDQ path shipped in #253 / #254 / #260 / #261, which remains the regression baseline tracked in benchmarks/baseline.json.

AMA Cryptography has undergone internal security analysis documented in this file. We welcome:

• Independent security audits from qualified cryptographers
• Academic review of our mathematical proofs
• Penetration testing of the implementation
• Code reviews focusing on cryptographic correctness

Please contact us at steel.sa.llc@gmail.com to coordinate security audit efforts.

AMA Cryptography is designed to comply with:

• NIST FIPS 202 - SHA-3 Standard (SHA3-256, SHAKE128, SHAKE256)
• NIST FIPS 203 - Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM / Kyber)
• NIST FIPS 204 - Module-Lattice-Based Digital Signature Standard (ML-DSA / Dilithium)
• NIST FIPS 205 - Stateless Hash-Based Digital Signature Standard (SLH-DSA / SPHINCS+)
• NIST SP 800-38D - Recommendation for Block Cipher Modes: GCM (AES-256-GCM)
• NIST SP 800-108 - Recommendation for Key Derivation Using Pseudorandom Functions
• NIST SP 800-57 - Recommendation for Key Management
• RFC 2104 - HMAC: Keyed-Hashing for Message Authentication
• RFC 5869 - HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
• RFC 8032 - Edwards-Curve Digital Signature Algorithm (EdDSA)
• RFC 3161 - Internet X.509 Public Key Infrastructure Time-Stamp Protocol

Non-compliance with these standards should be reported as a high-severity security issue.

Preferred channel: GitHub Private Vulnerability Reporting Email fallback: steel.sa.llc@gmail.com security.txt: .well-known/security.txt (RFC 9116) Response Time: 24-48 hours for critical issues Organization: Steel Security Advisors LLC

• docs/DESIGN_NOTES.md — Security arguments for original constructions (double-helix engine, adaptive posture, composition protocol)
• THREAT_MODEL.md — System threat model and risk assessment
• CRYPTOGRAPHY.md — Cryptographic algorithm overview
• ARCHITECTURE.md — System architecture and invariants
• CONSTANT_TIME_VERIFICATION.md — Timing-side-channel validation
• .github/INVARIANTS.md — Library invariants (canonical)

Copyright 2025-2026 Steel Security Advisors LLC. Licensed under Apache License 2.0.