Threat model & cryptography

The promise: Secure Notes is end-to-end encrypted by default. Every note — text, voice, attachment, metadata — is encrypted on your device with AES-256-GCM before it touches disk or iCloud. The encryption key is derived on-device from your master password via PBKDF2-HMAC-SHA-256 with 100,000 iterations and a 16-byte random salt unique per vault.

The key never leaves your device. The publisher (PixelPort LLC) has no access to it, no ability to recover it, and no mechanism to bypass it. Apple, the platform vendor, receives encrypted blobs over CloudKit and stores them in your iCloud private database — but the keys to decrypt those blobs live only on your devices.

The fallback is a 12-word recovery seed generated at first launch (BIP-39 word list, 128 bits of entropy). The user is the only party who holds it. We do not store, transmit, or escrow it. If you lose both the master password and the seed, the data is unrecoverable. That is the cost of real encryption and we will not engineer a backdoor around it.

• Server breach at the publisher. We hold no keys and no plaintext. A full database breach of our infrastructure yields ciphertext only.
• Server breach at Apple / iCloud. CloudKit sees ciphertext at rest. Even without Advanced Data Protection, our payload is unreadable.
• Compelled disclosure (legal process served on the publisher). We can return ciphertext. We can return our source code. We cannot return your plaintext because we do not have the means to produce it.
• Subpoena served on Apple. Apple can produce your encrypted CloudKit records. The records remain unreadable without your master password.
• Lost or stolen device with locked screen. Device passcode + Secure Enclave + iOS data protection mean the notes vault stays encrypted at rest. Without your passcode an attacker cannot decrypt anything.
• Shoulder-surfing on the lock screen. Notification previews for Secure Notes are off by default; locked notes never surface previews.
• Cross-app data leaks. The app holds no third-party SDKs, no ad trackers, no analytics on content, no telemetry that includes user data.

Honesty matters. End-to-end encryption is not a magic shield. The following attacks are out of scope, and we say so explicitly so you can plan around them:

• Compelled biometric or passcode unlock. If you unlock the app, or are forced to unlock the app, the content is in cleartext on screen. This is a user-control problem, not a cryptography problem. In jurisdictions where biometric unlock can be legally compelled but passcode cannot, disable Face ID before crossing borders.
• Malware running with your privileges on a jailbroken device. Our memory protections are iOS-platform defaults. A jailbroken device can read app memory. Do not jailbreak your phone if you store sensitive notes on it.
• Screen recording and screenshots. iOS does not let apps fully prevent screen recording by another app or by a determined user. We mark sensitive screens with UIScreen.captureDidChangeNotification handling where available, but you should assume an attacker with physical control of an unlocked phone can exfiltrate plaintext.
• Coercion attacks (the “$5 wrench”). The XKCD attack is real. If someone with physical leverage demands your password, no cryptography saves you. Geographic separation of seed and device + plausible deniability folders are mitigations; they are not full solutions.
• Endpoint compromise (keylogger, malicious accessibility). Standard iOS does not permit keyloggers, but configuration profiles installed under MDM can intercept input. Do not install MDM profiles from sources you do not control.
• Traffic analysis on iCloud sync. Even with encrypted payload, the metadata (you sync, when, how much) is observable. We do not engineer anti-traffic-analysis padding.
• Quantum attacks against AES-256.Grover's algorithm reduces AES-256 effective strength to 2^128 — still infeasible, but watch this space long-term. We will rotate to a post-quantum AEAD when one is standardized for production use.

The exact algorithms in use, named so you can verify them:

• Symmetric cipher: AES-256 in Galois/Counter Mode (GCM). NIST FIPS-197 + SP 800-38D. Authenticated encryption, no separate MAC needed.
• Key derivation: PBKDF2 with HMAC-SHA-256, 100,000 iterations minimum, 16-byte random per-vault salt. Iteration count tunable upward per future hardware.
• Random number generation: Apple SecRandomCopyBytes (DRBG seeded from the Secure Enclave entropy pool).
• IV / nonce handling: 96-bit nonce per encryption, generated via SecRandomCopyBytes per write. Never reused.
• Recovery mnemonic: BIP-39 (Bitcoin Improvement Proposal 39) style 12-word phrase. 128 bits of entropy. Deterministic mapping to the key-encryption-key.
• Biometric gating:iOS LocalAuthentication framework with the Secure Enclave. Biometric templates never leave the Secure Enclave; we receive only a boolean “authenticated.”
• At-rest device protection: Apple Data Protection class NSFileProtectionComplete on the encrypted vault file. Vault inaccessible to other apps when device is locked.

The data flow is intentionally short:

1. You type a note. Plaintext lives in app memory.
2. The app derives an encryption key from your master password via PBKDF2 on first unlock; the key lives in memory for the unlocked session.
3. The app encrypts the note locally with AES-256-GCM and writes the ciphertext to the on-device encrypted vault file.
4. CloudKit syncs the ciphertext to your iCloud private database. Apple sees ciphertext only.
5. Your iPad downloads the ciphertext, derives the same key from the same master password, and decrypts locally.

No server we operate touches your content. No third-party API touches your content. The only network protocol involved is CloudKit, and CloudKit never sees cleartext.

Less is more. The app requests exactly what it needs and nothing else:

• Face ID / Touch ID — to gate vault unlock.
• iCloud (CloudKit private DB) — to sync encrypted vault data across your own devices. Off by default; user must opt in.
• Microphone — only when you tap Record on a voice note. No background recording, no always-listening.

The app does not request: location, camera, contacts, calendar, notifications, motion, health, background fetch, or any data-tracking permission. Check Settings → Secure Notes on your device — the permission list will be short.

Privacy without transparency is marketing. Our standing commitments:

• Named ciphers, documented choices.Every cryptographic primitive is named on this page. Vague “bank-grade encryption” language is a red flag — we don't use it, you shouldn't accept it from anyone else either.
• Public Privacy Policy. Plain English, no dark patterns. Read it here.
• Named publisher. PixelPort LLC. We sign with our name on everything we ship.
• No content analytics.We don't scan your notes for advertising, machine-learning training, search-ranking, abuse-detection, or anything else. Ever.
• App Store Privacy Nutrition Label.See it on our App Store listing — “Data Not Collected.”
• This page. If our threat model changes, this document is updated and the dateModified bumped.

Security researchers are welcome. If you believe you have found a vulnerability in Secure Notes — cryptographic, application-layer, supply-chain, or otherwise — we would rather hear it from you than read it on Hacker News.

• Contact: security@pixelport.io
• Encryption: PGP key fingerprint published on request via the same address.
• Response window: 48 hours acknowledgement, 7-day initial assessment, fix prioritized by severity.
• Safe harbor: Good-faith research conducted under coordinated disclosure is welcomed; we will not pursue legal action against researchers who act in good faith.
• Recognition: Resolved reports receive a public credit in this document (with your permission) and a complimentary PRO subscription.

For implementation depth and threat-model context, the rest of the writing on this site is intentionally technical:

• What is AES-256 encryption — plain-English explainer of the cipher.
• Zero-knowledge architecture, explained — what the buzzword means, and how to verify a claim.
• What is a recovery seed phrase — BIP-39 in 60 seconds plus storage practice.
• How Face ID actually protects your data — Secure Enclave + TrueDepth deep-dive.
• Is iCloud safe for sensitive notes — what Apple does and doesn't encrypt by default.
• Privacy & encryption glossary — definitions for every named term on this page.