DEV Community: Keshav Chauhan

I'm 16. I built an AES-256-GCM encrypted journal app in Flutter. Here's exactly how the encryption works.

Keshav Chauhan — Tue, 09 Jun 2026 02:00:00 +0000

I'm Keshav, a solo developer from India building under my studio SezRonix.

I started keeping a digital journal and noticed something uncomfortable — I was editing myself. Writing around difficult thoughts instead of through them. Eventually I understood why: my entries were sitting on a server I didn't control, in a form someone could technically read.

So I built RozVibe. A private encrypted journaling app for Android.

Since dev.to has been kind to my previous posts on searching encrypted data and the hardest parts of building this, I want to do a complete technical breakdown here — not marketing, just the actual implementation with the real trade-offs.

The core design goal

Every sensitive piece of a journal entry — the text content, mood, timestamps — is encrypted on the user's device before it leaves the app. What Firestore receives is a single opaque base64 string. The server never sees plaintext. Ever.

How the encryption key works

This is the most important part to understand correctly, so I'll be precise.

The key never persists anywhere

The 32-byte AES key lives exclusively in RAM inside the EncryptionService class as _key of type encrypt_pkg.Key. It is never written to Firestore, never written to disk, never saved to SharedPreferences. It exists only while the user is actively logged in.

On logout:

void clear() {
  _key = null; // immediately wiped from memory
}

Gone. No trace of it on the device after logout.

Key derivation — PBKDF2 with HMAC-SHA-256

Since the key is never stored, it must be reconstructed on every login. This is done using PBKDF2 — a deterministic key derivation function. Same inputs always produce the same output.

final pbkdf2 = PBKDF2KeyDerivator(HMac(SHA256Digest(), 64));
pbkdf2.init(Pbkdf2Parameters(salt, 100000, 44));
final keyBytes = pbkdf2.process(
  utf8.encode('${userId}_${pin ?? "default_secure_vault"}')
);

100,000 iterations of HMAC-SHA-256. This is computationally expensive by design — it makes brute-force attacks against the PIN significantly slower.

The 44-byte output is split:

Bytes 0–31 → the 32-byte AES-256 key
Bytes 32–43 → legacy fallback IV (kept for backward compatibility)

The three inputs required to derive the key

The user's account ID (userId)
The user's PIN or password
A 16-byte cryptographically random salt

Lose any one of these three and you cannot derive the key.

The salt — the only persisted cryptographic material

When a user first signs up, a 16-byte random salt is generated:

encrypt_pkg.IV.fromSecureRandom(16)

This salt is stored in two places:

Locally: Android's EncryptedSharedPreferences (backed by the hardware Keystore)
Firestore: users/$userId/crypto_salt

The Firestore copy is what enables multi-device sync — more on that below.

Per-entry encryption

Every single encryption event generates a fresh 12-byte IV:

final iv = encrypt_pkg.IV.fromSecureRandom(12);

Never reused. Never predictable.

The cipher is AES-256-GCM. GCM mode gives both confidentiality and integrity — any tampering with the stored ciphertext is detectable on decryption. The final stored format is:

Base64( IV[12 bytes] + Ciphertext + GCM Auth Tag )

What Firestore actually receives

This is where the design becomes concrete. Inside DiaryEntry.toEncryptedMap(), all sensitive fields are bundled into a JSON object and encrypted before the document is written:

// sensitive fields bundled and encrypted
final encryptedData = encryptionService.encryptData({
  'content': content,       // journal text
  'mood': mood,             // emotional state
  'createdAt': createdAt.toIso8601String(),
  'updatedAt': updatedAt.toIso8601String(),
});

// what gets written to Firestore
{
  'id': id,              // non-identifying UUID
  'userId': userId,      // for security rules
  'date_index': dateIndex, // for sorting queries
  'isFavorite': isFavorite, // for filtering
  'data': encryptedData, // opaque base64 — everything else
}

Only the minimum unencrypted metadata needed for Firestore queries exists in plaintext. Everything a user actually wrote is inside that single data field — unreadable without the key.

A Firestore breach exposes four non-sensitive fields and one encrypted blob. Nothing readable.

How multi-device sync works

This is the question I get most often: if the key never persists, how do entries appear on a different device when you log in?

The answer is deterministic key reconstruction, not key retrieval.

Here's the exact flow when you log into a new device:

AuthService calls initializeEncryptionForUser
The app fetches users/$userId/crypto_salt from Firestore
PBKDF2 runs with: userId + PIN + fetched_salt
Because PBKDF2 is deterministic, the same inputs produce the exact same 32-byte key on the new device's CPU
That key decrypts all the data fields from Firestore

The key is never transmitted. It is never stored on the new device until login. It is mathematically reconstructed from credentials the user already knows plus a salt that was synced to Firestore. The moment the user logs out, it's wiped from RAM again.

Client-side search

Firestore cannot search encrypted content — you can't run a where query against a ciphertext field. So search runs entirely client-side.

The actual implementation in DiaryService.searchEntries:

Stream<List<DiaryEntry>> searchEntries(String userId, String query) {
  return getEntries(userId).map((entries) {
    return entries.where((entry) {
      return entry.content
        .toLowerCase()
        .contains(query.toLowerCase());
    }).toList();
  });
}

Flow:

Fetch all entries from Firestore (encrypted blobs)
Decrypt each entry client-side using fromEncryptedMap
Filter the decrypted list in memory by case-insensitive substring match
Return matching entries

The search query itself never leaves the device. No server ever sees what the user is searching for.

Known limitation: this approach decrypts the entire entry list in memory on every search.

At current scale, that's perfectly acceptable. But as a journal grows into thousands of entries, this becomes increasingly expensive. Every search requires decrypting the vault, iterating through every entry, and performing string matching in memory.

This isn't unique to RozVibe.

Many encrypted note-taking and journaling systems face the same fundamental problem:

If the server can't read your data, it can't build a traditional search index.

That means developers usually end up choosing one of two compromises:

Server-side indexing (fast search, weaker privacy)
Full client-side scanning (strong privacy, slower search)

I wanted a third option.

The Blind Index Architecture

The next RozVibe update replaces full-vault scanning with a local blind index.

When a journal entry is saved:

final tokens = SearchTokenizer.extractWords(content);

for (final token in tokens) {
  final hash = HMAC_SHA256(searchKey, token);
  blindIndex.insert(hash, entryId);
}

Instead of storing plaintext words, the app stores HMAC-SHA256 hashes of those words inside a local SQLite database.

A simplified record looks like:

token_hash  →  entry_id

8f2ab4...   →  entry_123
91dfe7...   →  entry_456

The plaintext word itself never enters SQLite.

Only the cryptographic hash.

An index is applied to the token_hash column, allowing SQLite to perform extremely fast lookups.

When a user searches for:

anxiety

the search flow becomes:

"anxiety"
      ↓
HMAC-SHA256(searchKey)
      ↓
Lookup token_hash in SQLite
      ↓
Return matching entry IDs
      ↓
Decrypt only those entries

Instead of decrypting every journal entry, the application decrypts only the entries that actually match.

Recovering The Index On A New Device

One challenge with local indexing is device migration.

The SQLite database isn't synchronized through Firestore.

So what happens when a user logs into a new phone?

RozVibe performs a one-time backfill process.

The application:

Downloads encrypted entries from Firestore
Reconstructs the encryption and search keys
Decrypts each entry locally
Generates blind-index hashes
Rebuilds the SQLite database

A simplified version looks like:

for (final doc in encryptedEntries) {
  final entry = decrypt(doc);
  final tokens = tokenize(entry.content);
  await index.insert(tokens, entry.id);
}

Once complete, future searches become local database lookups.

The search query never leaves the device.

The journal content never leaves the device.

And the server still has no searchable view of user data.

That trade-off is important to me.

Fast search is easy when the server can read everything.

Building fast search while keeping the server blind is a much more interesting engineering problem.

The trade-off I made consciously

Storing the salt in Firestore means someone with both Firebase admin access AND the user's PIN could derive their key.

I made this trade-off deliberately. The alternative — requiring users to manually export and store their own cryptographic key — is theoretically purer but practically means users lose their journals when they change phones. The UX failure rate on manual key backup is extremely high for a consumer app.

I chose recoverability over theoretical zero-knowledge purity. I think it was the right call for this use case. I'm open to being wrong.

What the app does beyond encryption

The encryption is infrastructure. The actual product:

Mood tracking: 5 states — Radiant, Calm, Neutral, Low, Stormy — selected per entry
Insights dashboard: 30-day mood trend chart, frequency histogram, distribution pie chart — all computed on-device using fl_chart
Sanctuary Lock: 4-digit PIN screen gating app access on every open
Rich text editor: flutter_quill for formatted journaling
Writing streak tracker: consecutive day counter
Journaling prompts: guided starting points for blank-page anxiety
Offline support: Firebase's offline persistence cache — works without internet

Full tech stack

Layer	Technology
Framework	Flutter (Dart, SDK ≥3.3.0)
State management	Riverpod + riverpod_generator
Auth	Firebase Authentication
Database	Cloud Firestore
Encryption	pointycastle (PBKDF2), encrypt (AES-256-GCM)
Secure storage	flutter_secure_storage (encryptedSharedPreferences:true)
Charts	fl_chart
Rich text	flutter_quill
Calendar	table_calendar

What I'd do differently

1. Explore password-based salt derivation
Rather than storing the salt in Firestore at all, derive it deterministically from the password itself using a separate KDF. Eliminates the Firestore salt dependency entirely at the cost of making salt rotation impossible.

2. Open source the encryption layer
The EncryptionService specifically would benefit from public audit. It hasn't happened yet. It should.

Download

If you're curious about how these ideas translate into a real product, RozVibe is available to try.

Free on Android via Uptodown — no Play Store required:
https://rozvibe.en.uptodown.com/android

Website: https://rozvibe.me

I read every comment personally. If you see something wrong in the implementation — especially in the key derivation or GCM usage — I genuinely want to know. This is my first app at this scale and the security community here is more qualified than I am to spot problems.

— Keshav

Why Searching Encrypted Data Is Harder Than Most Developers Think

Keshav Chauhan — Tue, 02 Jun 2026 13:30:00 +0000

Most developers take search for granted.

Add a search bar.

Query the database.

Return matching results.

Simple.

At least that's what I thought before building RozVibe, a privacy-first encrypted journaling app.

Then encryption entered the picture.

And suddenly one of the most basic features in software became surprisingly difficult.

The Search Problem Nobody Notices

When you search inside a typical application, the backend already knows your data.

That makes searching straightforward.

For example:

Blog platforms search article content
Note-taking apps search stored notes
CRMs search customer information
Journaling apps search journal entries

The server can index everything because the server can read everything.

But what happens when the server cannot read the data?

That's where things get interesting.

Encryption Changes The Rules

At RozVibe, journal entries are encrypted on the user's device before they're synced.

The server only receives encrypted ciphertext.

Not titles.

Not moods.

Not reflections.

Not memories.

Just encrypted data.

That's great for privacy.

It's terrible for traditional search.

Because databases cannot search what they cannot understand.

Imagine storing this:

{
"content": "Today was a great day."
}

A traditional database can easily find the word "great".

Now imagine storing:

Q7x6Mz8Pj4T2vNf...

That's what encrypted content looks like.

The database has no idea what's inside.

And that's exactly the point.

The Obvious Solution Is Also The Wrong One

When many developers first encounter this problem, the obvious answer is:

"Why not decrypt everything on the server before searching?"

Technically, that works.

But it completely breaks the privacy model.

The moment a server can decrypt user content, you've reintroduced trust requirements.

Now users must trust:

your infrastructure
your employees
your logging systems
your future business decisions
your security practices

The architecture is no longer truly private.

We wanted something different.

How We Solved Search In RozVibe

Instead of searching in the cloud, we moved search entirely to the device.

The process looks roughly like this:

Retrieve encrypted entries
Decrypt locally in memory
Perform search on-device
Display results
Discard temporary memory

The backend never participates in search operations.

The user's query never leaves the device.

The journal content never leaves the device in readable form.

Privacy remains intact.

The Tradeoff Nobody Talks About

Privacy-first engineering is largely a series of tradeoffs.

Client-side search introduces advantages:

✅ Better privacy

✅ Zero-knowledge architecture

✅ No searchable user profiles

✅ No server-side indexing

But it also introduces costs:

❌ More memory usage

❌ More CPU work on the device

❌ Increased complexity

❌ Slower searches for very large datasets

Privacy isn't free.

It simply changes where complexity lives.

Building Features With A Blind Backend

Search wasn't the only challenge.

Once the backend becomes intentionally blind, many common SaaS features become harder.

Consider:

The server can't index content.

Recommendations

The server can't analyze user behavior.

AI Features

The server can't inspect journal entries.

Analytics

The server can't understand emotional patterns.

Moderation

The server can't review stored content.

Every feature must be reconsidered through a different architectural lens.

What This Taught Me About Privacy

Before building RozVibe, I thought privacy was mostly about encryption.

Now I think privacy is more about restraint.

Encryption is the easy part.

The difficult part is willingly giving up access to data that could make product development easier.

Many software systems are built around visibility.

Privacy-first systems are built around intentional blindness.

And that changes almost every engineering decision.

The Unexpected Benefit

One of the most interesting outcomes wasn't technical.

It was psychological.

When users know their thoughts remain private, they write differently.

More honestly.

More openly.

More completely.

And for a journaling app, that matters far more than a slightly faster search query.

Final Thoughts

Search feels simple because most applications can read their own data.

Once you adopt a privacy-first architecture, that assumption disappears.

Suddenly every feature becomes a design decision.

Not just a technical one.

Building RozVibe taught me that privacy isn't something you add later.

It fundamentally shapes the architecture from day one.

And surprisingly, one of the hardest parts wasn't encryption.

It was search.

About RozVibe

RozVibe is a privacy-first encrypted journaling app designed to help people reflect, track moods, and write freely without surveillance.

Download: [DOWNLOAD LINK]

The Hardest Part of Building an Encrypted Journaling App Wasn’t Encryption

Keshav Chauhan — Tue, 26 May 2026 13:30:00 +0000

Lessons learned building client-side AES-256 encryption, secure sync, and emotionally safe UX in Flutter.

Most apps treat privacy as a feature.

We treated it as infrastructure.

When we started building RozVibe - a privacy-first encrypted journaling app built with Flutter - we quickly realized something uncomfortable:

A journaling app without real privacy creates emotional hesitation.

People write differently when they think someone else might read their thoughts.

And that changes everything.

Because journaling is not just data storage.

It’s cognitive decompression.

It’s emotional honesty.

And honesty requires trust.

The Problem With Most “Private” Apps

A surprising number of apps marketed as “private” still process user data server-side.

Yes, they may use HTTPS.

Yes, databases may be encrypted at rest.

But in many systems:

the company can still access user content
administrators theoretically retain visibility
journal entries may be processed in plaintext
personal reflections become behavioral analytics data

Technically, the data may be secured.

Psychologically, it still doesn’t feel safe.

That distinction became incredibly important while designing RozVibe.

Because emotional safety is not only a UX problem.

It’s an architectural problem.

Our Decision: Encrypt Before Data Leaves the Device

From the beginning, we adopted a strict engineering principle:

User journal content should never be readable by our servers.

That decision immediately shaped the entire system architecture.

Instead of relying on traditional server-side encryption, we implemented client-side AES-256-GCM encryption directly on the device.

Before any journal entry is synced:

Content is encrypted locally
A unique nonce/IV is generated for every encryption operation
Authentication tags are attached
Only ciphertext is transmitted to the backend
The server stores encrypted blobs only

The backend never sees plaintext journal entries.

Even if storage infrastructure were compromised, the stored data would remain unreadable without user-controlled encryption keys.

That trust model mattered deeply to us.

Why We Didn’t Use Server-Side Encryption

Server-side encryption solves infrastructure security problems.

But it does not fully solve trust problems.

With server-side encryption:

the backend still controls decryption
plaintext may exist during processing
administrators can theoretically access content
users must trust infrastructure they cannot verify

We wanted a different model.

In RozVibe, encryption happens before data leaves the device.

The server stores ciphertext - not journal entries.

That architectural distinction fundamentally changes the relationship between the product and the user.

Why AES-256-GCM?

We evaluated multiple encryption approaches before choosing AES-256-GCM.

For a mobile journaling application, we needed:

authenticated encryption
strong security guarantees
tamper detection
low performance overhead
reliable mobile compatibility

AES-GCM offered all of those advantages.

Performance mattered more than we initially expected.

People open journaling apps during emotionally important moments:

late-night reflection
anxiety spikes
emotional overwhelm
quick memory capture

Encryption cannot introduce noticeable friction.

Otherwise people stop writing.

One of the most overlooked parts of privacy engineering is this:

Security that feels heavy often becomes abandoned security.

AES-GCM gave us both security and responsiveness.

The Hardest Engineering Problem Wasn’t Encryption

Surprisingly, implementing encryption itself was not the hardest challenge.

Key management was.

Because encryption strength becomes meaningless if key handling is weak.

Mobile apps constantly deal with unstable environments:

devices restart
sessions expire
users reinstall apps
cloud sync introduces edge cases
operating systems aggressively manage memory

We explored multiple approaches:

Secure Enclave / Keystore integration
OS-protected secret storage
session-derived keys
encrypted persistence layers
recovery edge cases

Balancing usability with strong security became one of the most difficult architectural tradeoffs in the entire project.

Privacy-First Architecture Changes Everything

One of the surprising realizations during development was how quickly privacy-first architecture complicates otherwise normal product decisions.

Even simple features become harder when the backend is intentionally blind.

For example:

Search

Traditional search systems index plaintext content server-side.

Encrypted journaling systems cannot safely do that.

That forces difficult tradeoffs:

local indexing
encrypted search models
limited search capabilities

Syncing

Traditional sync systems assume the backend understands the data structure.

Encrypted sync changes that completely.

The server becomes intentionally unaware of:

journal content
emotional metadata
search context
user meaning

That affected:

conflict resolution
sync optimization
storage debugging
recovery flows
consistency handling

Privacy-first engineering forces you to rethink standard SaaS assumptions from the ground up.

Security UX Is Emotional UX

One lesson became increasingly clear while building RozVibe:

Security UX is emotional UX.

If privacy tools feel intimidating, users disengage.

Many secure products accidentally create anxiety through:

aggressive warnings
technical overload
complicated onboarding
“cybersecurity dashboard” aesthetics

We wanted the opposite.

So we intentionally designed RozVibe with:

minimal visual noise
calm writing spaces
quiet onboarding
simple privacy explanations
reduced cognitive overload

We didn’t want users to constantly think about encryption.

We wanted them to feel psychologically safe enough to write honestly.

That distinction matters more than many engineers realize.

Privacy Is Also a Psychological Design Problem

Building RozVibe changed how we think about software itself.

Modern apps are often optimized for:

engagement
retention
extraction
behavioral profiling
surveillance-driven personalization

Over time, users subconsciously learn this.

And they become less honest online.

Especially in personal spaces.

People begin self-censoring.

Even privately.

That realization fundamentally changed how we approached product design.

Instead of asking:

“How much data can we collect?”

We started asking:

“How little data do we actually need?”

Instead of:

“How do we maximize engagement?”

We ask:

“How do we reduce emotional friction?”

Instead of:

“How do we maximize retention?”

We ask:

“How do we create trust?”

Those questions lead to very different software.

What Building RozVibe Taught Us

Before building RozVibe, we viewed encryption mostly as a technical system.

Now we see it differently.

For deeply personal software, encryption becomes emotional infrastructure.

It gives people space to think honestly without feeling observed.

And honestly, building privacy-first software changed the way we think about engineering entirely.

Not just technically.

Philosophically.

Final Thoughts

The internet has trained people to expect surveillance by default.

That expectation quietly changes human behavior.

Especially in emotionally vulnerable spaces.

Maybe privacy-first software is ultimately about restoring something much simpler:

The ability to be honest with yourself.

If you’re building privacy-first products, secure systems, or thoughtful software architecture, I’d genuinely love to hear how you think about trust, encryption, and emotional safety in modern apps.

About RozVibe

RozVibe is a privacy-first encrypted journaling app focused on emotional safety, secure reflection, calm UX, and client-side encrypted storage.

Download: https://rozvibe.uptodown.com/