I used to keep my passwords in a password-protected, zipped Word document. Stored locally on my PC, with a backup copy on a USB drive.
Every password update required opening the file, entering the master password, editing the entry, syncing the change to the USB backup manually. Repeat.
On my phone? Even worse. I had to boot up the PC, unzip, search, update, re-sync — every single time.
That system worked… until it didn't. I realized I was one hardware failure away from locking myself out of everything. I needed a mobile solution, but with one non-negotiable constraint: my passwords were never leaving my device.
So I built Keyri.
Play Store: https://play.google.com/store/apps/details?id=com.nick.applab.silentsaver
Stack
- Flutter (cross-platform UI, single codebase)
- ChaCha20 for on-device encryption
- Google ML Kit for on-device QR/barcode scanning (optional)
- HaveIBeenPwned API with k-anonymity for breach checks (optional)
- XposedOrNot API for account breach details (optional)
- Brandfetch API for real logo icons (optional)
- Google Drive integration for storing encrypted data (optional)
The constraints that shaped every decision
No cloud = no server = no trust required. That wasn't a feature list — it was the starting point. Every technical choice follows from it.
Encrypting images on-device
I wanted users to store sensitive images (IDs, receipts) inside the vault. Images are compressed on-device, encrypted with ChaCha20, and stored in the app sandbox. The decryption key never leaves the device memory unencrypted.
Breach checks without exposing passwords
I integrated HaveIBeenPwned, but with a hard constraint: the actual password never leaves the device. The solution is k-anonymity — only the first 5 characters of the SHA-1 hash are sent. The server returns a list of matching hash suffixes, and the match is checked locally (standard approach)
Flexible CSV import
I recently rewrote the importer to auto-detect the 5 main credential fields (username, password, URL, title, notes) regardless of column order or naming. It now accepts a wide variety of CSV structures without requiring the user to manually map columns.
One-click autofill via Android's native framework
I wanted logging into websites to feel frictionless — ideally one tap from the browser, no copy-paste. The cleanest way is Android's Autofill Framework, but Flutter doesn't expose it directly.
To make Keyri participate in the system autofill service, I had to drop down to native Android code. I wrote a Kotlin service that integrates with the Autofill API and communicates with the Flutter side via method channels. I didn't know Kotlin before this project — I learned it specifically to implement this feature, with a lot of help from Copilot along the way tbh ;)
The result: Keyri appears as an option in Android's autofill picker, and credentials fill in-app and in browsers with a couple of taps. All parsing of the target app/website structure happens on-device; nothing is transmitted.
Google Drive backup — still local-first
I just rolled out optional Google Drive backup. The challenge was keeping the local-first philosophy intact.
The solution: data is encrypted on-device before upload. The backup file is useless without the app's master key, which never leaves the device unencrypted. Even if Google wanted to hand over the file, it would be encrypted gibberish without the user's credentials.
No account is created. The Drive integration uses the user's existing Google account via OAuth.
What Keyri does today
- Local-first vault: passwords, cards, barcodes/QR codes, encrypted images
- Biometric unlock (fingerprint/face)
- Android Autofill integration
- Local breach checks (k-anonymity, no data sent)
- Encrypted backups (Google Drive optional)
- Flexible CSV import from any major password manager
- Zero ads, zero tracking, zero accounts required
A few questions (no trust required)
I'm aware that a closed-source password manager from a solo dev isn't the easiest sell in the privacy community. I'm not here to ask for your trust — I built this to fix my own Word-document disaster, and I'm sharing it in case you're in the same boat.
If you're willing to evaluate it on its own merits (or just curious about the build), I'd love to hear some feedback.
What's the one feature that would make this actually usable for you? What's the one thing that would make you walk away?
Thanks for reading so far!
Top comments (2)
🫡 neat idea, nice project!
Why do you choose ChaCha20 over AES256GCM (which is usually HW accelerated + shipped in every platform with native support)?
Thanks!
Good question. I originally used Fernet, but it’s deprecated in the modern
cryptographylibrary. The migration path points toward AES-GCM or ChaCha20-Poly1305. I picked ChaCha20 for portability across the wide range of Android devices I target — on lower-end hardware without AES-NI, ChaCha20 in software can be faster and more consistent than AES-GCM. Anyway they are both really good.