<div dir="ltr"><div dir="ltr">On Thu, Jul 25, 2019 at 3:26 PM Robert J. Hansen <<a href="mailto:rjh@sixdemonbag.org">rjh@sixdemonbag.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> First, please allow me to define a bit of ad-hoc<br>
> nomenclature.  I will use the uppercase tems "ENCRYPT",<br>
> "ENCRYPTION", etc. as shorthands for "compress and<br>
> AES256-encrypt", "compression and AES256 encryption", etc.<br>
> Likewise, I will use "DECRYPT", etc. as shorthands for<br>
> "[AES256] decrypt and decompress", etc.<br>
<br>
For a straightforward purely-symmetric use case, consider using OpenSSL.<br>
 Just use it wisely: specify your own key and initialization vector,<br>
rather than trust OpenSSL's weak password derivation function.<br>
<br>
$ tar -cJf - mydir | openssl aes-128-cbc -out foo.txz -K<br>
DEADBEEFDEADBEEFDEADBEEFDEADBEEF -iv DEADBEEFDEADBEEFDEADBEEFDEADBEEF<br>
-out mydir.txz.aes<br></blockquote><div><br></div>Pardon my ignorance, but I gather from this example that I would have<br>to manage not only passphrases but also iv's as well?  (That would add<br>to my work's complexity.)<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Don't get me wrong: GnuPG can definitely do the job you want.  But<br>
consider whether you really need RFC4880's baroque packet format, weird<br>
CFB mode, and everything else.  Sometimes there's a lot to be said for<br>
simplicity.<br></blockquote><div><br></div>Thank you.  This is a valuable perspective.  I'm all for simplicity!<br><br>In fact, if I could have it my way, I would use a library that does<br>nothing more than AES256-encrypt/decrypt (as long as I had any<br>confidence that it would still be maintained 5 years from now).<br><br>In other words, I would love to use a single-purpose tool that is to<br>AES256-encryption/decryption what, for example, gzip is to<br>compression/decompression.<br><br>Unfortunately, I have not been able to hit upon such a tool, which I<br>find a bit mystifying.  Instead, all the tools I have found fall into<br>two distinct categories: (1) ephemeral projects; (2) large systems<br>(like GnuPG or OpenSSL) in which the AES256-encryption/decryption<br>capability is such tiny subcomponent that it is very difficult for me<br>to find out what I need to do for my purposes.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">(Who knows, maybe in the cryptography domain, complex<br>multifunctionality is what give systems their longevity.)<br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> [1] This gpg/gpg2 compatibility requirement is important, as<br>
> an insurance that the files will be DECRYPTABLE in the<br>
> "distant" future (10-15y), even the my tool is not properly<br>
> enough maintained to be operational then.  This, of course,<br>
> assumes that gpg will have greater longevity than a privately<br>
> implemented, single-user tool like mine.<br>
<br>
OpenSSL meets your requirement.<br></blockquote><div><br></div><div>I assume that by this you mean that OpenSSL will still be around 10-15<br>years from now, and *not* that one can use gpg to decrypt an<br>openssl-encrypted file.  (Please correct me if I'm wrong!)<br></div><div><br></div><div>Thank you again!</div><div><br></div><div>kj</div><div><br></div><div><br></div></div></div>