Skip to content

Cryptographic disclosures

Support is specific to an implementation, encoding, build, and execution context. The generated support reference and its exact JSON identify the signed v0.5.5 native Linux release. ARM64 is the primary reference and AMD64 is a separately named alternate. Neither catalog establishes an installed fleet's readiness or OCI image availability.

CPU compatibility and release history

The v0.5.5 release uses portable ML-KEM and ML-DSA primitive implementations. Its packaged ARM baseline gate executes primitive selftests and real TLS handshakes under CPU emulation without the SHA-3 extension. This gate does not replace checking your actual host: verify the supplied package and run its bounded --check-crypto-runtime command on the target CPU before installation. The command checks primitive operations; configured TLS identity, trust roots, entitlement, and observed traffic remain separate readiness checks.

The earlier v0.5.1 ARM64 agent can terminate with SIGILL during primitive initialization or periodic readiness checks on ARMv8 CPUs without SHA-3, including AWS Graviton2. Do not deploy those v0.5.1 ARM64 packages or that ARM64 image on those CPUs. The v0.5.2 tag contains the portable source correction, but its release stopped before native or OCI publication in the predecessor verification installer step. Earlier tags and artifacts were not replaced. The published v0.5.3 release included the portable primitive correction, but its default TLS bootstrap could fail from a read-only working directory, and the standard service sandbox blocked required state-directory writes. The v0.5.4 tag contained the service corrections but did not publish after its packaged systemd validation failed. Those earlier tags and artifacts remain unchanged.

The v0.5.5 package checks exercise bundled TLS startup from a read-only working directory as both root and a service user, plus state-file writes under the packaged systemd unit in disposable test containers. These checks do not establish an installed host's configuration or live traffic outcome. Use the verified v0.5.5 materials supplied through authorized onboarding.

TLS gateway

The explicit rustls/AWS-LC adapter prepares schema-v1 TLS policies. The X25519MLKEM768 group provides hybrid TLS 1.3 key establishment. Certificate and client authentication follow the configured certificate algorithms and trust stores; hybrid key exchange does not make those signatures post-quantum.

The focused gateway tests exercise 30 valid cipher-suite/group combinations with real loopback TLS handshakes and matching RSA/ECDSA identities. Negative checks cover incompatible identities, classical peers under a hybrid-required policy, missing trust roots, and invalid policies. These are test results for the released implementation. They do not establish an independent audit or module certification.

Primitive API

The release-bundled primitive factories expose X25519, ML-KEM-768, AES-256-GCM, ChaCha20-Poly1305, Ed25519, ML-DSA-65, and SHA-256. Their complete operation sets and exact provider versions are in the generated catalog.

ML-KEM uses separate key-generation, encapsulation, and decapsulation methods. The current typed encoding fixes public/private/ciphertext/shared-secret lengths at 1184/2400/1088/32 bytes. It checks public encoding and the private key's embedded public-key hash before use. Invalid ciphertext follows the maintained library's implicit rejection and returns a different secret; callers must use an authenticated protocol and a reviewed purpose-bound KDF. The old DH-shaped KEM method and unfinished standalone hybrid helper fail closed.

Owned typed KEM secret wrappers zeroize their storage on drop and redact Debug. They do not claim every foreign-library temporary is erased or all process memory is locked. No blanket side-channel, power-analysis, or formal-verification claim is made for the product.

Ed25519 uses detached signature bytes. ML-DSA-65 preserves its existing signed-message encoding; it is not a detached signature API. Store algorithm, exact implementation version, and encoding with material. Historical Kyber and Dilithium names are ambiguous: only explicitly matching final-FIPS v2 encodings may resolve to the new canonical IDs. Round-3 material needs its historical implementation and a separately reviewed migration.

The tests include RFC 7748 X25519 vectors, authenticated associated-data negatives, library-boundary encoding interoperability, and 30 published NIST ACVP ML-KEM-768 decapsulation/key-check cases pinned to a source revision. Standards conformance tests do not imply a FIPS module validation.

Messenger and library suites

Native Messenger clients have their own protocol, provider, prekey, and retained session-key requirements. Their use of a familiar suite label does not establish compatibility with Aegis's standalone composite-signature/nested-encryption library envelopes. See the Messenger support boundary.

Security reports

Use the project's published security-reporting channel. This reference does not announce an audit completion, bounty amount, formal proof, or promised response SLA. Release verification retains the project's signature, provenance, and audit checks; catalog availability does not replace those controls.