Security Whitepaper

Last updated: 12 July 2026

This document describes how PairNook protects your data — precisely, and including the parts that are deliberately not end-to-end encrypted. We believe a privacy product should be able to explain itself.

1. Threat model in one paragraph

The content of your conversations, photos, voice notes, shared passwords, and documents is end-to-end encrypted: through the protocol, the server cannot read your messages in transit or at rest — it operates on ciphertext. There is one deliberate exception in the current release: to make account recovery zero-effort, an encrypted copy of your recovery key is escrowed server-side (§4). A fully compromised server — or a malicious operator — could combine that escrowed key with your encrypted key backup to access message history. We treat this as a disclosed usability trade-off, not fine print; §4 explains it and the hardening path. Day-to-day, what the server can see is the metadata needed to run the service, plus the Life-planning items described in §7. We do not defend against a compromised end device: if someone controls your unlocked phone, they can read what you can read.

2. Protocol: Matrix with Olm/Megolm

PairNook's messaging is built on the open Matrix protocol, using its audited end-to-end encryption stack:

Olm — a Double Ratchet implementation (in the Signal lineage) used for one-to-one device sessions, providing forward secrecy: every message advances the ratchet, so past messages stay secret even if a current key leaks.
Megolm — the room ratchet used for the couple's encrypted room: message keys advance per message, and the sender's Megolm session keys are distributed to your partner's devices only over Olm-encrypted channels.
The cryptography is implemented by vodozemac, the Rust implementation of Olm/Megolm maintained by the Matrix core team — used natively via matrix-rust-sdk on iOS and Android, and as the WASM build via matrix-js-sdk on the web app. We do not write our own primitives.

3. Keys and devices

Every device you sign in on generates its own identity key pair: Curve25519 for key agreement and Ed25519 for signing. Private keys are generated on the device and never leave it in plaintext.
Message (Megolm) keys are shared device-to-device inside Olm-encrypted envelopes. The server routes these envelopes but cannot open them.
With one exception — the recovery key, which is sent to the server for escrow (§4) — no message key or identity private key transits our servers in plaintext.

4. Key backup and the recovery key

Losing a phone shouldn't mean losing your history — but backup must not weaken the encryption. PairNook uses Matrix server-side key backup:

Your devices continuously back up their Megolm message keys to the server, encrypted under your recovery key. The server stores this backup but cannot decrypt it.
For seamless multi-device recovery, a copy of your recovery key is additionally escrowed server-side, wrapped with AES-256-GCM under a secret that we — the operator — hold, so a freshly signed-in device can restore history without you re-typing keys. The escrow secret lives in the server's protected runtime configuration (and durably in AWS SSM Parameter Store as an encrypted parameter, in two regions — Mumbai, plus a disaster-recovery copy in Singapore), separate from the database that holds the blobs — and it is deliberately excluded from our backup archives.

The honest trade-off: because we hold both the escrow secret and the escrowed blobs, a fully compromised server — or a malicious operator — could unwrap your recovery key and use it to decrypt the key backup, i.e. your message history. This is a deliberate, disclosed usability trade-off of the current release: recovery works even if you lose every device and remember nothing. The encryption of messages in transit between your devices is unaffected. On the roadmap: user-held recovery keys and an opt-out of escrow, which close this gap at the cost of you safeguarding the key yourself. And if you delete your account, backup and escrow blobs are deleted with it.

5. Encrypted notification previews

Push notifications are a classic E2EE leak — most apps either show nothing or let the server read the preview. PairNook does neither:

The sender's device seals the notification preview per recipient device using ECIES-v1: an ephemeral X25519 key agreement, HKDF-SHA256 key derivation, and ChaCha20-Poly1305 authenticated encryption.
The server stores and forwards ciphertext only.
The preview is decrypted on your device at delivery time — in the iOS Notification Service Extension, or an Android background task — so the lock-screen preview is rendered locally from ciphertext.

6. Passwords and documents

Shared passwords and documents are transported and stored as ordinary encrypted room events — the same Olm/Megolm machinery as messages. The server is blind to them.

7. What is NOT end-to-end encrypted — by design

Life planning and activity items are readable by the server. To-dos, chores, groceries, reminders, important dates, calendar entries, expense records, notes, date plans, shared links and the watchlist, travel lists, photo captions, game boards and scores, and your answers to the daily Question for Two are stored server-side in readable form so that the server can schedule and send reminders and notifications when your apps are closed, and coalesce updates between partners. This is a deliberate, documented trade-off — not an oversight. If something is sensitive, put it in chat, not in a to-do title or a daily answer.

Also visible to the server, as with any messaging service: account data (email, display name), which devices you have, when messages were sent and to which room (but not their content), push tokens, and IP-level connection metadata.

8. What the server sees — summary

	Server sees
Messages, reactions	Ciphertext only
Photos / videos / voice notes	Encrypted blobs only
Passwords & documents	Ciphertext only
Notification previews	Ciphertext only (sealed per device)
Key backup	Encrypted under your recovery key — but an escrowed copy of that key is recoverable by the operator (§4)
Life & activity items (to-dos, notes, date plans, links, travel, photo captions, game state, daily-question answers)	Plaintext, by design (§7)
Account & routing metadata	Plaintext (required to operate)

9. Transport and infrastructure

TLS on every client connection — all traffic between your devices and PairNook uses TLS 1.2+ (TLS 1.3 preferred), with certificates automatically issued and rotated. Server-side services communicate on an isolated private network within a single host.
Single-tenant, self-hosted infrastructure — PairNook runs its own Matrix homeserver (Synapse) and backend on dedicated infrastructure in AWS Mumbai (ap-south-1). There is no shared multi-tenant SaaS database, no federation with other Matrix servers, and no third-party message-processing service.
No third-party analytics or tracking SDKs anywhere in the stack.

10. Responsible disclosure

Found a vulnerability? Please email support@pairnook.com with details. We commit to acknowledging reports quickly and fixing verified issues as a priority. Please give us reasonable time to remediate before public disclosure.