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.
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.