Need to implement a gpg/gpg2-compatible tool to encrypt millions of files in unsupervised mode
kynnjo at gmail.com
Thu Jul 25 22:59:51 CEST 2019
On Thu, Jul 25, 2019 at 3:26 PM Robert J. Hansen <rjh at sixdemonbag.org>
> > 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
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
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.)
>  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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnupg-users