Mailing List Archive

gpgsplit/pgpdump replacement
Hello list,

I just noticed that gpgv2 packaged for Debian does not include
the "gpgsplit" and "pgpdump" tools any more.

Is there any replacement available for them, e.g. by option to
main "gpg" binary?

hd


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsplit/pgpdump replacement [ In reply to ]
halfdog wrote:

> Hello list,
>
> I just noticed that gpgv2 packaged for Debian does not include
> the "gpgsplit" and "pgpdump" tools any more.
>
> Is there any replacement available for them, e.g. by option to
> main "gpg" binary?

As an alternative you may check out the original pgpdump utility
and sequoia pgp for splitting packets.

http://www.mew.org/~kazu/proj/pgpdump/en/

https://docs.sequoia-pgp.org/sq/index.html

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsplit/pgpdump replacement [ In reply to ]
Hello Stefan,

Thanks for your helpful reply!

Stefan Claas writes:
> halfdog wrote:
>
>> Hello list,
>>
>> I just noticed that gpgv2 packaged for Debian does not include
>> the "gpgsplit" and "pgpdump" tools any more.
>>
>> Is there any replacement available for them, e.g. by option
>> to main "gpg" binary?
>
> As an alternative you may check out the original pgpdump utility
> and sequoia pgp for splitting packets.
>
> http://www.mew.org/~kazu/proj/pgpdump/en/

Oh, interesting. This might have been an inconsistency in my
standard procedures as "pgpdump" still seems to be available
as a package on Debian Bullseye, but was not installed by the
install automation system on the target device in question.
I updated the configuration to have it installed during initial
setup.

> https://docs.sequoia-pgp.org/sq/index.html

Oh, seems very nice, but Debian Bullseye is packaging only the
verifier at the moment. Packaging is quite useful when wanting
it preinstalled and updated automatically on multiple devices.
Do you know if there are plans to get it into Debian Bullseye
or at least run it via own deb repositories?


As you seem to know about both gnupg and Sequoia, may I ask your
opinion if it is possible to implement following use case with
one of both?


There are multiple devices in the field, which cannot efficiently
be protected against physical access. These devices contain a
number of quite large (MBs to GBs) encrypted files with historic
data, which are usually not needed during normal operation. Therefore
the decryption key is not available on the device.

When something fails, this data might need to be reprocessed.
Due to the expensive/slow mobile link it would be painful to
transfer the encrypted file to the centralized server to decrypt
them here and send back the decrypted data over the slow link.
On the other side agent forwarding would keep your private key
available to a low-security remote device for a long time until
all the files are decrypted and does not give you any realistic
control, what is done with your private key when operating on
a larger batch of files (some thousand key operations which would
be error prone/slow to review and acknowledge all one by one).


The old procedure therefore was:

1) Use pgpsplit remotely to split the first KB of each encrypted
file to get the encryption header packet.

2) Transfer all those packets over the slow link.

3) Perform some packet check with pgpdump and then extract the
session keys from all those packets locally.

4) Send back a text file with all session keys.

5) Slowly decrypt/decompress/process all files remotely using
the session keys.

6) Destroy the session keys on the remote tmpfs by overwriting
the memory pages.



As you can see the procedure did not require any additional
software on local/remote while the functions were still available
with gpg and allows you to make sure, that you only decrypted
exactly the number of session keys you expected from the remote
side. It prevented misuse of you key for signing. With remote
device compromised it did not protect against decrypting other
data from that device (e.g. historic files already deleted and
being reinjected by an attacker) or files from another device
sharing the same public key for encryption. Later could be easily
prevented by using a per-device encryption key. As the two remote
attack scenarios were deemed very unlikely and low-impact, there
is no protection in place.

@PGP-RFC-Devs: Could it be a nice feature for future of PGP (if
cryptographically unproblematic) to have some kind of manipulation
proof "tag" in the encrypted session-key packet, that can be set,
e.g. via

--tag-encrypted-data "mytag-$(echo "some-salt $(hostname -f)" | sha256)"

to identify encrypted data source and avoid decrypting injected
session key packets. 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.

hd


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsplit/pgpdump replacement [ In reply to ]
Hi,

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
process:

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.

HTH,

Peter.

--
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 <http://digitalbrains.com/2012/openpgp-key-peter>
Re: gpgsplit/pgpdump replacement [ In reply to ]
halfdog wrote:

> Hello Stefan,
>
> Thanks for your helpful reply!

Hi halfdog,

you're welcome!

[...]

> As you seem to know about both gnupg and Sequoia, may I ask your
> opinion if it is possible to implement following use case with
> one of both?

I only started to use sequoia pgp as a replacement for GnuPG recently,
due to performance issues on my old offline Notebook and wanted to
mention that the packet split functionality is there included too.

[...]

> The old procedure therefore was:
>
> 1) Use pgpsplit remotely to split the first KB of each encrypted
> file to get the encryption header packet.
>
> 2) Transfer all those packets over the slow link.
>
> 3) Perform some packet check with pgpdump and then extract the
> session keys from all those packets locally.
>
> 4) Send back a text file with all session keys.
>
> 5) Slowly decrypt/decompress/process all files remotely using
> the session keys.
>
> 6) Destroy the session keys on the remote tmpfs by overwriting
> the memory pages.

I would say if you use sequoia pgp as a replacement for pgpsplit it
should work the same.

At least it's worth a try, in case you find no alternative and chances
would be low that in the future such split functionality would not be
included in future versions of GnuPG.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsplit/pgpdump replacement [ In reply to ]
On Wed 2020-05-27 20:42:45 +0000, halfdog wrote:
> I just noticed that gpgv2 packaged for Debian does not include
> the "gpgsplit" and "pgpdump" tools any more.

pgpdump was never part of GnuPG, it ships in its own package.

The gnupg-utils package contains /usr/bin/gpgsplit.

For more detailed examination of OpenPGP-related objects, in addition to
the other free software projects mentioned on this thread, you might
also be interested in python3-pgpy (if you are comfortable with python).

--dkg
Re: gpgsplit/pgpdump replacement [ In reply to ]
Peter Lebbing writes:
> 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
> process:
>
> 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.
> ...

You are right. The reason for the gpgsplit/transfer/decrypt scheme
was mainly because increase of data volume made the initial design
with full data transfer problematic. I should have moved to intermediate
key design back then already.

I think I will change the encryption of new data according to
your suggestings and keep some old gpgv1 instance while there
is still some old data around using the old encryption scheme.
It would be even possible to "upgrade" the old data by extracting
the session keys and reencrypting them but I do not think this
would be worth it.

Thanks,
hd

PS: good point thinking about the randomness needed. That should
be considered in general but in this specific use case (due to
the IO activity for the data to be encrypted) the software RNG
should gather sufficient entropy between invocations once per
day.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users