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

Aleksandar Lazic al-gnupg_users at none.at
Sat Jul 27 16:50:36 CEST 2019


Hi.

Am 25.07.2019 um 15:46 schrieb Kynn Jones via Gnupg-users:
> Hi everyone,
> 
> 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.
> 
> I need to ENCRYPT ~20 million files (~150TB) for long-term
> (>15y) storage.  This ENCRYPTION will be done in several
> batches, and will take place over many months (due to CPU and
> bandwidth limitations).
> 
> The ideal solution would produce ENCRYPTED files that can be
> decrypted using standard off-the-shelf gpg/gpg2. [1]
> 
> In my search for a library I could use to do this, I found
> gpgme and libgcrypt.  I tried the former, and found it not
> suitable, due to frequent gpg-agent-related failures.
> 
> libgcrypt, on the other hand, is a bit too low-level for
> someone who is not acquainted with the fine details of gpg's
> ENCRYPTION to replicate it.  (AFAICT, using straight-up
> gcry_cipher_encrypt would not necessarily produce an
> encrypted file (let alone an ENCRYPTED file) that could be
> decrypted/DECRYPTED with standard gpg/gpg2.)
> 
> Is there something in-between gpgme and libgcrypt that would
> allow me implement the required tool?
> 
> *Alternatively*, can someone tell me of a more efficient way
> than reading the gpg2 source code for me to learn how to
> implement gpg-compatible ENCRYPTION/DECRYPTION using
> libgcrypt?
> 
> Thank you all in advance!

Have you take a look into libsodium based tools?
https://download.libsodium.org/doc/libsodium_users

For example https://github.com/TLINDEN/pcp

> kj

Best regards
Aleks

> [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.
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 




More information about the Gnupg-users mailing list