Zecret
A modern, encrypted terminal diary.
One entry a day, in your terminal, kept in a single encrypted file that only you can open.
zecret.krfu.dev · Install · How it works
Why
A diary should be private by construction, not by promise. Zecret has no server, no account, no sync and no telemetry — there is nowhere for your writing to go. It is one encrypted file on your own disk, opened by a password only you know, in a terminal you already have open.
- 📅 One entry a day — each day is a page, named by its date; come back and it is the same page
- 🗓️ Grouped by month — the diary reads as months, each headed with how much of it you wrote
- 🔐 Encrypted at rest — Argon2id key derivation, AES-256-GCM per entry
- ✍️ Keyboard-driven — a fast Textual TUI, no mouse required
- 🔎 Instant search — live filtering across everything you have written
- 📄 One portable file — back it up by copying it; it is useless without your password
- 🌗 Light and dark — eight themes, picked in settings and remembered
- 🔒 Locks itself — walks away when you do, and asks for your password again
- ⬛ Covers the page — one key bars every word but the one under your cursor, for writing in public
- 🚫 Offline by design — no networking of any kind
Install
uv tool install zecret
zecret
That is the whole of it: uv fetches a
suitable Python along with the program, so nothing depends on what your
system happens to ship. If you would rather use what you already have,
pipx install zecret and pip install zecret both work on Python 3.13 or
newer.
Your diary lives at ~/.zecret/diary.enc by default. Point somewhere else
with --path /some/where.enc or the ZECRET_DIARY_PATH environment
variable — handy for keeping separate diaries, or trying it out without
touching your real one.
Your settings follow you rather than the file, so a diary opened with
--path still uses your theme. If you would rather it did not — running a
build you are working on, say — --config /some/where.json or
ZECRET_CONFIG_PATH gives that run preferences of its own.
zecret --help lists both flags and both environment variables, and
zecret --version says which Zecret you have without opening the diary.
On first launch there is no diary yet, so Zecret asks you to choose a master password and creates one. Every launch after that asks for that password to unlock it.
Using it
Press n to write about today, ctrl+s to save. Saving leaves you in the day with the cursor where you left it, so you can keep going and save again; esc is what goes back, and if you have not saved it offers to before it does. A day holds one entry, so pressing n again later opens what you already wrote rather than starting a second page — the evening simply continues the morning. Every save re-writes the diary file atomically, so there is no draft state to lose track of.
Missed a day? Press a and type the date. Anything up to today is fair game; days that have not happened yet are refused.
Press / to search. Your entries are already decrypted in memory for the session, so filtering is instant and nothing touches the disk.
Press ? for every key in one popup, and s for settings
— where you pick a theme, choose how long the diary waits before locking
itself, and change your master password. Those preferences are kept in
~/.zecret/config.json, the one file Zecret writes unencrypted; it holds
your settings and nothing about what you wrote.
Zecret locks itself after fifteen minutes without a keystroke, and asks for your password again — press ctrl+l to do it yourself on the way out of the room. It works while you are writing, too, and saves the day before locking it away: the alternative would be a question sitting on the screen with the diary open behind it. A half-written entry holds the timer off rather than being thrown away by it. Change the wait, or turn it off, in settings.
Locking covers the diary you have walked away from. ctrl+r covers the one in front of you: every word goes under a bar except the one your cursor is touching, so you can keep writing on a train without the seat behind you reading the page. Press it again to lift the bars, and they stay lifted or lowered as you move between days.
It hides what you have already written, and that is the honest claim: the word you are typing is revealed as you type it, so someone determined to watch you write still can. It is also not a substitute for locking — the bars are on the screen, not on the diary. The text underneath is untouched, so what you save is what you wrote.
Keys
| Key | Where | Does |
|---|---|---|
| n | entry list | Write about today |
| a | entry list | Write about another day (asks which) |
| enter | entry list | Open the selected day |
| d | entry list | Delete the selected day's entry (asks first) |
| r | entry list | Re-read the file, picking up another Zecret's writing |
| / | entry list | Search |
| s | entry list | Settings: theme, locking, master password |
| ctrl+l | entry list, editor | Lock the diary without quitting (saves the day you are writing) |
| ? | entry list | Help — every key, on one page |
| q | entry list | Quit |
| ctrl+s | editor | Save, and carry on writing |
| ctrl+r | editor | Cover the writing, leaving only the word you are on |
| esc | anywhere | Back (offers to save first if you have unsaved edits) |
| ctrl+q | anywhere | Quit (offers to save first if you have unsaved edits) |
Getting around a long diary: j/k or the arrow keys move a day at a time, g/G (or home/end) jump to the newest and oldest entries, and PgUp/PgDn move a screenful. These stay out of the bar at the bottom, which only has room for so much — ? lists everything.
Inside a day, the editor answers to the usual text-editing keys, including ctrl+home/ctrl+end for the two ends of the entry and ctrl+a to select all of it. Those are not listed under ?: it is a page about the diary, and they mean here what they mean in every other editor.
How it works
- Key derivation — Argon2id (
time_cost=3,memory_cost=64 MiB,parallelism=4, roughly OWASP interactive settings), with a random 16-byte salt generated per diary and stored in the file header. Your password is never stored; the derived key never touches disk. - Encryption — AES-256-GCM with a fresh random nonce for every encryption. Each day's entry is encrypted independently, so editing one day never re-encrypts the others. Only the dates are visible in the file; every word you write is inside the ciphertext.
- Integrity — tampering with a stored entry, or a wrong password, fails the AEAD authentication check and is reported as an error, never as an empty or partial diary. The header carries an encrypted verifier, so this holds even for a diary with no entries yet.
- Durability — saves are atomic (temp file →
fsync→os.replace), so an interrupted save can never leave a half-written diary. Creating a diary instead claims the path withO_EXCL, so two first runs racing each other cannot end with one written over the other; a creation that fails removes what it started. The file is created0600.
Plaintext is never written to disk — not as temp files, not as logs, not for crash recovery.
Development
git clone https://github.com/kfurtak1024/zecret.git
cd zecret
uv sync # dev tools included (PEP 735 dependency group)
./zecret-dev.sh # run it against a throwaway diary
uv run pytest
uv run ruff check . && uv run ruff format .
uv run mypy
Note ./zecret-dev.sh rather than uv run zecret. Running the app from a
checkout opens your own diary with whatever code is currently checked
out, which is not what you want a half-finished change doing. The script
points the app at .zecret-dev/ instead — gitignored, throwaway, and
seeded on first run with a few hundred generated days so there is enough in
it to see a layout problem. The password is dev. Delete the directory
whenever you like; the next run rebuilds it.
It overrides the preferences file as well as the diary, which matters more than it sounds: without that, trying themes out in a development build changes the theme in the one you write in.
uv run python tools/seed_dev_diary.py --help # different data, same guardrails
The screenshots above are generated, not taken by hand — regenerate them after any change that alters what a screen looks like:
uv run python tools/screenshots.py # needs librsvg or inkscape
CI runs those same checks on every push and pull request. uv.lock is
committed and CI installs from it, so regenerate and commit it whenever
pyproject.toml changes.
License
MIT © Krzysztof Furtak — see LICENSE.
Metadata
Release files for zecret 0.4.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| zecret-0.4.0.tar.gz | 1.3 MB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| zecret-0.4.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 1.4 MB
Release files / zecret-0.4.0.tar.gz
| Download URL | zecret-0.4.0.tar.gz |
|---|---|
| Size | 1.3 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
76abba7bb0f3200973e02e1916dd71cc330cc59154c17283707d16e8056a7b3e
|
|
BLAKE2b-256 checksum How to use checksums |
374b27d11c86be30f54a098f3ec63fcc84b30101913bc35b6a75af68a353008d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 27, 2026.
Transparency logRelease files / zecret-0.4.0-py3-none-any.whl
| Download URL | zecret-0.4.0-py3-none-any.whl |
|---|---|
| Size | 74.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
e4043432577d9994b5eaeeab0f12f187307a4342ce430025eca35910b474544c
|
|
BLAKE2b-256 checksum How to use checksums |
a7dc58e513e53a589d2d0b77b9dd47e4c008a82035a063eb83ea0223ff40c416
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 27, 2026.
Transparency log