Need to implement a gpg/gpg2-compatible tool to encrypt millions of files in unsupervised mode

[Kynn Jones]

On Thu, Jul 25, 2019 at 3:26 PM Robert J. Hansen <rjh at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190725/a8ec037c/attachment.html>