Architecture & Cryptography

This page explains how AENC protects your data. It covers the building blocks it uses, where each one applies, and how they fit together. You will find it useful if you want to check the design yourself.

1. Overview & threat model

AENC's core is an offline encryption tool. You build a self-contained encrypted package on your device and share it over any channel you already use; only the person you picked can open it. Used this way, no AENC server takes part in encryption or decryption, so there is no metadata about who talks to whom for anyone to collect. The Google Play edition adds an optional, opt-in built-in messenger (a paid feature) that delivers those same end-to-end-encrypted packages through our own zero-knowledge relay — the relay only ever handles ciphertext plus minimal delivery metadata and can never read your content or keys (see §13).

What AENC protects. It keeps your content private and genuine while it travels over channels you do not trust. It keeps your private keys secret even if you lose the phone or someone installs a fake copy of the app. What it does not claim. It cannot protect an unlocked device in an attacker's hands, and it does not pretend the client side anti tamper is unbreakable. Those measures only raise the cost of an attack. The real boundary is simple. Your private keys live off the device, on removable media.

2. Cryptographic primitives

All formats use canonical CBOR (CTAP2 canonical). The exact header and envelope bytes serve verbatim as AEAD associated data. Before it runs any crypto, the decoder rebuilds the input and compares it byte for byte, so it rejects anything that is not canonical or has been changed.

3. The end-to-end flow

4. Identities & keys

An identity is a set of key pairs that AENC generates on your device.

• X25519 key pair, for receiving encrypted messages. Senders encrypt to the recipient's public key.
• Ed25519 key pair, for signing messages and self signing your pairing certificate.
• sntrup761 key pair, present only on a Post Quantum identity. You turn this on when you create the identity.
• A random 16 byte device id and a display name. AENC encrypts both at rest and never puts them in a certificate.

You share the public halves as a pairing certificate (§8). The private halves stay in the encrypted .aekey file, which you keep on a removable drive (we recommend this) or on the phone. AENC loads them into memory only while the identity is unlocked (§10).

5. Sealed-sender messages

Each encrypted item is a self contained package (magic AES2 for text, AEF2 for files). "Sealed sender" means AENC encrypts the sender's identity inside the package. Anyone who intercepts it sees no sender, no recipient name, only opaque bytes.

Authentication modes

• SIGNED, an Ed25519 signature that proves to the recipient, and to a third party, who sent it. Use it for contracts and official messages.
• DENIABLE, a shared key MAC. The recipient can check that the sender was someone able to use the key, but they cannot prove to anyone else who wrote it (repudiation). Use it for private conversations.

AENC computes the signature or MAC over a length prefixed transcript. That transcript binds the header, the wrapped key, the sender key, the timestamp and the message, so nothing can be swapped between packages.

6. Hybrid post-quantum mode

A Post Quantum identity carries an extra sntrup761 key. When both sides are PQ, AENC derives the content key from both an X25519 ECDH secret and an sntrup761 encapsulation, and mixes them through HKDF. An attacker has to break both to recover the key. So your message stays private even against a future quantum computer, and it stays at least as strong as X25519 is today.

Types must match. A Classical identity and a Post Quantum identity cannot message each other. You both need the same type. A coloured badge shows which one you have. Blue means Classical, green means Post Quantum.

7. Identity key file at rest (.aekey)

AENC stores your identity as an encrypted .aekey file, protected by your passphrase.

Argon2id is slow and memory hard on purpose (64 MiB, 3 passes). That makes cracking a stolen .aekey expensive, so pick a long, strong passphrase. For the best protection, keep the file on a removable USB drive and pull it out when you are done. You can store it on the phone, but that is less secure.

8. Pairing certificates & verification (.aepair)

To message someone, you import their public pairing certificate, usually by scanning a QR code in person. The certificate signs itself and carries no name.

When you import a certificate, AENC rebuilds the bundle canonically and compares it byte for byte, checks that the advertised cipher suites match the keys inside, and verifies the Ed25519 self signature. It does all of this before it trusts anything. The fingerprint is a domain separated SHA-256 over the whole bundle. Two people compare it in person to stop anyone slipping in the middle at pairing time. A contact stays unverified until you confirm it.

9. Contact book (.aecb)

Your contacts live only in memory during a session. To keep them, AENC saves them as an encrypted .aecb file. It encrypts that file with a subkey from your identity, so only you can open your own contact book, and the book is tied to the identity that made it. The book records whether each contact is verified.

10. Removable-key mode & memory hygiene

• Removable key first. Keep your keys on a USB or SD drive. Plug it in to work, pull it out when you are done. You can keep them on the phone for convenience, but AENC clearly marks that as less secure.
• RAM only when unlocked. AENC holds decrypted private keys in native, page locked (mlock) memory with guard pages, and wipes them when you lock, when the app goes idle, or when you close it.
• Nothing at rest. AENC encrypts captured photos and voice straight from memory. Decrypted content is view only and gets wiped when you leave the screen.
• Emergency wipe securely overwrites and deletes AENC files in a location you choose.

11. Resistance to digital forensics

AENC is built so that examining the phone turns up almost nothing. Forensic tools recover what an app leaves behind, things like databases, caches, logs, thumbnails, and files that were deleted but not overwritten. AENC leaves none of that on purpose.

• Nothing in app storage. AENC keeps no message database, no key cache, no content logs, and no plaintext in its private storage, cache or preferences. There is no history to carve out.
• Keys are off the phone. Private keys live on a removable drive. Take the drive out, and a full forensic image of the phone holds no private key at all. There is simply nothing on the device to extract or crack.
• Plaintext lives only in RAM. While you are unlocked, AENC holds keys and decrypted content in locked (mlock) memory and wipes them on lock, on idle, or when the app closes. It encrypts captured photos and voice straight from memory and never writes them to disk. Decrypted content is view only and gets wiped on exit.
• The channel keeps nothing useful. What travels through a messenger is an opaque .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 has a real chance only if someone grabs the device while it is unlocked, with the USB key inserted and a session open. That is the short window when keys are in memory. Pull the drive and lock when you are done. After that, even with full physical access and professional tools, there is next to nothing to recover.

12. Build variants & network behavior

AENC ships as two builds from one codebase. The crypto core described above is identical in both, byte for byte. They differ only in how you get a licence and whether the app may use the network. Encryption always runs fully on your device. Neither build ever sends your message content, ciphertext, contacts or private keys.

• Offline build (foss). Direct download. It declares no INTERNET permission, so the OS makes any network traffic impossible. No server, no telemetry.
• Play build (play). Google Play Store. It declares INTERNET because Google Play Billing and our licence check need it, so it reaches the fixed set of endpoints below.

Endpoints the Play build contacts

Bottom line. All of that traffic uses HTTPS with TLS. The offline build sends nothing at all. In neither build does any plaintext message, contact, or private key ever leave the device; the messenger relay carries only ciphertext it cannot read, plus the minimal metadata needed to deliver it. The Play listing's Data Safety declaration reflects the online build's traffic.

13. The built-in messenger (relay, ratchet, push)

The Google Play edition adds an optional, paid, opt-in messenger. Its design goal: add convenient online delivery without weakening the offline guarantees above. The message a recipient opens is still the same standalone sealed .aenc that decrypts only with their removable key — online delivery is a separable layer wrapped around it, never a replacement for it.

Layering — the .aenc stays innermost

A sent message is built as: inner = sealed .aenc(text/pointer), then wrapped by a Double Ratchet envelope for transport. The recipient unwraps the ratchet layer and is left with the standalone .aenc, which the offline engine then opens with the identity key exactly as in §5. Strip the ratchet entirely and the inner .aenc still decrypts — the two layers share no keys. So even a total compromise of the ratchet/transport yields only ciphertext that still needs the removable .aekey.

Forward-secret addressing (no stable "who ↔ whom")

• Session setup: an X3DH + PQXDH handshake (classical X25519 DH terms folded with a CRYSTALS-Kyber-768 shared secret) establishes a shared root, using the recipient's published, signed prekeys.
• Double Ratchet with header encryption: message keys and mailbox addresses both ratchet forward. Each message goes to a fresh, pseudorandom mailbox id derived from the ratcheting header key, so the relay sees uncorrelated addresses — it cannot reconstruct who is talking to whom from the addresses alone. Skipped / out-of-order messages are handled with a bounded look-ahead.
• Server-blind prekey directory: a contact fetches your prekey bundle from the relay under an opaque id (b64url(sha256(your Ed25519 key))); the bundle itself is stored encrypted under a key derived from your public key, so the relay holds only an irreversible id + ciphertext it cannot read or enumerate. Bundles are self-signed and pinned to the trusted contact key, so the relay cannot substitute or forge one.

The relay

A deliberately "dumb" Node store-and-forward spool: deposit puts a ciphertext blob at an opaque mailbox, fetch returns and deletes it (delete-on-fetch; short safety TTL for never-collected messages). Large files stream to disk as encrypted blobs, resumable, then deleted on receipt. There are no accounts and no id/IP request logging. Anonymous writes are gated by a lightweight proof-of-work to blunt flooding. It never holds plaintext, keys, or a readable identity.

Push & honest metadata limits

To wake a killed app, the relay can send a contentless Firebase (FCM) push — a bare "open and fetch" signal, no sender or content. This is opt-out; with push off, delivery falls back to in-app polling. The honest residual metadata cost of online delivery: your IP, message timing and size, and — while push is on — a stable device push token the relay/Google use to reach you. Rotating mailbox addresses remove address-level linkage; IP/timing and push-token linkage are mitigated only by turning push off or, on the roadmap, by an onion-routing transport. Content, keys, and identity remain protected throughout.