gpgsplit/pgpdump replacement

[halfdog]

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