Since getting my nitrokey I wanted to be able to be able to conveniently access some files protected by my nitrokey.
Everything I found seemed either overly complicated, or a hassle to use (not something I could quickly use with a single command). So I’ve written a utility to handle this, it’s not nitrokey spesific, I just use the nitrokey to store the password.
It’s just a convenience wrapper around openssl to temporarily decrypt, then encrypt files after editing. The readme includes some examples that access the password from the nitrokey.
This is all fairly simple stuff, it’s just that having to do this manually ends up being such a hassle that I found it off-putting, whereas this can be command + touch-nitrokey it’s more or less acceptable for me.
I had a brief look into it and have a few suggestions:
you should use a separate dir beneath /dev/shm and restrict the permissions for the current user so that other users are not able to access the decrypted files
/dev/shm might get swapped so swapoff might be necessary or encrypted swapfile
never use passwords via cmdline arguments as this can be read in ps output and could leak the password. better, pipe it in via stdin, read it from a secured file, environment parameter for the user or use kernel keyring
you could use a gpg key stored on a token and use asymmetric cryptography (e.g. pass can be used like this with a Nitrokey)
I’ve updated the script to take the password as an environment variable (as you suggested).
Python’s tempfile.TemporaryDirectory creates a directory that other users can’t read.)
Regarding Python’s fernet primitives, I hadn’t heard about these before. Some reasons not to use them could be…
Wanting to keep this a simple-script (no additional dependencies), while openssl is technically a dependencies, it’s fairly ubiquitous.
Wanting to create a file users can decrypt in a straightforward way with command line tools.
It may be that fernet primitives can work here too, I just wanted to go with something familier to users (also myself), so if in a decade or two - Python’s fernet primitives aren’t maintained, there is a good chance openssl will still be able to decrypt the files.
As for your other points.
Re /dev/shm, good to know that it may be written to disk. Ideally there could be an in-memory-encrypted-ram-disk, perhaps something using FUSE on Linux. It may be out-of-scope for with-crypt to solve this itself, although if there is a convenient way to temporarily set this up - then it’d be worth including in the documentation.
Note that I suspect in this case, users may be better of encrypting their swap - because even if the users store the files on an encrypted-ram-disk any application editing/viewing the files could have it’s data written un-encrypted to swap.
Included a note about encrypted-swap in the readme.
Although I’ve used gpg, I always found gpg to be confusing and never managed to set it up in a way I could use with confidence. OTOH, I’m not against it, it’s just not something I’m likely to use myself right now.
