DEV Community: gabinotech22-cmyk

AegisLink is now installable — shipping a zero-metadata messenger to Android Closed Testing"

gabinotech22-cmyk — Tue, 07 Jul 2026 18:33:59 +0000

For months this project lived on an emulator on my desk. As of this week, it lives on other people's phones: AegisLink is now in Closed Testing on Google Play — the first build someone who isn't me can actually install.

If you're new here: AegisLink is an open-source, end-to-end encrypted messenger built around one obsession — the server should learn as close to nothing as possible. No account (no email, phone, or name), sealed sender so the relay never sees who a message is from, an embedded Tor path, Double Ratchet + X3DH with a hybrid post-quantum handshake, and a fully encrypted local DB. The earlier posts in this series go deep on each piece.

This post is about the less glamorous part: what it actually takes to ship something like this, honestly.

The Data Safety form is a feature, not a chore

Google Play makes you fill in a "Data Safety" section — enumerate, row by row, exactly what your app collects and shares. For most apps it's an exercise in phrasing data collection as gently as possible.

For AegisLink the honest answer to almost every row is "no data collected, no data shared" — because there genuinely is nothing on the server to declare. No IP logs, no access timestamps, no message sizes, no analytics SDK. Zero metadata stops being a slogan the moment a platform forces you to state, under policy, exactly what you keep.

I dropped 32-bit, and I'll say the floor out loud

I tested on a genuinely low-end device (2GB RAM, 32-bit ARM). The result was honest and useful: identity generation didn't freeze, the crypto ran — but the device swapped itself into uselessness and the OS killed the process repeatedly. That's not a bug in the app; it's a hardware floor.

So the minimum supported spec is now arm64 with ~3GB+ RAM, and I dropped the 32-bit ABIs. I'd rather state the floor plainly than ship a "supported" build that quietly isn't. Most phones from the last few years clear it easily.

The crypto runs in JS — on purpose, with eyes open

The primitives run in JavaScript (Hermes). That's a deliberate trade-off: one auditable codebase over raw KDF speed. It works, but it's a known performance ceiling on low-end hardware, and I'm not going to pretend otherwise.

What's still not done

Being honest is the whole point of doing this in the open: the crypto has not had an independent third-party audit yet. That's a planned next step. Until it happens, every claim here is something to verify in the source — not to take on faith.

Want to break it? Be a tester

That's exactly what Closed Testing is for — real phones, real feedback, before anything gets called done. Two steps:

Join the testers group: https://groups.google.com/g/aegislink-testers
Then install from Play: https://play.google.com/store/apps/details?id=com.aegislink.app

(Order matters — Play only shows "Install" once you're in the group.)

Code, protocol docs, and threat model: https://github.com/gabinotech22-cmyk/AegisLink

If you find something wrong — in the app or the code — that's the best thing you can do for the project. Tell me in the comments.

Shipped this week: the mailbox transport now routes through an embedded Tor client built into the app itself, instead of depending on a separate Orbot install. That removes a real adoption barrier â€” most people won't install a second app just for IP-laye

gabinotech22-cmyk — Sun, 28 Jun 2026 19:31:01 +0000

How AegisLink's handshake survives a quantum computer (X3DH + ML-KEM-768)

gabinotech22-cmyk — Fri, 26 Jun 2026 16:56:56 +0000

In my first post in this series I said the next one would go deep on the
handshake. This is it. If you've ever wondered what actually happens in the
half-second before two strangers can exchange an encrypted message, read on. As
always: this is pre-release, unaudited — the point of writing it down is so
you can check it.

The job of a handshake

Before any messages flow, two devices that have never talked need to agree on a
shared secret — over a relay that sees everything and is assumed hostile. The
relay can drop, reorder, replay, and inject traffic, and it can try to swap the
keys it hands you. The handshake has to produce the same secret on both sides
and detect tampering.

AegisLink uses X3DH (the Signal construction) for this, then adds a
post-quantum layer on top. Let's take them in order.

Part 1: classical X3DH

Each user has a long-term Ed25519 signing key and X25519 Diffie-Hellman
keys. To receive messages, Bob publishes a prekey bundle:

his identity key,
a signed prekey (X25519, signed with his Ed25519 identity key),
optionally a one-time prekey (consumed once, then gone).

Alice fetches Bob's bundle and does the critical first step: she verifies the
Ed25519 signature on the signed prekey before doing anything else. If it
doesn't check out, she aborts. This is what closes the classic
prekey-substitution MITM — a malicious relay can hand Alice a fake prekey, but
it can't forge Bob's signature over it.

Then she runs the Diffie-Hellman ladder:

DH1 = DH(IK_A, SPK_B)
DH2 = DH(EK_A, IK_B)
DH3 = DH(EK_A, SPK_B)
DH4 = DH(EK_A, OPK_B)   // only if a one-time prekey was available

Every DH output is checked against all-zero and rejected if it matches — that's
the guard against low-order / identity-point injection, where an attacker tries
to force a known shared value.

The results are concatenated and run through a KDF:

SK = HKDF-SHA256( IKM = 0xFF×32 ‖ DH1 ‖ DH2 ‖ DH3 [‖ DH4],
                  info = "AegisLinkX3DH" )

Bob, on receipt, mirrors the exact same DH order, the same zero-guards, and the
same HKDF parameters — so both sides land on an identical SK without ever
sending it.

Part 2: making it quantum-resistant

X25519 is great today, but it falls to a large enough quantum computer. And the
threat isn't hypothetical-someday — it's harvest now, decrypt later: an
adversary records your encrypted traffic today and decrypts it in 2035. For a
privacy tool, that's the threat that matters.

So handshake v2 adds ML-KEM-768 (FIPS 203, the standardized Kyber) on
top of X3DH — it does not replace it. Bob publishes one more prekey: a signed
PQ prekey (PQSPK), an ML-KEM-768 public key signed by his identity key, just
like the classical one.

Alice, after finishing classical X3DH:

encapsulates against Bob's PQ prekey: (ct, ss) = ML-KEM-768.encapsulate(PQSPK_B)
appends the 32-byte ML-KEM secret ss to the classical material:

   SK = HKDF-SHA256( IKM = 0xFF×32 ‖ DH1 ‖ DH2 ‖ DH3 [‖ DH4] ‖ ss,
                     info = "AegisLinkPQXDH" )

sends the 1088-byte ML-KEM ciphertext ct inside the sealed message, never as a field the relay can see.

Bob decapsulates ss = ML-KEM-768.decapsulate(ct, PQSPK_secret_B) and derives
the identical SK.

The payoff is the "hybrid" property: breaking a v2 session requires breaking
both X25519 and ML-KEM-768. A future quantum attacker who cracks the elliptic
curve still hits a wall at the lattice, and a classical attacker who finds a flaw
in the (newer, less battle-tested) lattice scheme still hits the curve. You only
lose if both fall.

One subtle bit: implicit rejection

ML-KEM uses implicit rejection (per FIPS 203): feed it a tampered ciphertext and
it doesn't throw an error — it returns a different shared secret. That's by
design. In our handshake it means a tampered ct simply yields a different SK,
and the first real message fails to decrypt, rather than leaking a
distinguishable "decapsulation failed" signal.

Where to look

It's all in the open — the X3DH implementation lives in
mobile/src/crypto/signal/x3dh.ts, and the full spec (with the threat model and
the parts that are still in progress) is in
docs/PROTOCOL.md.

Repo: https://github.com/gabinotech22-cmyk/AegisLink

If you spot a mistake in the construction above — wrong, weak, or just unclear —
that's exactly the feedback I'm after. Next in the series: how the Double Ratchet
takes over once this handshake hands off the first key.

Building a messenger that hides metadata, not just messages

gabinotech22-cmyk — Sun, 21 Jun 2026 09:02:37 +0000

Most "encrypted" apps protect what you say. They do far less about who you
talk to, when, and how often — the metadata. And metadata is often the part
that actually gets people in trouble.

I'm building AegisLink, an open-source end-to-end encrypted messenger, with
that as the central obsession. This is the first post in a build-in-public
series. Everything here is pre-release and has had no independent audit yet,
so treat it as claims to verify — not promises. That's exactly why the code and
protocol are public.

The threat I actually care about

End-to-end encryption is table stakes now. The interesting question is what the
server learns even when it can't read your messages:

who is talking to whom
when, and how often
from which IP, on which device
message and attachment sizes

A server that logs those can reconstruct your entire social graph without ever
decrypting a word. So the design rule for AegisLink's relay is simple: know as
little as possible.

How that translates into code

No account. No email, no phone, no name. Identity is generated on-device (Ed25519 + X25519); your address is a random ID.
Dumb relay. It forwards opaque ciphertext and keeps no logs of who messages whom — no IPs, no access timestamps, no message sizes.
Modern crypto. Double Ratchet + X3DH, with a hybrid post-quantum layer (PQXDH). Private keys never leave the device.
Sealed signaling for calls. WebRTC SDP/ICE is sealed with NaCl box before it reaches the relay, so the server never sees IPs or DTLS fingerprints.
Encrypted at rest. The local DB is encrypted (SQLCipher); backups use an Argon2id-derived key only the user holds.

What's NOT done yet

Being honest is the whole point of doing this in the open:

Transport-level sealed-sender — hiding the sender from the relay process itself — is in active development, not shipped.
No third-party audit has happened. The protocol and threat model are in the repo precisely so people who know more than me can check the work.

Follow along / tear it apart

Code, protocol docs and threat model:
https://github.com/gabinotech22-cmyk/AegisLink

Next post I'll go deep on one piece — probably the X3DH/PQXDH handshake. If
there's something you'd rather I break down, tell me in the comments.