Is Your Journal Really Private? What Real End-to-End Encryption Actually Looks Like

The Short Version

Why Privacy Isn't a Nice-to-Have for a Journal Specifically

Most data an app collects is fine to be seen by someone on the other end: a workout log, a grocery list. A journal is different: it's the one place people are supposed to be able to write without editing themselves for an audience. Research on self-disclosure backs this up directly. Joinson (2001) found that perceived privacy and anonymity in computer-mediated writing measurably increased how honestly people disclosed personal information, compared with conditions where they felt observed. If a journal doesn't feel private, people write a version of the truth, not the truth. That quietly defeats the purpose of journaling research keeps finding benefits for.

The stakes aren't hypothetical, either. Mozilla Foundation's 2022 Privacy Not Included review of mental-health and journaling apps found the majority of the ones it evaluated had weak privacy practices: vague data-sharing policies, third-party trackers, or no meaningful encryption of user content at all. The healthcare and wellness sector has also carried the highest average data-breach cost of any industry for years running, according to IBM's annual Cost of a Data Breach Report. Mental-health-adjacent data is exactly the kind of thing worth protecting structurally, not just promising to protect.

What "End-to-End Encrypted" Actually Means

The phrase gets used loosely. Almost every reasonably built app today encrypts data in transit (TLS, the padlock in your browser) and at rest (the database disk itself is encrypted). Both are good practice, and both are table stakes — and neither one is end-to-end encryption, because in both cases the provider's own servers hold a key that can decrypt the data internally, for debugging, analytics, or just because the architecture works that way. End-to-end encryption means something stricter: the encryption key is derived from a secret only the user has, and the provider is never in possession of anything that can unwrap it. Health Partner's journal is built to the stricter definition.

The Two-Layer Key Design

Encrypting every entry directly with a key derived from your passphrase would work, but it creates a real problem: change your passphrase, and you'd have to re-decrypt and re-encrypt every past entry with the new key. For someone with years of entries, that's a lot of on-device work triggered by something as routine as a passphrase change. The fix is a second layer of indirection, the same pattern used by full-disk encryption and most password managers. Here's what that looks like, step by step:

• Your passphrase, kept separate from your login password, goes through a deliberately slow, memory-hungry process (Argon2id) that produces a master key. This happens only on your device and never leaves it. "Memory-hungry" is the part that matters: it's specifically designed to make guessing your passphrase at scale expensive, even with specialized cracking hardware.
• At setup, the app generates a random 256-bit vault key and wraps it with the master key using strong, standard encryption (AES-256-GCM). Only this wrapped copy, plus the salt and cost parameters needed to redo the passphrase step, is sent to the server.
• The vault key — never the passphrase, never the master key — is what actually encrypts your entries. Each entry gets its own one-time random code, so encrypting the exact same text twice still produces different ciphertext, and every entry carries a built-in tamper-detection check: any change to stored ciphertext becomes detectable automatically.

The payoff: changing your passphrase only means re-deriving the master key and re-wrapping one vault key, not re-encrypting every entry you've ever written.

What the Server Actually Holds

Per entry, the server stores just the encrypted content and the one-time code used to produce it. Title, body, and any tags you write live entirely inside that encrypted blob, meaningless without the vault key. A small amount of metadata, which day an entry belongs to and which part of the day it's for, sits next to it in plain text by design — the same way a filing cabinet's folder labels are visible even though the pages inside are sealed. What you actually wrote is not. For your account as a whole, the server holds the wrapped vault key, the salt and cost parameters used to derive your master key, and a second wrapped copy of that same vault key, this one wrapped with your recovery key instead of your passphrase. That second copy is the entire mechanism behind account recovery, covered next.

The Trade-off Almost No One States Out Loud

Here's the part that a lot of "your data is encrypted" marketing quietly skips: real end-to-end encryption removes the standard "forgot your password" safety net, because there is no server-side key to reset it with. Health Partner's recovery key exists specifically to give you one alternative path: shown once at setup, it's a second wrapped copy of your vault key that lets you regain access if you forget your passphrase. But if you lose both your passphrase and your recovery key, your journal entries are permanently unreadable — gone, by design, not something we're choosing not to fix. If we could reset your access without either secret, we'd also be able to read your journal, which is exactly what this design exists to prevent.

What This Means for You, Practically

• Save the recovery key the moment it's shown. It's displayed once and never stored in plaintext again after that: a password manager entry or something written down and kept offline works; a note that syncs unencrypted to the cloud undermines the point.
• Use a passphrase different from your login password. One credential leaking shouldn't expose the other.
• Don't expect a support-ticket reset. There's no "verify your identity and we'll reset it" option for the journal passphrase, because verifying your identity doesn't give anyone the key.
• Tamper detection is automatic. The authentication tag on every entry means any modification to stored ciphertext is detectable without you doing anything.

Frequently Asked Questions

Does end-to-end encryption mean Health Partner literally cannot read my journal?

Yes, structurally, not just as a policy. Entries are encrypted on-device with a key derived from a passphrase that is never sent to the server. The server only ever stores ciphertext (with its authentication tag built in) plus a wrapped copy of the key needed to decrypt it. What you actually write is never stored as plaintext anywhere in the backend, for anyone, including us, to read.

Is my journal passphrase the same as my login password?

No, and that's deliberate. Your login password authenticates you to the app the normal way. Your journal passphrase is a separate secret used only to derive the key that unlocks your entries. Keeping them separate means a login credential leak alone can't expose journal content, and vice versa.

What happens if I forget my journal passphrase?

You can recover access using the recovery key shown once at setup. Entering it lets the app unwrap your existing data encryption key without your original passphrase, then you set a new passphrase and the key is re-wrapped under it. Past entries are untouched by this process.

What if I lose both my passphrase and my recovery key?

Your journal entries are permanently unreadable. Nobody, including Health Partner, can decrypt them without one of those two secrets, because the server never holds a usable key. This is the direct cost of the encryption actually being end-to-end rather than a marketing description of ordinary server-side encryption.

How is this different from apps that just say "your data is encrypted"?

Most apps that say this mean encryption in transit (TLS) and at rest (the database disk is encrypted), both of which are good practice but leave the provider holding a key that can decrypt your data internally. End-to-end encryption means the key is derived from a secret only you have, and the provider is never in possession of anything that can unwrap it.

Where This Leaves You

"We take your privacy seriously" is a sentence any company can write regardless of what its database actually looks like. What actually matters is the design: what gets sent to the server, what key would be needed to decrypt it, and who holds that key. For Health Partner's journal, the server only ever sees ciphertext, and the key lives only where a passphrase or recovery key can reconstruct it. That's also why losing both secrets is unrecoverable rather than an inconvenience: the same property that keeps entries private removes any backdoor that could restore them. Download Health Partner to start a journal that only you can read.

References

1. Joinson AN. Self-disclosure in computer-mediated communication: the role of self-awareness and visual anonymity. Eur J Soc Psychol. 2001;31(2):177–192.
2. Biryukov A, Dinu D, Khovratovich D. Argon2: the memory-hard function for password hashing and other applications. IETF RFC 9106. 2021.
3. National Institute of Standards and Technology. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. NIST Special Publication 800-38D. 2007.
4. Mozilla Foundation. Privacy Not Included: Mental Health Apps. 2022.
5. IBM Security. Cost of a Data Breach Report. 2024.

Also on the blog