tool to encrypt millions of files in unsupervised mode (was: Need to implement a gpg/gpg2-compatible tool...)

[Kynn Jones]

On Fri, Jul 26, 2019 at 6:20 PM Ángel <angel at pgp.16bits.net> wrote:

> On 2019-07-25 at 16:59 -0400, Kynn Jones via Gnupg-users wrote:
> > 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.
>
> A single-purpose tool that only did AES265-encryption would be finished,
> needing little to no mainteinance and thus looking like an ephemeral
> project.
>

I see, good point.


> I think the main risk you would bear using a little-test tool would be
> that it was somehow flawed in a subtle way so that other tools failed to
> decrypt a tiny fraction of the files.
>

Thank you for the heads-up.  I had not considered this risk at all
until now.  I wonder if I can find a good set of test cases, maybe by
cannibalizing the test suites of other programs.

>
> I recommend you to also keep hashes of the original files (maybe in a
> different encrypted file) in addition to whatever authentication system
> you plan to be using. Plus, obviously, keeping a copy of the encryption
> tool (both compiled and in source form) along the backups.
>
> As for the actual format to use, I would suggest using zip files with
> AES encryption. There are many programs supporting it, and it is
> nowadays an ubiquitousformat (albeit AES encryption support is lower,
> that is still much bigger than for eg. an openssl enc format). It seems
> likely that there will still be programs able to decrypt them, even if
> the original program no longer works.
>
> Nevertheless, with a goal like this, you should include a plan wherein
> there are periodic tests of the data, in which a goal can be to detect
> that it is no longer possible to decrypt them with commonplace hardware,
> and perform a migration to a more modern (and supported) encryption
> schema if actually needed.
>

All very sensible advice.  Thank you!

kj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190726/7a028780/attachment.html>