4 ms·
Unless compatibility with gpg is a requirement, I think scrypt[0] is a much simpler tool for file encryption. The utility is meant to showcase the KDF of the sa
by RJIb8RBYxzAMX9u 10y ago
Unless compatibility with gpg is a requirement, I think scrypt[0] is a much simpler tool for file encryption. The utility is meant to showcase the KDF of the same name. It's very simple and has virtually no parameters. So:
$ xz -k elrond_minutes.txt
$ scrypt enc elrond_minutes.txt.xz elrond_minutes.txt.xz.enc
$ signify -S \
-s vilya.key \
-m elrond_minutes.txt.xz.enc \
-x elrond_minutes.txt.xz.enc.sig
$ rm elrond_minutes.txt{,.xz}
Signing the final output is probably extraneous; I think scrypt uses a HMAC. This involves invoking multiple tools, but since each tool only does one thing it's much easier to reason about, and I prefer this over using an omnibus tool like gpg.
[0] https://github.com/Tarsnap/scrypt https://github.com/Tarsnap/scrypt
- agumonkey 10y agoMy paranoid self wanted to replace rm with shred.
- twr 10y agoYou can just pipe xz instead, although you may want to shred the original file: xz < file | scrypt enc - > file.xz.enc And I agree: scrypt (the program) is much better for password encrypting documents. It is only a few thousand lines of readable code; it uses modern algorithm choices (scrypt, AES256-CTR, HMAC-SHA256), with no alternatives; there isn't any configuration involved; and it's written by a respected author.
- RJIb8RBYxzAMX9u 10y agoshred is ineffective if you're using a CoW FS, and probably less effective on a journaling FS, and those probably covers 99% of all the FS people use today. Just use FDE.