On Thu, Jul 25, 2019 at 3:26 PM Robert J. Hansen <r...@sixdemonbag.org> wrote:
> > 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 > Pardon my ignorance, but I gather from this example that I would have to manage not only passphrases but also iv's as well? (That would add to my work's complexity.) 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. > Thank you. This is a valuable perspective. I'm all for simplicity! In fact, if I could have it my way, I would use a library that does nothing more than AES256-encrypt/decrypt (as long as I had any confidence that it would still be maintained 5 years from now). In other words, I would love to use a single-purpose tool that is to AES256-encryption/decryption what, for example, gzip is to compression/decompression. Unfortunately, I have not been able to hit upon such a tool, which I find a bit mystifying. Instead, all the tools I have found fall into two distinct categories: (1) ephemeral projects; (2) large systems (like GnuPG or OpenSSL) in which the AES256-encryption/decryption capability is such tiny subcomponent that it is very difficult for me to find out what I need to do for my purposes. (Who knows, maybe in the cryptography domain, complex multifunctionality is what give systems their longevity.) > [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. > I assume that by this you mean that OpenSSL will still be around 10-15 years from now, and *not* that one can use gpg to decrypt an openssl-encrypted file. (Please correct me if I'm wrong!) Thank you again! kj
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
