gpgsplit/pgpdump replacement

Peter Lebbing peter at
Thu May 28 10:26:48 CEST 2020


On 28/05/2020 06:20, halfdog wrote:
> Using a signing key per source seems to be impractical here too as it
> would also require to transfer the whole file beforehand for signature
> verification.

What about solving your entire use-case with an explicit two-step

There's an encrypted, signed OpenPGP file with just a cryptographically
secure random number. It is signed by a per-source signing key and
encrypted to the secure machine.

There's another file with symmetrically encrypted data using the tool of
preference (could be GnuPG with --symmetric encryption) which actually
contains the bulk of the data. The "passphrase" or encryption key is the
cryptographically secure random number from the OpenPGP file.

So every time you would now create a public-key encrypted file with the
historic data, you explicitly generate a fresh "session key". You
encrypt the data symmetrically with that key, and also public-key
encrypt and sign that "session key".

When you need to recover the historic data, the device sends only all
the public-key encrypted "session keys" to the secure machine. That
checks all these are signed by the device in the field, and if so,
returns all "session keys".

It's basically a duplication of the OpenPGP session key, and indeed,
internally you are using a session key to encrypt a "session key". So it
needs twice the randomness, which might be a problem on embedded
systems. But it prevents needing packet surgery and inspection, instead
just using default mechanisms.



I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Gnupg-users mailing list