Nyra security: how the encryption works

Published 31 August 2026. Nyra is in development and not yet released. This page describes the design as built so far, unfinished parts included.

The short version

Nyra is an end-to-end encrypted messenger. Messages are encrypted on your device and can only be decrypted on the recipient's device. The Nyra server relays sealed envelopes between accounts and holds no keys that could open them. Not because we promise to look away, but because the math gives the server nothing to read.

The threat model in plain words: we assume the server could be seized, subpoenaed, or hacked, and we design so that even then the attacker gets ciphertext and a small, honestly documented amount of metadata. What we cannot defend against: malware on your own phone, someone reading over your shoulder, or a contact screenshotting your messages. No messenger can.

Key agreement: X3DH explained simply

Before two people can exchange encrypted messages, their devices need to agree on a shared secret without the server ever learning it. Nyra uses X3DH, the Extended Triple Diffie-Hellman key agreement, the same construction Signal designed and published.

Here is the idea without the algebra. Every account publishes a small bundle of public keys to the server: a long-term identity key, a signed medium-term key, and a stack of one-time keys. When you message someone for the first time, your device fetches their bundle and performs several Diffie-Hellman computations that mix your keys with theirs. The result is a shared secret that only the two devices can derive. The server handed over public keys, which are safe to publish by definition, and learned nothing about the secret.

The "triple" part matters: mixing long-term, medium-term, and one-time keys gives both sides assurance about who they are talking to, and means even the very first message uses keys that are discarded after one use.

The Double Ratchet and forward secrecy

X3DH gets a conversation started. The Double Ratchet keeps it safe over time. After the initial secret is agreed, every message is encrypted with a fresh key, and the key that encrypted it is deleted immediately after use. Two mechanisms turn the keys over, which is where the "double" comes from.

A symmetric ratchet steps forward with every message: each key is derived from the previous one through a one-way function, so keys can be computed forward but never backward. A Diffie-Hellman ratchet turns whenever the conversation changes direction: each reply mixes in brand new random key material, which heals the session even if some earlier state leaked.

Together they give you two properties worth knowing by name. Forward secrecy: a key stolen today cannot decrypt messages sent yesterday, because yesterday's keys no longer exist. Post-compromise security: if an attacker briefly captures your session state, the DH ratchet locks them out once the conversation continues. These properties genuinely separate protocols: Signal has both, while Session removed forward secrecy, a widely criticized decision. Our comparison page goes through this fairly.

Audited primitives, unaudited app: the honest split

Nyra does not implement its own cryptography from scratch. The primitives, meaning the low-level building blocks such as X25519 key exchange, Ed25519 signatures, and the ChaCha20-Poly1305 cipher, come from the @noble family of cryptographic libraries, which are minimal, open source, and independently audited.

Here is the part we will not blur: Nyra itself has not been independently audited. Composing audited pieces into a protocol and an app is exactly where subtle bugs live. An independent audit of Nyra is planned before launch, and we will publish the results whatever they say. Until it is done, do not use Nyra, or any unaudited software, for anything your safety depends on.

What the server actually does

The server's job is deliberately boring. It stores public key bundles, accepts sealed envelopes, queues them for the recipient, and deletes them on delivery or after the 7-day queue TTL, whichever comes first. Group messages are opaque envelopes too, so the server holds no group member lists. The app's expiry defaults are described on the disappearing messages page.

A relay still sees some things, and pretending otherwise is how privacy tools lose trust. The server sees your username and public keys, your IP at connection time (kept briefly for rate limiting), the fact that an envelope of roughly some size moved from one account to another, and how many envelopes wait in your queue. The full two-column table of what the server can and cannot see is on the home page, and the metadata page explains why we document this instead of promising zero metadata.

What protects your data at rest

Encryption in transit is only half the job; the other half is the phone in your pocket. Everything Nyra stores on your device is sealed under a key that is itself wrapped by a key living in your phone's hardware keychain. That keychain key is unavailable while the phone is locked, never leaves the device, and is excluded from device backups. When Nyra goes to the background, the unwrapped key is zeroed from memory.

The app lock PIN is hashed with Argon2id, a memory-hard function built to make guessing expensive. And the lock accepts a second PIN, the dead switch, which wipes the app on the spot, plus an optional auto-erase after too many failed attempts, with exponential backoff between tries. Individual chats can also require the lock to open, or be hidden from the main list entirely behind it. If you need to move phones, the whole account exports as a single passphrase-encrypted backup file; the wrong passphrase opens nothing.

Media: sealed the same way

Photos, files and voice messages get a fresh random key per file on your device. The file is encrypted with that key, the ciphertext goes to the relay, and the key travels inside the end-to-end encrypted message. The server stores a blob it cannot open and never sees the key. On your device, media is stored encrypted at rest like everything else.

Registration friction: proof of work

Because Nyra asks for no phone number and no email, there is nothing scarce to burn when someone scripts mass account creation. So registration includes a small proof-of-work challenge: your device solves a puzzle that takes a moment on a phone and becomes expensive at bot scale. Labeled honestly, proof of work is spam defense, not a security or anonymity feature. It raises the cost of abuse without asking you for identity.

Verification: same sky on both screens

Encryption stops anyone in the middle from reading your messages, but you still want to confirm nobody in the middle is pretending to be your contact. Nyra derives a small constellation from the keys of both parties, and each of you sees it in the chat. Compare it out of band, over a channel the server does not control: in person, on a video call, over another messenger. Same sky on both screens means the connection is secure. It is the same idea as Signal's safety numbers, drawn as something two humans can compare at a glance.

Known limits and open questions

Bluntly:

• Metadata cannot be fully eliminated. A server that delivers messages must know where to deliver them. We minimize and document, we do not erase.
• Nyra is young. The protocol composition is unaudited, the app is in development, and young software has bugs. Signal has earned its maturity over years in a way no new messenger, ours included, can claim.
• Sealed sender is still in development. Today the server can see which account an envelope came from and where it goes. We are building sealed sender to strip the sender from the envelope, so a seized server could not map who talks to whom. Until it ships, we say the server sees both ends.
• Your device is the boundary. A compromised phone defeats any messenger. Lose your recovery phrase and the account is gone forever, and nobody can restore it, including us.

Reporting a vulnerability

We want reports. If you find a weakness in Nyra's protocol, code, or infrastructure, tell us; credit is yours if you want it. A dedicated security address is being set up before launch and will be listed here and in /.well-known/security.txt. That file is already live and points to this page. Until then, reply to any waitlist email from us and mark it security; it reaches the same small team that writes the code.

No bounty numbers we cannot back, no certifications we do not hold, no security theater. Reports get read, fixes get shipped, findings get disclosed once users are safe.

Questions people ask