[slooonz]

I think you should clearly spell out how the key is derived.

From the description, I believe it's random string hard-coded in the executable + user-provided password => AES key ?

Also… "full offline", but "my API is on a digital ocean droplet" ? What ?

(I guess the API to generate a .exe with its own random string ? But again, very unclear of what it is, what’s it’s doing, and how)

[0north]

You’ve mostly got it.

The API on DigitalOcean just builds a fresh .exe and embeds a unique seed into the runtime build. After that, everything is offline.

The seed is made server-side during creation as a SHA-256 over a timestamp + jitter source, and is written as (vault-seed.txt)in the .zip.

Inside the .exe, the vault reads its own embedded seed. The KDF is thus:

key = SHA256(SHA256(password||seed))

Each encryption uses a fresh 16-byte IV and encodes ciphertexts as:

ivHex + "." + encryptedHex

So the text is encrypted and locked behind an AES key and an ivHex per click.

The result is simply: same password + different builds => different AES keys, because each .exe has a different seed baked into it.

That’s what creates the conditions where two environments can never decrypt each-other’s ciphertexts and can be generated endlessly.