Thanks for the feedback. This is why I built it FOSS.

On the libraries: Mini Diarium actually does use established, widely audited crates rather than rolling its own primitives. See https://github.com/RustCrypto/AEADs for AES-256-GCM, https://github.com/RustCrypto/password-hashes for key derivation, and https://github.com/dalek-cryptography/curve25519-dalek + https://github.com/RustCrypto/KDFs for the key file ECIES scheme. The thin cipher.rs wrapper just handles nonce prepending with no custom crypto primitives.

On key reuse: the master key is intentionally shared across entries (as in Signal, 1Password, etc.), but each encrypt() call generates a fresh 96-bit nonce from the OS CSPRNG, so the (key, nonce) pair is never repeated.

That said, I am not a security expert by any means. If you've spotted something concrete, a specific call site, a protocol flaw, or a library you'd swap in, I'd genuinely love to hear it. Open to PRs or a discussion issue.

Regards

Let alone the cloud, SQLite in iCloud Drive is the reason I am not using Bear notes app. After losing to convoluted file formats a couple of times I do not consider any journal or notes app that doesn’t let me see/edit plain text files on the disk. I will deal with encryption, storage, etc on my own. Those are too personal files to be either locked or go behind any amount of friction. I still have tons of files locked from Dyrii that was abandoned

Hey, thanks for the feedback! Yes, currently in the preferences you can see the path of your local SQLite DB file, so you could definitely sync that to the cloud.

I will improve it further in next releases to make it even simpler (for example, by defining a custom path for the store, which cannot be done currently), but it can definitely be done already.

Regarding the key for recovery: you can already do it. Mini-Diarium already supports both password and public key authentication. So you can use the password and generate the .key file and keep it in a secure place as a backup in case you forget your password (or do it in reverse: use the key file and have the password as a backup).

Thanks again!

This site is not for bots, go away please.

The "before it touches disk" thing in the promo copy is silly, yes, but there's really no sane threat model for this; from every vantage point where this could matter, you already have game-over attacks on the app.

Protected memory can be used to fix that. Working on a related project that I'm planning to share soon.

But so what? Another app can't really read swap file/partition. Unless it runs with elevated privileges like root, in which case the system is compromised anyway.

Hey, thanks for the feedback! That's a valid point; currently, my main focus is to secure the store on disk, but this is definitely a point which could be improved later on.

If your machine is fully compromised or actively monitored by a threat actor with physical access, then this tool would not cover you, that's for sure.

If you have any concrete recommendations, I can even give it a try in one of the next releases.

Thanks!

I thought we were all supposed to be encrypting our swap. Or is there something better an app can do about this?