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 is an offline encryption tool, not a messenger. It never sends your content anywhere. 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. No AENC server takes part in encryption or decryption, so there is no metadata about who talks to whom, or when, for anyone to collect.

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, and it covers only licensing and Google Play platform plumbing. The offline build sends nothing at all. In neither build does any message content, ciphertext, contact, or private key ever leave the device. The Play listing's Data Safety declaration reflects the online build's traffic.