> First, please allow me to define a bit of ad-hoc > nomenclature. I will use the uppercase tems "ENCRYPT", > "ENCRYPTION", etc. as shorthands for "compress and > AES256-encrypt", "compression and AES256 encryption", etc. > Likewise, I will use "DECRYPT", etc. as shorthands for > "[AES256] decrypt and decompress", etc.
For a straightforward purely-symmetric use case, consider using OpenSSL. Just use it wisely: specify your own key and initialization vector, rather than trust OpenSSL's weak password derivation function. $ tar -cJf - mydir | openssl aes-128-cbc -out foo.txz -K DEADBEEFDEADBEEFDEADBEEFDEADBEEF -iv DEADBEEFDEADBEEFDEADBEEFDEADBEEF -out mydir.txz.aes Don't get me wrong: GnuPG can definitely do the job you want. But consider whether you really need RFC4880's baroque packet format, weird CFB mode, and everything else. Sometimes there's a lot to be said for simplicity. > [1] This gpg/gpg2 compatibility requirement is important, as > an insurance that the files will be DECRYPTABLE in the > "distant" future (10-15y), even the my tool is not properly > enough maintained to be operational then. This, of course, > assumes that gpg will have greater longevity than a privately > implemented, single-user tool like mine. OpenSSL meets your requirement. _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
