A technical description of how AENC protects your data: the primitives it uses, where each one is applied, and how the pieces fit together. Written for readers who want to verify the design.
AENC is an offline encryption tool, not a messenger. It never transmits your content. You produce a self-contained encrypted package on your device and share it over any channel you already use; only the intended recipient can open it. There are no AENC servers involved in encryption or decryption, so there is no metadata (who talks to whom, when) for anyone to collect.
What AENC defends: confidentiality and authenticity of your content in transit over untrusted channels; the secrecy of your private keys even if the phone is lost or a malicious copy of the app is installed. What it does not claim: to protect an unlocked device in an attacker's hands, or to make client-side anti-tamper unbreakable — those are cost-increasing measures layered under the real boundary, which is that the private keys live off-device on removable media.
| Primitive | Role in AENC |
|---|---|
| X25519 (ECDH) | Key agreement between sender and recipient for every encrypted message. |
| AES-256-GCM | Authenticated encryption (AEAD) of the message payload and of the identity file at rest. |
| Ed25519 | Digital signatures: message authentication (SIGNED mode) and the self-signature on a pairing certificate. |
| sntrup761 (Streamlined NTRU Prime) | Post-quantum KEM, combined with X25519 in the optional hybrid mode. |
| HKDF-SHA-256 | Key derivation: turns key-agreement shared secrets into per-message AEAD keys. |
| Argon2id | Memory-hard password hashing (64 MiB / 3 passes / 1 lane) protecting the identity file with your passphrase. |
| SHA-256 | Pairing fingerprints and domain-separated hashing. |
All formats are canonical CBOR (CTAP2 canonical). The exact header/envelope bytes are used verbatim as AEAD associated data, and decoders re-encode and byte-compare to reject any non-canonical or tampered input before performing cryptographic operations.
An identity is a set of key pairs generated on-device:
The public halves are shared as a pairing certificate (§8). The private halves stay in the encrypted
.aekey file (kept on a removable drive — recommended — or on the phone) and are only loaded into
memory while the identity is unlocked (§10).
Each encrypted item is a self-contained package (magic AES2 for text, AEF2 for
files). "Sealed sender" means the sender's identity is encrypted inside the package — an interceptor
sees no sender, no recipient name, only opaque bytes.
The signature/MAC is computed over a length-prefixed transcript that binds the header, the wrapped key, the sender key, the timestamp and the message — so nothing can be swapped between packages.
A Post-Quantum identity carries an extra sntrup761 key. When both sides are PQ, the content key is derived from both an X25519 ECDH secret and an sntrup761 encapsulation, combined through HKDF. An attacker must break both to recover the key — so the message stays confidential even against a future quantum computer, while remaining at least as strong as X25519 today.
Types must match. A Classical identity and a Post-Quantum identity cannot message each other — both parties must be the same type. The type is shown by a coloured badge (blue = Classical, green = Post-Quantum).
Your identity is stored as an encrypted .aekey file, protected by your passphrase.
Argon2id is deliberately slow and memory-hard (64 MiB / 3 passes), which makes brute-forcing a stolen
.aekey expensive — so choose a long, strong passphrase. For the best protection, keep the file on
a removable USB drive and remove it when you're done; storing it on the phone is possible but less secure.
To message someone you import their public pairing certificate, usually by scanning a QR code in person. The certificate is self-signed and carries no name.
On import, AENC re-encodes the bundle canonically and byte-compares it, checks that the advertised cipher suites match the keys present, and verifies the Ed25519 self-signature — all before trusting anything. The fingerprint (a domain-separated SHA-256 over the whole bundle) is what two people compare in person to defeat a man-in-the-middle at pairing time. A contact stays unverified until you confirm it.
Your contacts live only in memory during a session. To keep them, they are saved as an encrypted
.aecb file, encrypted with a subkey derived from your identity — so only you can open your own
contact book, and it is bound to the same identity that created it. Verified/unverified status is stored per
contact inside the book.
mlock) memory with guard pages, and zeroised when you lock, when the app is idle, or on close.AENC is designed so that examining the phone yields almost nothing. Forensic tools recover what an app leaves behind — databases, caches, logs, thumbnails, deleted-but-not-overwritten files. AENC deliberately leaves none of that:
mlock) memory and zeroised on lock, on idle, or when the app closes. Captured photos and
voice are encrypted straight from memory and never written to disk; decrypted content is view-only and wiped
on exit; screenshots are blocked on the decrypt screen..aenc blob. Seizing the transport, the server or the recipient's inbox yields ciphertext only.The one weak moment — and how to avoid it. Forensics only has a realistic chance if the device is captured unlocked, with the USB key inserted and a session open — the brief window when keys are in memory. Remove the drive and lock when you're done; then, even with full physical access and professional tooling, there is practically nothing to recover.