Security · How it actually works

Security you can reason about.
No magic words. Just the math.

Every privacy app says it's secure. This page is the opposite of a slogan, it spells out exactly which math protects what, draws a hard line between your messages and your call media, and tells you plainly what the server can and can't see. If a section sounds modest, that's on purpose. We'd rather under-promise than overclaim.

The stack

What protects every message.

Your messages and their attachments are end-to-end encrypted. Only the devices in a conversation ever hold the keys.

Post-quantum key exchange
Keys are established with ML-KEM-1024 (Kyber-1024), the NIST-standardized post-quantum KEM. A conversation set up today stays private even against a future quantum computer recording it now to crack later.
Double Ratchet, per message
Session keys move forward with every message. Compromising one key doesn't unlock the messages before or after it, that's forward secrecy, applied to each chat continuously.
AES-256-GCM sealed content
The message body is sealed with authenticated AES-256-GCM before it ever leaves your phone. Tampered or swapped ciphertext fails its integrity tag and is rejected, not silently shown.
End-to-end media
Photos, video, voice notes and documents are encrypted on-device with a fresh per-file AES-256-GCM key; only ciphertext is uploaded. The server stores an opaque blob it cannot read, in testing, a server-held file simply fails to decrypt. That failure is the proof.
The server

Honest about what the relay sees.

A relay has to move encrypted bytes from one device to another. Here is exactly where that line sits, including the metadata we can't hide yet.

The server can see

  • Encrypted bytes queued for delivery, never plaintext
  • The recipient node ID a sealed packet is routed to, so it can be delivered
  • Coarse online/offline presence, unless you hide it
  • Ephemeral system logs that are volatile and not retained

The server can't see

  • Your messages, media, or call audio and video, all sealed end to end
  • Your contact list, it lives on your device, not on the server
  • Your name, phone, or email, we never asked for any of them
  • Your private keys, they never leave your phone

What a data request would find

  • Encrypted bytes that are unrecoverable without the recipient's private key
  • No real-world identity bound to any account
  • No retained access logs to correlate a person against
Calls

Where messages and calls differ.

We won't blur two different technologies to sound more impressive. Here's the precise truth.

Setting up a call (the ring, the agreement on keys) runs through the same post-quantum-secured signaling channel as your chats.

The live audio and video themselves travel as a real-time WebRTC media stream, encrypted in transit with DTLS-SRTP, the standard encryption for real-time media. So your messages get the post-quantum ratchet; your call media gets WebRTC's encrypted transport. Two different jobs, two appropriate tools, stated plainly rather than marketed as one.

On your device

Protection past the encryption.

Encryption guards the wire. These guard the phone in your hand, and the moment someone else is holding it.

App lock & biometric
Gate the whole app behind a fingerprint or face. A lockscreen privacy cover hides message content from notifications and the app switcher while you're away.
Decoy & panic mode
A separate decoy PIN opens a believable second app, fake chats, fake call log, your real conversations nowhere in sight. A panic action can wipe on the spot. Plausible deniability when it counts.
Hidden chats vault
PIN-locked chats vanish from your main list behind a disguised label of your choosing, so a glance at your phone reveals nothing, and even the vault itself doesn't look like one.
Metadata hygiene
Screenshot protection, GPS and EXIF data stripped from photos before they send, ghost mode, and full control over your last-seen visibility. Less trail, by default.
Notifications

A wake-up, not a window.

Push is the one place an encrypted app can quietly leak. Here's our posture.

The readable text you see in a notification is decrypted on your own device, it isn't carried through the push in the clear.

And push delivery is optional. You can run in a strict mode with no push token registered at all, trading instant alerts for the smallest possible delivery footprint. Either way: no advertising ID, and no analytics SDK riding alongside the app.

Honest limits

What we don't claim.

Nothing here is unhackable, and we won't pretend otherwise. These are the edges, stated up front.

The relay can see that two node IDs exchanged sealed packets
To deliver a message, the server must know which node ID it's queued for. It never learns what was said, only that two IDs traded encrypted bytes. Sender-anonymizing delivery ("sealed sender") is on the roadmap, not shipped. Treat routing metadata as visible; treat content as not.
Signed voice notes verify the device, not a courtroom
A 1-to-1 voice note carries a cryptographic seal so your contact's app can confirm it really came from their device and wasn't swapped or AI-faked. Group signing and court-grade non-repudiation are future work, the current seal is receiver-side verification, not legal proof.
Public broadcast channels are public by design
Anything posted to an open, broadcast-style channel is readable by anyone who can see that channel, there's no single recipient to seal it to. The end-to-end-encrypted part is your private 1-to-1 chats, groups, and private channels.
Lose your device, lose the account
There's no server-side recovery loop, by design, because a recovery loop is also an attacker's way in. Use the in-app encrypted session export to keep a backup in storage you control. No magic reset, no password-reset email, no back door.
We're still hardening
WingPost is in active security hardening ahead of a wider launch. We add protections continuously and would rather tell you where the edges are than paper over them. Found something? The disclosure line below is real and read by a human.
"

If you've found a weakness, we want to hear it before anyone else does. Reach the security team directly at security@anadevyra.com. Report in good faith, give us a reasonable window to fix it, and we'll work it with you, no lawyers, no theatrics. The full terms are on our responsible-disclosure page.

AnA Devyra Security