Security

Security and cryptography.

How Whispyr protects your conversations, described as it is actually implemented today, including the limits.

Last reviewed: September 2026

On this page

At a glance

  • Whispyr is serverless. Message content travels directly between devices over local Wi-Fi, Bluetooth or Apple Multipeer Connectivity and is never uploaded to a Whispyr server.
  • Direct chats are end-to-end encrypted with ChaCha20-Poly1305. Each session uses fresh X25519 keys, which gives per-session forward secrecy.
  • Whispyr is not a Double Ratchet design. There is no per-message ratchet and no post-compromise security.
  • Trust is established on first use. Authenticity is confirmed by comparing safety numbers in person.
  • Whispyr has not yet been independently audited. The protocol is Whispyr’s own design and has been reviewed internally only. We welcome external review.

How a chat is encrypted

When two devices start a session, each side generates a fresh ephemeral X25519 key pair for that session. The session key is derived with HKDF-SHA256 from the X25519 shared secret, a fixed salt and both participants’ handles. Long-term keys are not used to derive the session key on current builds.

The ephemeral public key is carried in a handshake signed with the sender’s long-term Ed25519 identity key, so an attacker on the path cannot substitute their own key without that identity key.

Message content is sealed with ChaCha20-Poly1305. The associated data binds every ciphertext to the sender’s handle and to the message type, so a ciphertext cannot be replayed as a different kind of message.

Session lifetime

Ephemeral keys and session keys live only in memory. They are never written to the Keychain or to disk, and are discarded when the session ends, is re-keyed, or the app exits. A session key expires after 30 minutes and the next message triggers a new handshake; the previous key is kept for a 30-second grace period. To survive brief link drops, the responding device may reuse its existing ephemeral key during a re-handshake, so in practice the forward-secrecy window can be longer than 30 minutes.

Older app versions

When one device runs an old version of Whispyr, the session falls back to a key derived from long-term keys, without forward secrecy. This exists only for compatibility and goes away as old versions age out.

Cryptographic primitives

On iPhone, iPad and Mac, Whispyr builds on Apple CryptoKit primitives and does not invent new ones.

PurposePrimitive
Key agreementX25519
Signatures and identityEd25519
Message encryptionChaCha20-Poly1305
Link encryption (Bluetooth, local network)AES-256-GCM
Key derivationHKDF-SHA256
Key confirmationHMAC-SHA256
Encrypted backupsPBKDF2-HMAC-SHA256 (600,000 iterations), ChaCha20-Poly1305

The Bluetooth link layer and the backup key derivation use small HKDF and PBKDF2 helpers written in-house on top of CryptoKit’s HMAC-SHA256. Like the rest of the protocol, they have been reviewed internally but not audited externally.

Bluetooth and local-network links

Over Bluetooth Low Energy, the encrypted chat session runs on top of an additional authenticated link. Each side sends an ephemeral X25519 key signed with its Ed25519 identity, both derive directional AES-256-GCM keys with HKDF-SHA256, and a key-confirmation message must verify before the connection is used. Handshake attempts are rate-limited.

Links over the local network use the same kind of AES-256-GCM link encryption, with separate keys and counters for each direction. In both cases the chat itself stays end-to-end encrypted inside the link.

What is and isn’t encrypted

  • Direct chats are end-to-end encrypted as described above.
  • Profile information you choose to show, such as your name, handle and profile photo, is shared with nearby devices during discovery and the handshake, before a chat is encrypted.
  • Spaces between iPhones travel over Apple’s encrypted Multipeer Connectivity sessions.
  • Emergency broadcasts are intentionally not encrypted, so that anyone nearby can read them. They are signed with a key carried in the message itself, which proves the text was not changed in transit but not who sent it. Treat them as unverified.
  • Metadata such as which devices are near each other, when they communicate and how much is sent is visible to observers of the radio and local network.

Trust and verification

Whispyr uses trust on first use. When you first talk to someone, Whispyr records their long-term identity key for that contact.

Safety numbers are derived from both identity keys and let two people confirm in person that no one is in the middle. Automatic checks against the recorded key and key-change alerts exist, but their coverage currently varies by platform and app version. Do not treat the absence of a warning as proof that a key did not change; comparing safety numbers is the authoritative check.

The first exchange with a new contact is not authenticated until you compare safety numbers. An attacker who is actively on the path at that exact moment could interpose.

Key storage

Your identity keys are generated on your device and never leave it. There is no key escrow and no backdoor.

On iPhone, iPad and Mac, keys are stored in the Keychain as device-only items: they are never synced to iCloud Keychain and cannot be restored onto another device, and they are readable only after the device has been unlocked once since restarting. They are not stored in the Secure Enclave. Keychain items can outlive an uninstall; use Settings → Clear All Data in the app to remove them.

Data on your device

Your chats, contacts in Whispyr, Spaces, stories and events are stored on your device and are not synced to any Whispyr-operated cloud. Before a photo is sent, Whispyr removes GPS, EXIF and other capture metadata on your device.

Photos, voice messages and files you send or receive are kept in the app’s documents folder, which can be part of your own iCloud or computer backup of the device. That backup is under your Apple account, not Whispyr’s.

Backups are optional and created only by you. The backup file is encrypted on your device with a passphrase you choose and saved where you decide. Whispyr has no copy and cannot recover a lost passphrase. A restored device receives new encryption keys.

Analytics and crash reports

Anonymous analytics are opt-in and off by default. Nothing is sent until you turn them on, and you can turn them off at any time.

If you opt in, Whispyr sends event names from a fixed list (for example, that the app was opened or a message was sent), a random install identifier, a random record ID, the app version and build number, and a timestamp. Crash reports are included only when you have opted in. They contain a stack trace with file paths removed, plus your iOS version, device model and region setting.

Whispyr never sends message content, attachments, names, handles, contacts, your location or advertising identifiers. The app contains no third-party analytics or advertising SDKs.

What Whispyr does not protect against

  • A compromised device. Malware, a jailbroken operating system or someone with access to your unlocked phone can read messages before encryption and after decryption.
  • Session key compromise. Forward secrecy is per session. If a session key leaks, that whole session is exposed, and the protocol does not self-heal.
  • Downgrades with old app versions. Sessions with very old versions fall back to weaker, non-forward-secret encryption.
  • Metadata and traffic analysis. Whispyr protects content, not the fact that devices are nearby and communicating.
  • Well-resourced state-level attackers. Whispyr is not designed to withstand them.
  • Denial of service. Radio signals can be jammed or flooded. Whispyr makes no availability guarantee.

Reporting a vulnerability

We take security reports seriously and will not pursue legal action against good-faith researchers who follow coordinated disclosure.

Email support@getwhispyr.app with the subject “Security Report”. Please include the affected platform and app version, a description, steps to reproduce and the impact you expect. We aim to acknowledge reports within 5 business days and to provide a triage assessment within 10 business days. With your permission, we will credit you when a fix ships.

Please give us a reasonable chance to fix an issue before disclosing it publicly, and do not test against other people’s devices without their consent.