Zisty Security Overview

Last updated: November 2, 2026 · iOS 5.8.x

This is for people with some technical background who want to know why they should trust Zisty. It covers the cryptography, what the server can and cannot see, where data lives, and what we do not protect against. Every item was checked against the current code.

1. What you have to trust

• Not the server for content: it only ever holds ciphertext and no key that opens a message.
• The App Store app to do what this page says. The code is not public and has not been audited by a third party; section 17 lists what you can check yourself.
• iOS: the Keychain, file protection, randomness and Apple CryptoKit. The app ships no third-party crypto, analytics or advertising code.
• We (the operator) and the network see some metadata, such as times, sizes and IP addresses; sections 13 and 14 list it.

2. Identity

On first launch the phone makes three long-term keys:

• X25519 for key agreement;
• Ed25519 for signing;
• ML-KEM-768 (FIPS 203), stored as its 64-byte seed.

They live in the Keychain as AfterFirstUnlockThisDeviceOnly: they are never in iCloud Keychain and never in a backup restored elsewhere.

Your fingerprint is the first 128 bits of SHA-256(Ed25519 public key). That is your whole identity: no account, phone number, email or contact upload. A card whose fingerprint does not match its signing key is dropped.

3. Adding and verifying friends

• In person: signed cards are exchanged over the nearby link and both people compare a 30-digit safety number. It is SHA-256 over the two signing keys in byte order; the first 12 bytes give six 5-digit groups, about 96 bits. Such friends are marked as verified in person.
• Invite link (https://zisty.app/i#XXXX-XXXX):
  • the 8-character code is valid for 24 hours and works once;
  • it sits after the #, so browsers never send it to a web server;
  • the friend's app redeems the code at the mailbox server for your signed card, then drops a signed (not encrypted) friend request in your public inbox. The inbox token is SHA-256("projecty-public-inbox-v1|" + fingerprint).
• The invite step trusts the server: a malicious server could hand out someone else's card for your code. Friends added this way are marked "added remotely, not verified in person". Comparing the safety number later rules this out.
• Your card (nickname, the three public keys, app version, no picture) is on the server only while "Allow remote friend requests" is on.

4. One-to-one messages

4.1 Pairwise key

HKDF-SHA256(X25519(mine, theirs), salt = both fingerprints sorted and joined, info = "projecty-pairwise-v1"), 32 bytes.

It seeds the ratchet, the outer seal, the mailbox tokens and the nearby tokens.

4.2 Double Ratchet

Content uses a Signal-style Double Ratchet without a prekey server:

• the larger fingerprint initiates;
• the responder's static X25519 key is its first ratchet key.

The KDFs:

• root KDF: HKDF-SHA256(salt = root, IKM = DH, info = "projecty-ratchet-v1"), 64 bytes (the new root, then the new chain);
• chain KDF: message key = HMAC-SHA256(chain, 0x01), next chain = HMAC-SHA256(chain, 0x02);
• messages are sealed with ChaCha20-Poly1305. The whole header (ratchet key, previous chain length, number, version and every ML-KEM field) is authenticated data.

Out-of-order and replayed messages:

• up to 200 skipped keys per chain, 400 stored;
• replays are recognised and dropped.

Used keys are deleted.

4.3 Post-quantum

Between iOS builds from 3.1 on, sessions are hybrid X25519 + ML-KEM-768:

• Root: the initiator encapsulates to the responder's card key, and root = HKDF-SHA256(pairwise ‖ ML-KEM secret, info = "projecty-ratchet-pq-v1"). The 1088-byte ciphertext rides in the initiator's headers until the responder has replied.
• Every step (header v4): each message carries the sender's current ephemeral ML-KEM key. Each DH step also encapsulates a fresh secret to the peer's latest key, and both go into HKDF-SHA256(salt = root, IKM = DH ‖ ML-KEM, info = "projecty-ratchet-v2").

Recorded traffic stays closed even if X25519 falls to a quantum computer, and post-compromise recovery holds against such an attacker too. Version downgrades (v4 → v3, v3 → v2) are rejected.

4.4 When forward secrecy starts

From the peer's first reply on, every message key comes from ephemeral keys and is deleted after use. Messages sent before that reply are protected only by the peer's static X25519 and ML-KEM keys; a later leak of those keys would expose them. This is the cost of having no prekey server.

4.5 What goes through the ratchet

For a post-quantum friend, everything sealed goes through the ratchet: messages, posts, profiles, receipts and call signalling. The exceptions are:

• attachment chunks and chunk requests (already sealed with a per-file key that arrives inside a ratcheted manifest);
• nearby handshakes, acks and wakes;
• friend requests and accepts;
• session resets.

Every envelope's ciphertext is signed with the sender's Ed25519 key.

5. Mailbox and outer seal

• Outer seal: the whole envelope (sender, kind, signature, inner ciphertext) is sealed again with the static pairwise key, so the server sees neither who sent it nor what kind it is.
• Mailbox token: HKDF-SHA256(pairwise, info = "projecty-mailbox-v1|" + recipient fingerprint), one per friend and direction. It cannot be linked to anyone without the pairwise key.
• Recipients register their tokens on their authenticated connection. Deposits are unauthenticated: an HTTPS POST holding only a token and ciphertext.
• Mail is deleted as soon as the recipient acknowledges it, otherwise after 5 days (2 days if the recipient has never connected). Of several queued copies of the same state (a profile, a read receipt), only the newest is kept, grouped by an opaque tag.

The outer seal uses the static key and has no forward secrecy. It hides metadata only; the content inside is ratcheted.

6. Groups

• Each group has a 256-bit group key made by the owner. It is sent with the full roster to each member over that member's ratcheted (post-quantum) one-to-one channel.
• A group message is sealed with ChaCha20-Poly1305 under the group key, signed by its sender, then outer-sealed per member.
• Key rotation:
  • at once when someone is added, removed or leaves; people removed or gone read nothing sent afterwards;
  • daily, by the owner, on the next message;
  • phones delete group keys older than 6 days.

Groups have no per-message ratchet: one key opens everything sent while it was current, so group forward secrecy is measured in days.

7. Pictures, videos and files

• Small pictures and voice clips travel inside the message.
• Large files:
  • a random 256-bit file key, 1 MB chunks, ChaCha20-Poly1305 per chunk;
  • the nonce is the chunk index and the authenticated data is blobID/index, so chunks cannot be reordered or swapped;
  • the key, file name, thumbnail and access key travel in the encrypted message.
• The server keeps:
  • the ciphertext chunks;
  • the uploader's fingerprint, the size and the recipient count;
  • SHA-256 of the access key.
  Downloads need only the access key, no identity. A file is deleted once every recipient has it, at most after 5 days.
• Photos lose their location and other metadata before sending; orientation is kept.

8. Calls

• Offer and answer go through the ratchet, each carrying a 32-byte random secret.
• Key derivation:
  • master = HKDF-SHA256(offer ‖ answer, info = "projecty-call-v1");
  • from the master: per-direction audio and video keys and a 16-byte route token.
• Media packets are sealed with ChaCha20-Poly1305. The nonce is direction plus sequence number; the header is authenticated.
• Paths:
  • direct UDP on the same local network;
  • otherwise the server's UDP relay;
  • failing that, the existing encrypted connection.
  The server sees the route token, sizes and timing.
• Calls do not appear in the Phone app's recents.

9. Nearby link

• Nearby messages go over Bonjour and TCP (Wi-Fi or peer-to-peer Wi-Fi), with no server. Bluetooth carries only the handshake and wake-ups.
• Advertisements carry no name, only a daily 8-byte token per friend: HKDF-SHA256(pairwise, info = "bonjour" + date + advertiser fingerprint). Only that friend can tell whose phone it is, and the two ends of one friendship advertise different tokens.

The link has no TLS and no outer seal. A device on the same network that joins the link can see:
· both fingerprints;
· the nickname in the handshake card;
· message kinds and sizes.
It cannot see content.

10. Data on the phone

• Everything the app writes is encrypted:
  • ChaCha20-Poly1305 under a 256-bit storage key;
  • the key is in the Keychain (ThisDeviceOnly);
  • the data directory is excluded from iCloud and computer backups.
  Files are readable after the first unlock, so messages can arrive while the phone is locked.
• Retention:
  • per chat: burn after reading (30 s), 1, 3, 5 or 9 hours from when a message is seen, on both phones;
  • unseen messages: 5 days at most;
  • posts: 1, 3, 5 or 9 days.
• App Lock uses Face ID; the app never sees biometric data.
• Device logs contain no message content. They leave the phone only when you tap upload, and the server keeps them for 30 days.

11. Vault

• The vault has its own X25519 key pair. The private key is wrapped with PBKDF2-HMAC-SHA256 (600,000 iterations, 16-byte salt) and ChaCha20-Poly1305. The password needs at least 6 characters.
• Each item has a random file key, sealed with its metadata (name, thumbnail) to the vault's public key using HPKE (X25519, HKDF-SHA256, ChaCha20-Poly1305).
• Adding needs no password; listing and opening do. There is no recovery without the password, for anyone.

12. Moving phones, recovery kit, remote wipe

• Move:
  • the new phone shows a QR code with an ephemeral X25519 key and a one-time token;
  • the old phone connects locally and streams everything, sealed chunk by chunk with a key derived from both ephemeral keys;
  • after the import is confirmed, the old phone erases itself. An identity lives on one phone.
• Recovery kit:
  • holds the identity keys, group keys, friends and groups, no messages;
  • sealed with PBKDF2-HMAC-SHA256 (600,000 iterations) and ChaCha20-Poly1305; the passphrase needs at least 8 characters;
  • you keep it wherever you like. Whoever has the kit and its passphrase can be you.
• Remote wipe works only from friends you allowed in advance (in that chat's info page).

13. What the server knows

Stored	For how long
Each phone's fingerprint, signing key, first and last connection	Deleted after 60 days without a connection
Push tokens (messages and calls)	Until replaced or withdrawn
The mailbox tokens each phone registers	Updated as friends change
Waiting mail: recipient fingerprint, token, ciphertext, size, time	Until picked up, 5 days at most
Attachment chunks, uploader fingerprint, size, access-key hash	Until every recipient has them, 5 days at most
Card (only with remote requests on): nickname, public keys, app version	Until turned off
Invite code → fingerprint	24 hours, single use
Diagnostic logs you upload (no content)	30 days

The server does not know:

• the content of messages, files or calls;
• file names, group names or pictures;
• who deposited a message (deposits are unauthenticated);
• what kind of message it is.

It never tells anyone who is online.

It can infer:

• roughly how many friends someone has, from the number of tokens they register;
• the size and time of each message;
• IP addresses at connection and deposit (held in memory for rate limiting, never written to the database or logs).

An operator watching closely could guess, from IPs and timing, which two phones talk to each other. Every relayed messenger has this metadata problem; we do not add cover traffic.

• Push:
  • the text is fixed ("you have a new message" or "incoming call"), with no sender or content;
  • a call push also carries the mailbox token and, when small enough, the encrypted offer;
  • Apple sees the push token and the time.
• Server logs hold no content and no IP addresses; identities normally show as "-".
• Backups:
  • a daily database copy with all mail bodies removed, kept 7 days;
  • the Tokyo standby receives a live replica, including waiting ciphertext; data deleted on the primary can remain there for about 2 hours.

14. Network

• The primary server (Singapore) has two entrances:
  • mail.projecty.vip through Cloudflare, with the system's normal certificate check;
  • a direct IP, trusted only through a pinned server key, with no certificate authority.
  The standby in Tokyo answers "standby" until it is promoted.
• On the domain path, Cloudflare terminates TLS and sees what the server sees: tokens, ciphertext, sizes and IPs, never content.
• After connecting, the phone signs a 32-byte server challenge with its Ed25519 key. Uploads use the session token issued after that.

15. Algorithms

Use	Algorithm
Key agreement	X25519; ML-KEM-768 (hybrid)
Signatures	Ed25519
Symmetric encryption	ChaCha20-Poly1305 (256-bit keys)
Key derivation	HKDF-SHA256; HMAC-SHA256 message chains
Vault	HPKE (X25519 · HKDF-SHA256 · ChaCha20-Poly1305)
Password-based keys	PBKDF2-HMAC-SHA256, 600,000 iterations
Fingerprints, safety numbers, tokens	SHA-256 / HKDF-SHA256
Implementation	Apple CryptoKit, CommonCrypto (PBKDF2); no third-party crypto

16. Known limits

• The code is not public and has not had a third-party audit.
• Metadata: sizes, times and IPs are visible to the server and to Cloudflare.
• A friend added remotely relies on the server's card until you compare safety numbers.
• Groups have no per-message ratchet; forward secrecy is measured in days.
• One-to-one messages sent before the peer's first reply rest on the peer's long-term keys.
• The nearby link has no outer seal: devices on the same network can see fingerprints, nicknames and sizes.
• Retention is an agreement between the two apps; it cannot stop screenshots, photos of the screen or a modified client.
• The vault and the recovery kit are only as strong as their passwords.
• Android is in maintenance: no post-quantum sessions and no calls. Sessions with Android friends are classic X25519 Double Ratchet.
• Encryption does not help once someone controls your unlocked phone.

17. How to check

• Test vectors: protocol-vectors.json. Both the iOS and the Android test suites check these byte for byte. They use only test keys made from fixed seeds and cover:
  • the pairwise key, safety number and mailbox tokens;
  • signatures, AEAD boxes and attachment chunks;
  • every step of a classic, a hybrid and a per-step post-quantum Double Ratchet session;
  • the envelope encoding.
  An independent implementation of the formulas above should match them exactly.
• In the app: the chat info page shows the safety number to compare in person, and whether the session is post-quantum and forward secret.
• On the wire: you will see only TLS to the two entrances above, and ciphertext on the nearby link.
• Problems: report@projecty.vip.