Mailing List Archive

tool to encrypt millions of files in unsupervised mode (was: Need to implement a gpg/gpg2-compatible tool...)
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.
AES specification itself is fixed and unlikely to go away (even though
in 15 years maybe we will all be using a completely different encryption
system).
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.
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.

Best regards



_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: tool to encrypt millions of files in unsupervised mode (was: Need to implement a gpg/gpg2-compatible tool...) [ In reply to ]
On Fri, Jul 26, 2019 at 6:20 PM Ángel <angel@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