For context, read the first part of this first!

Updates since the last iteration

I’ve updated the encryption scheme to use a username and password instead of just a passphrase. Internally, it operates pretty much treated the same, but this allows for slightly easier management of access/passphrases as I send them to people.

In most places, the static passphrase I was using has been replaced with a concatenated version of the username and password. With this, I can grant access to specific posts for certain users if I wish and easily revoke access.

Procedurally Generated Filenames

I store files in filenames that I generate using pbkdf2, derived from the user/pass and the page’s url. It’s used something like this: PBKDF2(USER||PASS, CANONICAL_URL). This isn’t security though obscurity - the file contents are still encrypted.

This way, only authorized users can read it now and into the future, as you need to know the user/pass to figure out where the encrypted contents are stored. The encrypted material is harder to locate without the correct credentials. As a result this mitigates the possibility of some service such as archive.org, etc. archiving it far into the future when the currently used ciphers may be broken.

The storage filename is sufficiently random that it would not be feasible for someone to brute-force, as long as passwords are strong. Indexes are not served for this site so users cannot list all available files. However, even if someone did acquire one of them, they’d need to have a valid user/pass to decrypt the contents of the file as each is encrypted using AES-GCM.

Encryption

We still derive encryption keys using PBKDF with a sufficiently high iteration count, like so: PBKDF(user||pass, random_salt)

And then, we do encryption using AES-256-GCM: AES-256-GCM(post_html, key, random_iv)