Prevon

Security

The Proof.

Don't take our word for it. Here's the actual math.

We believe security architecture should be verifiable, not just trusted. This page describes Prevon's design and current build, and the cryptography behind it.

It is not a warranty or a guarantee of security. No software is free of bugs, and security depends on your device, your settings and how you keep your twelve words. Where a feature is not shipped yet, we say so. There has been no independent security audit yet: every review so far was done by us and by internal, AI-assisted reviews.

2128
Possible key combinations
340 undecillion — a 39-digit number, for a phrase the app generated
Try to crack it yourself

01

The Server

A Sky Full of Static

Imagine a thief breaks into a bank and opens your deposit box. Inside, instead of your things, there's a solid block of steel. That's the idea behind what our servers would hold if you turn sync on.

When you type your 12 words, you aren't logging into a website. There is no account to log into. You're unlocking something with a key your device works out from the words (or, for a Key Chest vault, opens from a key file) — we do not hold it, and we do not store a copy. Without that key, what a server holds is designed to be .

And because there are no accounts, there are no folders with your name on them either. Your scrambled notes are designed to sit in the same shared storage as everyone else's, with nothing in that storage saying which pieces belong to whom. So even a thief who took everything should get a pile of locked boxes and no easy way to tell whose is whose, or to open one.

The real engineering

Storage holds one flat keyspace with no per-user index. Object keys are derived deterministically from the user's own key material, so the server is designed to hand back a blob it cannot name, attribute, or enumerate. There is no account table linking a person to a row, because there is no account.

The intended consequence: a full database dump yields a set of opaque blobs and nothing that says which blobs belong together, whose they are, or what any of them contain. Correlation would have to be reconstructed from the ciphertext itself, which is what the encryption is meant to prevent. Metadata such as timing and size may still be visible.

Sync is off by default. The relay code is deployed and its routes are live, but they have had no independent audit, and we have not verified every property below against the running relay. Treat this as the design. Even by design, the relay and Cloudflare can see your device's IP address and the time of each request, and roughly how much was sent.

Verified against: pie_security/lib/src/doorman.dart · pie_core/lib/src/config/vault_config.dart

02

The Lock

Slow on Purpose, So Guessing Is Costly

Most apps turn your password into a key instantly. That speed helps the thief too — a fast computer can try billions of passwords a second. So we chose the opposite of fast.

We run your words through , which is deliberately slow and deliberate about one thing in particular: memory. Before it will produce your key, it has to hold 64 MB of memory for a few passes. That's more than a speed bump. To guess a million passwords at once, a thief doesn't just need a faster chip; they need a million times 64 MB of memory, all at the same time. That makes large-scale guessing far more expensive.

That little pause you feel when you unlock your vault with your words? That's this wall being built, in front of you. The delay you notice is the same cost a thief would have to pay — per guess. A short PIN is a different story: see below.

The real engineering

Argon2id, 64 MB memory limit, 2–4 passes depending on tier (new vaults use 4), 256-bit output key. Parameters are read from the source (argon2_ffi.dart). The vault database is then encrypted with SQLCipher (AES-256), and each note, title and folder name is sealed a second time with XChaCha20-Poly1305 using a random 24-byte nonce.

Scope: this describes the 12-words path. A Key Chest vault is locked by a random key instead, and the words are one way to open a small key file. The faster Quick Unlock PIN path is weaker; see the table of attackers below.

Memory-hardness is the whole argument. A plain hash is embarrassing on a GPU because the attacker only pays for compute, which is cheap and parallel. Argon2id makes every guess occupy 64 MB for its duration, so N simultaneous guesses need 64 MB × N of fast memory. Scaling the attack means buying memory, not just silicon.

The visible cost is the pause on unlock. That pause is the control working — it is the same work an attacker must pay, once per guess.

Verified against: pie_security/lib/src/argon2_ffi.dart

Function
Argon2id
Memory per guess
64 MB
Passes
2–4, depending on tier (new vaults: 4)
Output key
256-bit

03

The Math

Why Brute-Force Guessing Doesn't Scale

Your vault is locked by . They're picked at random from a list of 2,048, which sounds small and isn't: twelve picks give you around 340 undecillion possible combinations. That's a 39-digit number — so big that it's more than the number of stars in the entire universe.

Now picture a computer that could try a trillion of those combinations every single second, far faster than anything we know how to build. Even at that speed, trying every combination would take about 10 billion billion years. The universe has been around for about 14 billion.

These figures assume your twelve words were generated uniformly at random by the app. Words you chose yourself, or that were exposed some other way, do not get this protection. And the arithmetic is about guessing: for a standard (“Normal”) vault, anyone who holds your twelve words and a copy of the vault files can read everything today, whatever PIN or key you added. A Key Chest vault works differently.

Every possible 12-word phrase

340,282,366,920,938,463,463,374,607,431,768,211,456

That is 340 undecillion. Now imagine trying to guess it; a billion guesses every second. Go on:

Simulated at one billion guesses per second
Phrases tried
0
Space covered
0%

Press the button. The percentage will not move in any way you can perceive.

Everybody on Earth — all 8 billion of us — each trying a billion phrases a second, working non-stop since the Big Bang, 13.8 billion years ago.

1.02%

Over 98% of the space is still untouched. That is what 2128 means.

At a billion guesses a second, exhaustively searching this space would take far longer than the universe has existed, and each real guess against Prevon also costs 64 MB of memory. 2128 is 2,048 words taken twelve times, minus a 4-bit checksum. These figures are arithmetic about a uniformly random phrase, not a prediction about future technology or a guarantee of security.

What about a ? The best known shortcut for this kind of search is , which in theory roughly halves the number of bits of work, like turning a 39-digit lock into a 20-digit one. That would still be a very large search, and the key derivation adds its own memory cost. We cannot predict future technology or new attacks.

This is arithmetic about the key space, not a warranty. Real-world security also depends on the software, your device and how you handle your words.

The real engineering

128 bits of entropy, not 39 digits of decimal. 12 words from a 2,048-word list is 12 × 11 = 132 bits, of which 4 are a checksum, so the phrase carries 128 bits of randomness. The honest framing is key space, not a digit count.

Exhaustive search at 10¹² guesses/second takes about 1019 years. Grover's algorithm reduces the effective work to ~264 operations in theory; that is an idealised bound, and it does not account for the memory-hardness of derivation. We make no prediction about future hardware.

The energy floor is real but does not bite at this size. Landauer's limit sets a minimum energy to erase one bit (~2.8×10-21 J at room temperature). Counting through 2128 keys costs on the order of 1018 J; the Sun emits ~1044 J over its whole life. Energy only overtakes the Sun at roughly 2214 — so at 128 bits the binding constraint is honestly time, not energy. The floor that does bite is memory: a billion simultaneous Argon2id guesses at 64 MiB would need ~67 petabytes of RAM held at once.

Verified against: pie_security/lib/src/doorman.dart

Your words
12, from a list of 2,048
Key space
2128 ≈ 340 undecillion
Best quantum shortcut
Grover: ~264 effective work (in theory)

04

Changing your words

If you think someone got your words, you don't start over — you change them.

Most apps treat “change your password” as a coat of paint. The old locked files are still sitting there, locked with the old key — so anyone who already copied them keeps a working copy.

Changing your words in Prevon is designed to re-lock everything. means every stored piece is unlocked with the old words and re-locked with the new ones, and the vault itself is re-keyed at the storage layer. It happens as one single operation: if any part fails, the whole thing is designed not to happen, and your old words still work.

And once it succeeds, the old words are designed to stop working. They should not unlock your notes, or a copy someone took before you changed them. Removing a lost PIN or security key from your list is a different thing: it does not undo what a copy of that key could already do.

The real engineering

One rotation path exists in the shipped engine, and it always does both halves together: every stored row is re-encrypted under the new derived key, and the vault is re-keyed at the storage layer. There is no fast/partial mode.

The operation is designed to be all-or-nothing: if either half fails, rotation should not complete and the old phrase should remain valid. We have not independently verified that. Once it succeeds, the old phrase is designed to unlock nothing, including ciphertext captured before the rotation ran. It cannot undo anything an attacker already read while holding the old phrase and an unlocked vault. Known gap: after a phrase change, the old key can remain wrapped inside Quick Unlock PIN records, so an attacker who also holds an older copy of those records is not shut out; changing the phrase removes your extra ways in so you set them up again.

An optional step-up gate can require the current phrase on top of PIN or biometric before a rotation is allowed to start, which closes the “unlocked phone left on a table” case.

Verified against: pie_brain/lib/src/security/rotation_orchestrator.dart

05

Sync storage — off by default

One Unlabeled Pool, Not a Filing Cabinet

Off by default

Sync is off by default and unaudited. The code is compiled into the source, and every in-app switch for it starts off, so nothing is sent until you turn it on. The scripted release builds leave it out unless we choose to include it. What follows is the design we are hardening, not a verified description of the running relay.

Many cloud sync services keep your files in a folder tied to your account. Ghost Sync is designed so there is no such folder to find: every user's encrypted notes are meant to sit in one shared, undivided pool with nothing that marks which pieces belong to whom. Finding your own data again is designed to be a calculation your device performs from your Recovery Seed, not a lookup against an account record we hold. The design also pads each encrypted note to a standard size, so a short note and a long one look similar from outside — see for the exact buckets. And because there's no account record to check for inactivity, storage that's gone unpaid and unrenewed is designed to expire on its own. All of this is design: sync is off by default and the expiry and renewal behaviour is not verified.

The real engineering

Build status, precisely: the relay is a Cloudflare Worker (D1 + R2) that is deployed and running, and the client side is compiled into the source. The in-app switches (sync.enabled, ghost.masterEnabled, ghost.sharingEnabled) are off by default, and the scripted release builds compile the feature out unless the operator opts in. Several relay routes (the append-chain log and the paid-tier redeem route) are live code that has had no audit.

There is no account system at all. Your identity is the twelve words: they derive the vault id and the key on every device, so nothing on the server is a record of a person. Device discovery runs through /v1/discover-chains and /v1/claim-device-slot against per-device chains, rather than a lookup table keyed to an account, because there is no account to key.

The honest gaps. Each encrypted envelope is padded up to one of seven fixed sizes, from 1 KiB to 5 MiB (each step 4× the last), which is meant to reduce what its length reveals. There is no relay-level cover traffic: timing and traffic volumes between devices are not hidden. Usage billing is deliberately deferred rather than shipped, and we have not verified the per-identity storage quota in this pass.

Transferring to a second device works two ways that do not need the relay: a direct device-to-device transfer over your local network, or typing the same twelve words into the new device together with a copy of your vault. The nearby-transfer protocol is not yet bound to the pairing code and is unaudited.

Envelope padding
Seven sizes, 1 KiB to 5 MiB
Cover traffic
None today
Sync switches
Off by default
Independent audit
None yet

Read the full walkthrough of how this pool and device discovery fit together on the Ghost Sync page.

How We Compare

How Prevon is designed differently

A feature-by-feature look at how Prevon is designed, next to popular note apps, based on their published documentation.

FeaturePrevonNotionGoogle KeepApple NotesOthers
Designed so the vendor does not hold your key
On-device AI processing(see note below the table)
No account required
End-to-end encrypted sync (designed; off in the private beta)(see note below the table)
Device-to-device sync, no cloud in the middle (designed; off in the private beta)
No note content sent to a cloud AI (current Prevon build)

✓yes  ·  × no. Verdicts are read from each vendor's own published documentation as of , and describe the default setup. Apple Notes only gains encrypted sync when Advanced Data Protection is switched on. Apple Intelligence runs many tasks on the device, but is opt-in and unavailable in some countries. “Others” is a category rather than one product, so no single answer fits it. On the cloud-AI row: Notion AI and Google Keep’s Gemini features process your content on their servers, and Apple Intelligence sends harder requests to Private Cloud Compute — so, going by that documentation, none of the three keeps AI processing entirely off the network. If any of this changes, it is on us to correct the page.

* Prevon’s sync is switched off in the private beta, so that row describes its design — with default settings your notes stay on your device. Its on-device AI features are in beta. Prevon’s column describes its design and the current private-beta build, not an independent audit.

Read the full comparisons, including where each app wins

06

Digital Cremation

Wiping the key, not hunting the data

When you throw something away in real life, it's gone. On a phone, it isn't. Deleting a file usually just removes the name, and phone storage quietly moves “deleted” data somewhere else to save wear on the chip — so the old copy can sit there, perfectly readable, for weeks. That's true for , and it's why “erase” buttons often don't mean what they say.

So we don't rely on overwriting alone. When you wipe your vault, its keys are removed from your device and its files are overwritten and deleted, and the leftover copies of your notes are designed to be unreadable without the key. This is best effort. It does not reach a copy of your twelve words that you or someone else kept elsewhere, a backup of the files, or older copies that can linger in the database's internal log or in the safety copy kept after an app upgrade. A note you “delete forever” can sit in those for a while, so do not use delete as a shredder.

The real engineering

Wear levelling makes overwrite-based erasure unreliable: a write to a logical block lands wherever the controller chooses, so the original physical copy can survive indefinitely and is unreachable by software. The wipe therefore does two things and trusts neither alone: it first removes this vault's key records from the phone's secure storage, then overwrites the vault files with random data and deletes them.

Removing the key records is meant to leave stray copies undecryptable, but only if no other route to the key exists. For a standard vault the key is derived from your twelve words, so anyone with the words and any surviving copy of the files (a backup, a relocated flash block, an older database log or migration safety copy) can still open it. The wipe also asks the relay to delete synced data, best effort, if you used sync. It is not a certified shredder, and we have not verified it on every phone.

Verified against: pie_brain/lib/src/handlers/nuke_vault_handler.dart · pie_security/lib/src/doorman.dart

07

Protection

How unlocking actually works

  • Quick unlock

    Keys required
    Your phone (PIN or biometric)
    Best for
    Fast everyday access without retyping your phrase. Weaker than the words: a PIN can be guessed offline by someone who copies the phone's secure-storage records
  • Extra ways in (built, not tested on real hardware)

    Keys required
    A hardware security key and/or an NFC tag, alone or combined with a PIN ("and") or as alternatives ("or")
    Best for
    Raising the bar beyond a PIN. Never yet tested with real keys or tags on real phones; an NFC tag can be copied
  • Full unlock

    Keys required
    Your 12-word Recovery Seed
    Best for
    Opening your vault on a new device (together with a copy of your vault), or after a reset
  • Step-up re-auth

    Keys required
    Your current 12-word phrase, on top of PIN or biometric
    Best for
    Blocking a phrase change from an unlocked, unattended device

Your are the root way in for a standard vault, and the words never sit on the phone. We do not hold them. If you lose every way in and your words, we cannot recover your notes. The design has no escrow or spare key held by us. Two things to know: for a standard (“Normal”) vault, your words plus a copy of the vault's files open everything, whatever PIN or key you added. A Key Chest vault, offered when you create a vault, is locked by a random key instead, and the words are only one way to open its key file; it is lightly tested on real devices and has had no independent review. The first-launch Explore vault has no words, and anything running as the app on your phone can read its key, so keep nothing you care about in it.

08

Native app

Why Prevon Is a Native App, Not a Browser App

We could build a web version. It would be cheaper and easier. For now we have decided against it, because it would weaken the model on this page.

A website is not one thing you install — it's code that gets re-sent to you every time you open it. So if something between you and that server is tampered with, even briefly, the code running on your screen could change without you noticing. A native app is different: it's a signed package that sits on your device, and updates arrive through a signed channel. That makes it easier to inspect than a page that rebuilds itself on every refresh. The app does not currently detect a tampered build, so install only from an official store, or check a direct download against the fingerprints on our verify page. Android builds that Google Play generates also carry Google's own licence check, which contacts Google Play each time the app starts.

There's a second reason. A browser tab shares its world with other tabs, extensions, and scripts — and browsers treat data stored by a website as something they may clear when space is tight. Your notes should not be disposable. Prevon runs inside the your phone provides, which is designed to keep other apps out of its storage, and it keeps your files there until you decide otherwise.

Convenience and control aren't always the same thing. We picked control.

The real engineering

The threat is update-channel integrity, not transport. A web app re-fetches its code on every load, so compromise of a server, a CDN edge, or DNS for even a short window injects code that runs with the user's trust — and nothing in the page can detect it, because the page is the thing that changed.

A native build is a signed artefact: the code is fixed at install, updates arrive through a signed channel, and the binary can be inspected. Storage differs too — a native app writes durable files under OS sandboxing, where a browser treats local data as a cache it may evict.

Verified against: apps/pie_notes — native build & OS sandboxing

How it works

Your data, encrypted

Security researchers are welcome to review it. We have not had a third-party audit.

This is the design. Sync is off by default, so unless you turn it on no notes are sent through that middle leg.

Encrypted locally

Your notes are encrypted on your device before anything is sent, if you turn sync on

Scrambled data moves

By design, our servers handle only encrypted data and do not hold the key to decrypt it

Decrypted locally

Your devices, with the right keys, decrypt the data

The fine print

Where It Ends — and Why That's the Point

Everything above describes how we designed Prevon, not a promise of outcome. This is the same honesty turned on the edges: places where the protection stops. A security researcher would likely find these quickly — read them here first, in plain words.

Honest edge

Notes stay on your device unless you turn sync on

Ghost Sync and sharing are compiled into the source, but every in-app switch starts off and nothing is sent until you turn it on. Our scripted release builds leave the feature out unless we choose to include it. The relay code is live and has had no independent audit.

ghost.masterEnabled / sync.enabled off by default

Honest edge

Traffic metadata is not hidden

The design is meant to keep your notes unreadable to us. But a server holding your encrypted blobs can still tell that some device sent some amount of data at some time, from some IP address. We do not disguise timing or traffic patterns — there is no cover traffic today, and we would rather say that than imply otherwise. Separately, the on-device assistant's models download from huggingface.co, which sees your IP address and which file you asked for.

no cover traffic

Honest edge

A compromised device is outside what we protect

We encrypt your notes, titles, attachments and search index on the device, and in transit if you use sync. If malware is reading your screen or your memory while the vault is unlocked, or is running as the app on your phone, encryption does not help — that is true of encrypted apps in general, not just ours. Some things also sit outside the vault encryption; see the known gaps below.

out of scope by design

Honest edge

There is no spare key held by us

Lose your twelve words and we cannot recover your notes: there is no reset link and no recovery path. We designed it without escrow, which is also meant to leave nothing for us to hand over. It is a feature with a sharp edge, not a flaw we can patch on request.

no key escrow exists

Honest edge

AI and sharing: read the status, not the pitch

The on-device assistant runs locally against downloaded models. Cloud AI (a provider such as Anthropic or OpenAI) is compiled off. You can point the assistant at a server you run yourself, but it does nothing until you add one. Sharing is compiled in but off by default and unaudited. We do not count sharing as protection until it has been reviewed.

CloudGates.cloudAiEnabled = false

Honest edge

Standard building blocks, audit still to come

We use well-tested, standard cryptography instead of rolling our own, which avoids one common source of failure, though not all of them. It is not a substitute for a third-party audit — we have not had one, and iOS, macOS, Windows and Linux builds are unaudited too. All review so far was by us and by internal AI-assisted reviews. We plan an independent cryptography and mobile review and will keep saying this until we have one.

no external audit yet

We would rather show you the edges of the design than ask you to take it on faith. This page is not a warranty, and it may be out of date as the app changes.

09

Who gets what

What we don't protect against, in a table

From our own security model, last reviewed 2026-10-29. Checked by us and by internal AI-assisted reviews only; no independent audit yet.

  • Someone with only a copy of your files or a backup

    What they get
    Metadata: roughly how big the vault is, file dates, and the settings for the slow key function. A copy of the whole app folder can also include the few things kept outside the vault encryption (see the known gaps).
    What stops them, and where it stops
    Not your notes, attachments, PIN or words. If the app generated your words, guessing them is not feasible. Words you chose yourself can be guessed.
  • A stolen phone that is switched off or just rebooted

    What they get
    The encrypted files.
    What stops them, and where it stops
    The phone hardware holds the unlock secrets until the first unlock after boot. We have not tested how much easier a phone that was unlocked once since boot is for a forensic lab.
  • A stolen phone, unlocked at phone level, Prevon locked

    What they get
    The encrypted files and the chance to try your ways in on the phone.
    What stops them, and where it stops
    Notes, unless they meet a way in. The app adds growing delays after wrong tries, but that counter is software, and a PIN-only way is exposed to patient guessing.
  • A stolen phone with Prevon already open

    What they get
    Everything on screen and in memory.
    What stops them, and where it stops
    Lock the app before putting the phone down. The automatic lock is a timer inside the app and does not run while the phone has suspended the app.
  • Someone who knows your 12 words

    What they get
    Alone, nothing. With any copy of your vault files, for a standard vault, everything today, whatever PIN or key you added.
    What stops them, and where it stops
    A Key Chest vault is locked by a random key, so the words alone are not the key there. Words are never stored on the phone.
  • Someone who knows your PIN

    What they get
    If a PIN is your only way in, they can open the app on your phone.
    What stops them, and where it stops
    Not the words. If every way in also needs your security key, the PIN alone opens nothing.
  • Malware running as the app, or a rooted phone

    What they get
    What the app can see. It can copy the stored unlock records and ask the phone for the secret meant to be used without a prompt.
    What stops them, and where it stops
    Not the words. A PIN-only way can then be guessed offline because its guess counter is software. Our estimate, not a measurement: a 6-digit PIN falls in hours or less on rented hardware. A long passphrase or a security key holds up much better.
  • A court order served on us

    What they get
    We hold no keys and no copy of your words, so there is nothing we can hand over that opens your notes. Metadata and files they seize themselves are as in the first row.
    What stops them, and where it stops
    A court can compel you. We do not claim to protect against that, or against being forced to unlock with a fingerprint or PIN.

10

Known gaps

What is open today

A plain list, not ranked. “Open” means we have no confirmed fix in the shipped code. This is the list a researcher would build in a day, so we publish it first.

  • Reminder text and the words on Reminders and Calendar widgets are on by default and sit outside the vault encryption: in the notification system, on the lock screen, on smartwatches, and in widget stores. Turning "Show what reminders are about" off makes notifications generic and removes the widget copy.
  • The on-screen keyboard (including third-party keyboards) may learn what you type in notes, titles and search unless you turn on the private keyboard setting. Password, PIN and phrase fields are always private.
  • A plaintext copy of each note title is kept in note metadata fields, and the on-device search-by-meaning cache stores note text unencrypted inside the app sandbox.
  • Lecture recordings are held as plain audio in temporary storage until the vault is next unlocked.
  • The Explore vault key can be read by anything running as the app.
  • Quick Unlock PINs are offline-guessable if someone copies the phone's secure-storage records, and a phrase change leaves the old key wrapped in them.
  • "Delete forever" can leave copies in the database log and in the migration safety copy kept after an app upgrade (up to 7 days).
  • The automatic lock does not run while the phone has suspended the app. The clipboard clears itself after 60 seconds by default, but that timer has the same limit.
  • The delay after wrong tries can be shortened by moving the phone's clock forward on some systems.
  • Nothing in the app detects a tampered build.
  • Hardware security keys and NFC tags have never been tested on real devices. Nearby transfer is not bound to the pairing code. Relay sync routes and the paid-tier redeem route are live code with no audit. iOS, macOS, Windows and Linux builds are unaudited.
  • The Android build Google Play generates includes Google's licence check, which contacts Google Play at every launch and stops the app on a phone without Google Play. The assistant's models download from huggingface.co. With sync off and models already downloaded, the app makes no routine requests. A network capture of a default-settings app has not yet been done.
  • We have not verified that every folder holding app data is excluded from iOS backups. Contents would still be encrypted, but sizes and counts could show.
  • There is no independent audit yet.